[Crazy_kettle]

Сообщение от Drakosha

Во первых, copy constructor и operator= всегда стоит написать или запретить. (Пользоваться дефолтным === написать)

Если запретить, то имхо в вектор ничего нельзя будет добавить . Кстати, Имхо вызов конструктора не вредит. Другое дело деструктор, но его я убрал . Память освобождается при очистке вектора. Да это решение не идеально, т.к. нужно иметь ввиду возможные кросс-референсы и memory-leaks (при использовании комманд копирования и изменения вектора, отличной от clear). Но это на данный момент не используется! Более того, написав copy constructor и operator=, я потеряю в скорости, т.к. будет происходить как минимум 2 НЕ ОБЯЗАТЕЛЬНЫХ копирований строки (от одного можно избавиться, но не от второго ).
[hr]

Сообщение от alexey_ma

Ты создал структуру (назовем его ts), при попытке добавления это структуры в в вектор создается новый обьект (назовем его ts1) , в ts1 копируется ts. Поскольку копи-конструктора у тебя нет, то копируется плоско - тоесть ПОБАЙТНО. В итоге получаем две структуры содержащие указатель на одну и ту-же область памяти. Для обеих структур вызывается деструктор (не обязательно при удалении из вектора, у тебя просто обьекты выходят из скопа, то есть кончается их время жизни) и пытается дважды освободить один и тот же указатель. В итоге креш.

Ну это я знаю и имею ввиду. Только, кажется, ваше объяснение НЕ подходит. Я же писал:

Сообщение от Crazy_kettle

переменная s и вектор vec ещё используются (не говоря уже об области видимости)

Сообщение от Crazy_kettle

Более того, как для переменной s, так и для vec.back(), он(деструктор) явно не вызывался, т.к. s.str==vec.back().str!=0.

Более того, ту возможность, о которой вы писали, я предусмотрел:

Сообщение от Crazy_kettle

s.str=0;//Чтобы деструктор не пытался освободить память повторно.

Да при окончании программы вызывается деструктор для строки. Но т.к. s.str==NULL, то ф-ция free(s.str) НИЧЕГО не делает, а, значит, можно считать, что для структуры s деструктор вовсе отсутствует .
Не предусмотрел я то, что при реализации vector:ush_back может создаваться временный объект (что вы категорически отрицаете) и для него вызываться деструктор, который всё портит. Я не виню за это программистов Microsoft, это их дело как писать свои процедуры.

Сообщение от alexey_ma

И писать надо не как умею, а как того требуют правила языка. Не стыдно быть чайником - стыдно им оставаться.

Почему-то мне, кажется, что изучать новые средства лучше на простеньких программках. Т.к. в нормальных возможны большие проблемы с отладкой, из-за чего получается «кривой» код (т.к. переписывать с нуля влом).
[hr]

Сообщение от Crazy_kettle

Да похоже программисты Microsoft что-то с STL перемудрили и действительно где-то у них создаётся временный объект. Хотя это мне кажется странным, т.к. для больших объектов из-за этого скорость должна сильно упасть!!!!!!

Сообщение от PSyton

Уважаемый, MS тут не причем. STL он и в Африке STL.

Кажется, Вы меня не правильно поняли. Я не скидываю свою вину по написанию неправильного кода на программистов MS. Пусть пишут как хотят, как умеют, и как думают они (не я). Да у меня был баг и я его поправил.
Интересует меня другое. Я ведь всегда думал, что STL разрабатывалась/писалась так, чтобы обеспечивать максимальное быстродействие. Только вот зачем нужно создавать временный объект? (конечно, программистам MS виднее, но разработчики библиотеки, поставляемой с g++ 3.4.4, обошлись же без этого). И это, имхо, создание временного объекта может отнимать уйму времени (если этот объект очень большой). Не зря же объекты передаются по ссылке ?!