Может ли std :: string перемещаться после создания, если он никогда не изменялся?

Question

Может ли std :: string перемещаться после создания, если он никогда не изменялся?

0

Я использую std :: string для управления памятью и эффективности для хранения относительных данных местоположения.

Строка std :: инициализируется длиной 30 байт, и после этого никогда не будет никаких вызовов, сделанных в их контейнере, кроме, возможно, деструктора.

То, что я хочу знать, - это если им гарантировано остаться в одном месте после того, как они были инициализированы, если они не будут изменены?

Nowayz 06 янв. 2014, в 18:29

Источник

0

Смотрите здесь : «Указатель, полученный из c_str (), может быть признан недействительным путем: передачи неконстантной ссылки на строку в любую стандартную библиотечную функцию или вызова неконстантных функций-членов в строке (...)»
BoBTFish 06 янв. 2014, в 16:38
0

Я передал непостоянную ссылку на символ * для инициализации, но он должен просто скопировать эти данные и все будет хорошо, я полагаю, после этого.
Nowayz 06 янв. 2014, в 16:40
0

Прочитайте вашу ссылку, но, к счастью, я не буду передавать или вызывать функции-члены (кроме c_str ()) после инициализации, и любой доступ будет осуществляться из этого указателя.
Nowayz 06 янв. 2014, в 16:47
0

В этом случае вы также должны обратить внимание на то, что «запись в массив символов, доступ к которому осуществляется через c_str() является неопределенным поведением». Который действительно само собой разумеется, потому что вы должны отбрасывал const -ness
BoBTFish 06 янв. 2014, в 16:51
0

Если длины всегда фиксированы, std::array<char, 30> может быть более подходящим. Они гарантированно останутся в одном месте независимо от того, что какой-то идиот-программист решит с ними сделать.
Casey 06 янв. 2014, в 17:27
0

@Casey, ты совершенно прав. Я забыл о фиксированном размере std :: array! Это лучшее решение на сегодняшний день. Спасибо
Nowayz 06 янв. 2014, в 20:17

Показать ещё 4 комментария

Теги:

c++

c++11

3 ответа

1

Если вы каким-либо образом не измените строку, адрес ее динамических данных не изменится. Я настоятельно рекомендую вам использовать const std::string в том случае, если вы описываете это для лучшей удобочитаемости и ремонтопригодности.

Ivaylo Strandjev 06 янв. 2014, в 13:46

0

Это звучит так, как если бы вы захотели использовать std::unique_ptr<char[]> вместо std::string. Это делает тот факт, что вы на самом деле не храните строку, но хотите только автоматического уничтожения, явного.

fgp 06 янв. 2014, в 15:36

0

В этом случае автоматическое уничтожение не требуется, объекты создаются динамически и будут явно уничтожены кодом. Спасибо хоть
Nowayz 06 янв. 2014, в 20:12
0

@Nowayz Тогда, боюсь, я не совсем понимаю, что ты пытаешься сделать ...
fgp 07 янв. 2014, в 11:53
0

Попытка избежать написания всего контейнера только для эффективного управления памятью того, что лучше всего подходит в простом массиве C
Nowayz 07 янв. 2014, в 22:50
0

@Nowayz Это действительно не мое дело, но теперь вы меня заинтересовали - почему тогда std :: unique_ptr <T []> не отвечает вашим потребностям? Он заботится об управлении динамически распределяемым массивом Ts ...
fgp 07 янв. 2014, в 23:52
0

Это сработало бы, я просто не хочу, чтобы оно разрушалось, когда выходило за рамки.
Nowayz 09 янв. 2014, в 18:52
0

@Nowayz Ах, хорошо, ты не хочешь, чтобы это вызывало деструктор T. Я предполагаю, что вы в настоящее время используете размещение new для создания объектов в памяти, выделенной std :: string, и позже вызываете деструктор для их уничтожения?
fgp 09 янв. 2014, в 22:39
0

Да, байт-код, сгенерированный в реальном времени, хранится в сегментах и должен оставаться в том же месте, пока не будет вызван деструктор.
Nowayz 10 янв. 2014, в 09:45
0

@Nowayz Хм, тогда я бы использовал std::unique_ptr<char[]> Я думаю ...
fgp 10 янв. 2014, в 11:41
0

Мне не нужен объект, который "умный". Все, что мне нужно, это эффективное управление памятью, поэтому я не трачу место на 4 КБ и не трачу время на написание менеджера. Я забыл о добавлении std :: array в C ++ 11, пока Кейси не прокомментировал. Это то, что я использую.
Nowayz 11 янв. 2014, в 03:28

Показать ещё 7 комментариев

Ещё вопросы

Смотрите здесь : «Указатель, полученный из c_str (), может быть признан недействительным путем: передачи неконстантной ссылки на строку в любую стандартную библиотечную функцию или вызова неконстантных функций-членов в строке (...)»
Я передал непостоянную ссылку на символ * для инициализации, но он должен просто скопировать эти данные и все будет хорошо, я полагаю, после этого.
Прочитайте вашу ссылку, но, к счастью, я не буду передавать или вызывать функции-члены (кроме c_str ()) после инициализации, и любой доступ будет осуществляться из этого указателя.
В этом случае вы также должны обратить внимание на то, что «запись в массив символов, доступ к которому осуществляется через c_str() является неопределенным поведением». Который действительно само собой разумеется, потому что вы должны отбрасывал const -ness
Если длины всегда фиксированы, std::array<char, 30> может быть более подходящим. Они гарантированно останутся в одном месте независимо от того, что какой-то идиот-программист решит с ними сделать.
@Casey, ты совершенно прав. Я забыл о фиксированном размере std :: array! Это лучшее решение на сегодняшний день. Спасибо
В этом случае автоматическое уничтожение не требуется, объекты создаются динамически и будут явно уничтожены кодом. Спасибо хоть
@Nowayz Тогда, боюсь, я не совсем понимаю, что ты пытаешься сделать ...
Попытка избежать написания всего контейнера только для эффективного управления памятью того, что лучше всего подходит в простом массиве C
@Nowayz Это действительно не мое дело, но теперь вы меня заинтересовали - почему тогда std :: unique_ptr <T []> не отвечает вашим потребностям? Он заботится об управлении динамически распределяемым массивом Ts ...
Это сработало бы, я просто не хочу, чтобы оно разрушалось, когда выходило за рамки.
@Nowayz Ах, хорошо, ты не хочешь, чтобы это вызывало деструктор T. Я предполагаю, что вы в настоящее время используете размещение new для создания объектов в памяти, выделенной std :: string, и позже вызываете деструктор для их уничтожения?
Да, байт-код, сгенерированный в реальном времени, хранится в сегментах и должен оставаться в том же месте, пока не будет вызван деструктор.
@Nowayz Хм, тогда я бы использовал std::unique_ptr<char[]> Я думаю ...
Мне не нужен объект, который "умный". Все, что мне нужно, это эффективное управление памятью, поэтому я не трачу место на 4 КБ и не трачу время на написание менеджера. Я забыл о добавлении std :: array в C ++ 11, пока Кейси не прокомментировал. Это то, что я использую.

wrren · Accepted Answer · 2014-01-06T15-35-00.000Z

Если вы перемещаете, вы имеете в виду, что внутренний указатель на строку символов может быть изменен, а затем нет, это не должно происходить до тех пор, пока вы не вызываете какие-либо неконстантные строковые методы.

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

STD :: строка (данные, 30); где данные - char *, 30 - size_t. После этого любой доступ на чтение должен осуществляться непосредственно из внутреннего указателя. Вот как происходит создание и доступ.