Жизненный цикл объектов, передаваемых со ссылкой на STL контейнеры

Question

Я опытный кодер, но все еще относительно новый для STL, и только пришли на эту проблему:

Насколько мне известно, STL контейнеры не предназначены для копирования объектов, которые они содержат, или иным образом влияют на их жизненные циклы, но экспериментально я вижу разные результаты.

В частности, классы строк, которые предназначены для обнуления первого символа их базового хранилища при уничтожении, по-прежнему доступны, если они хранятся в контейнере до того, как они выйдут из области видимости. Например, рассмотрим следующий пример:

с использованием пространства имен std;

queue<string> strQueue; 

const char *genStr(int i) 
{ 
    ostringstream os; 
    os << "The number i is " << i; 
    strQueue.push(os.str()); 
    return strQueue.back().data(); 
} 

void useStr() 
{ 
    while(!strQueue.empty()) 
    { 
     cout << strQueue.front() << endl; 
     strQueue.pop(); 
    } 
} 

int main(int argc, char **argv) 
{ 
    for(int i = 0; i < 40; i++) 
    { 
     printf("Retval is: %s\n", genStr(i)); 
    } 
    useStr(); 

    return 0; 
} 

Как струны выходит из области видимости, когда genStr() выходит, я бы ожидать, что Printf на только выход «RetVal является:», или, по крайней мере, для вызова useStr(), чтобы дать неопределенные результаты , так как память прерывалась повторными выделениями из дополнительных вызовов, но оба они возвращают соответствующие сохраненные строки.

Я хотел бы знать, почему это происходит, но вместо этого я был бы рад просто узнать, могу ли я полагаться на этот эффект, происходящий с любым старым объектом.

Благодаря

Answer 1

Насколько мне известно, STL контейнеры не предназначены для копирования объектов, которые они содержат

Хорошо, давайте остановимся прямо там. Контейнеры STL do часто копируют их содержимое. Они копируют их, когда они вставлены, они копируют их, когда контейнер изменяется либо автоматически, либо явно, и копирует их, когда сам контейнер копируется. Много копий.

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

Кроме того, ссылки на ваш код отсутствуют, поэтому я озадачен тем, что относится к названию этого вопроса.

Answer 2

Что входит в контейнер представляет собой копию объекта, а не сам объект. Точно так же вы также получаете копию. Вы можете получить доступ к этим объектам до тех пор, пока ваш контейнер находится в области видимости.

Answer 3

Все коллекции «STL» (я ненавижу этот термин) хранят копии переданных им объектов, поэтому время жизни объекта в коллекции полностью не зависит от исходного объекта. При нормальных обстоятельствах копия объекта коллекции останется действительной до тех пор, пока вы не удалите ее из коллекции или не уничтожьте коллекцию.

Answer 4

STL контейнеры не предназначены для копирования объектов, которые они содержат

STL является все о изготовление копий. Это сделает их, когда вы вставляете объекты, и иногда их создавайте, если базовое хранилище будет изменено.Вы можете сломать код, если объект, который вы копируете, становится недействительным, когда ваша функция выходит за пределы области видимости (например, если вы добавляете указатель на локальную переменную, а не копируете локальную переменную).

В вашем случае вы не копируете ссылку на строку, вы копируете строку. Эта скопированная строка существует в области strQueue, поэтому поведение, которое вы видите, является полностью действительным и надежным.

Вот еще одно недоразумение прояснится:

В частности, классы строк, которые предназначены для обнуления первого символа их основной памяти при разрушении

C++ не стремится когда-либо делать подобные вещи. Это будет скрытая стоимость, а C++ ненавидит скрытые затраты :) Дескриптор строки не коснется памяти, потому что, как только деструктор вышел, объект больше не существует. Доступ к нему - неопределенное поведение, поэтому реализация C++ будет делать все, что быстрей и наименее расточительно в четко определенном коде.