Должен ли я использовать строку или символ []? - PullRequest
0 голосов
/ 22 августа 2010

Итак, я хочу иметь буфер с массивом структур вроде этого:

EventItem
{
   tag; // some string or array of characters to describe the value;
   value; // some integer or something

}

Значение может быть любым, например, int32.Что меня беспокоит, так это тег.Если у меня есть массив этих объектов, и я делаю тег строкой, что произойдет, если пользователь введет EventItem в этот буфер, который имеет длинный тег?Приведет ли это к тому, что буфер или его части будут скопированы в другое место в памяти для хранения этого большего EventItem (большего из-за этой длинной строки)?

Было бы лучше для меня ограничить тег, просто используяфиксированное количество символов с использованием массива вместо строки?

Очевидно, я не знаю точно, о чем я говорю, но я не знаю, как создать буфер с нужным количествомсмежного пространства, не зная заранее размер EventItems.

Может ли кто-нибудь объяснить, как эта ситуация будет ухудшаться для меня?

Заранее большое спасибо!

Ответы [ 4 ]

7 голосов
/ 22 августа 2010

То, что вы хотите, это std::string.

Не только потому, что его c ++ и не c, но и потому, что работать на std::string s намного проще, чем на char[].

Кроме того, построение вашей структуры также может быть более простым и простым, избегая копирования char[]

struct EventItem{

   EventItem(const int_32 value,const std::string&tag):m_value(value),m_tag(tag){}

   int_32 m_value;
   std::string m_tag;
};

Меня беспокоит тег. Если у меня есть массив этих объектов, и я делаю тег строкой, что происходит, если пользователь вводит EventItem в этот буфер, который имеет длинный тег? Будет ли это вызвать буфер или его части для копирования где-то в памяти, чтобы держать это больше EventItem (больше из-за это длинная строка)?

Не ясно (ИМО), но я склонялся к «нет, и не беспокойся об этом». Единственный способ, которым это могло бы произойти, - это когда буфер пересекает границу страницы (при условии, что здесь используется страничная память). Ну, если это произойдет, это произойдет. Об этом позаботится чудо виртуальной памяти.

Очевидно, я не знаю точно, что Я говорю о, но я не знаю как буфер может быть создан с нужное количество непрерывного пространства не зная размера EventItems заранее.

Пусть std::vector позаботится об этом. Конечно, всегда могут возникать ситуации, когда смежное пространство может быть недоступно. Почему ты так переживаешь Можете ли вы объяснить нам ситуацию, когда это будет проблемой?

2 голосов
/ 22 августа 2010

Если у меня есть массив этих объектов, и я делаю тег как строку, что произойдет, если пользователь введет EventItem в этот буфер, который имеет длинный тег? Приведет ли это к тому, что буфер или его части будут скопированы в другое место в памяти для хранения этого большего EventItem (большего из-за этой длинной строки)?

Если вы используете std :: string, то сам EventItem не будет увеличиваться (или уменьшаться) в размере независимо от того, что вы делаете с элементом строки. std :: string управляет своим фактическим содержимым, сохраняя его в другом месте. Внутри он, вероятно, содержит указатель на память, выделенную в другом месте (вероятно, с использованием new). Если ему когда-либо понадобится расширение для хранения большего количества контента, он просто выделяет новую память, копирует данные и освобождает старое. Сам объект std :: string всегда имеет одинаковый размер.

Это относится практически ко всему в C ++. std :: vector, std :: list и т. д. По сути, любой объект, который каким-то образом динамически расширяется для хранения все большего и большего количества контента, фактически использует указатели и new для хранения контента в другом месте.

С другой стороны, вам нужно быть осторожным, если вы когда-либо сохраняете свои собственные указатели на некоторые фрагменты контента, управляемые внутри объекта, такого как std :: string или std :: vector или тому подобное. При добавлении дополнительных элементов в такой контейнер весь набор может быть скопирован в другое место и, таким образом, лишает законной силы ваши указатели.

Так что, если у вас, возможно, есть std :: vector, то каждый раз, когда вы добавляете другой EventItem к этому вектору, он может перемещать всю группу в другое место в памяти. Но, конечно, если вы когда-нибудь получите доступ к этим элементам только через методы вектора (например, at () или operator []), вы даже не заметите разницу.

0 голосов
/ 22 августа 2010

Это зависит от того, что буфер должен содержать. Обычно в буферах данных не должно быть реальных указателей внутри. Это исключает структуры данных даже так просто, как std::string. Если это не является обязательным требованием, подумайте еще раз, нужен ли вам в действительности плоский буфер данных.

Буферам данных с фиксированным распределением для строк нет места в C ++. Небольшие встроенные системы, да. Обычно такие приложения не включают «описание значения».

Скорее всего, вам следует отменить применение любого использования массивов, буферов, char[] и постоянных необработанных указателей в пользу vector, string и управляемых структур.

0 голосов
/ 22 августа 2010

Оба отстой. Вместо этого используйте QString.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...