Классы: как правильно заполнить std::vector?

По ходу m_pSL выходит из области видимости. Куда его впихнуть?

Это сообщение отредактировал(а) Alca - 20.3.2009, 18:23

1) std::vector< const std::auto_ptr<TStringList> >
2) std::vector<boost::shared_ptr<TStringList> >
3) boost::ptr_vector
4) свой класс, подменяющий std::vector, хранящий указатели с выделенной памятью и вызывающий delete для указателей, которые из него удаляются

Alca, А m_pSL тебе и не нужен. Ты же адреса запомнила. Значит и восстановить можешь.

Добавлено через 54 секунды

Да. Или сама освобождай память.

Alca, 
при выходе из области видимости исчезает переменная m_pSL, но не выделенный блок данных, на который она указывала. В деструкторе класса TfrmMain не забудь почистить вектор.

std::vector< const std::auto_ptr<TStringList> >
 Здесь была могилка этой программы. :gigi:


Это сообщение отредактировал(а) Rififi - 20.3.2009, 18:51

  сотри быстро 

Значит можно так?:


Это сообщение отредактировал(а) Alca - 23.3.2009, 12:27

Alca, а в чем прикол тогда вектора? Автоматически чистить не будет - ИМХО auto_ptr мне кажется лучше.

очень просто


Добавлено через 2 минуты и 5 секунд

еще один камикадзе?  

Anikmar, нельзя auto_ptr'ы в контейнеры класть. Тебе же vinter сказал   

Честно говоря я никогда не использовал auto_ptr - как-то привык сам за собой убирать. Но в данном конкретном случае чем плох такой подход? Почему нельзя?

auto_ptr нарушает семантику присваивания, которе сплошь и рядом в каждом контейнере

Так что ли???

На примере можно? Что-то я не полнял.

Мейерс: "При копировании auto_ptr право владения объектом, на который ссылается указатель, переходит к копии, а исходному указателю присваивается NULL."
А вообще компилятор должен ругать и отказываться компилировать за попытку положить в контейнер auto_ptr.

Мда, не знал. (Правда думаю узнал бы сразу - как только использовать бы начал, было бы разочарование) - я для себя предполагал, что auto_ptr наиболее удобен как раз для векторов - когда нужно те объекты хранить, которые только через new создаются.

Спасибо, буду знать на будущее.

Поругать может, но отказываться компилировать - нет. Вдруг мне нужна именно такая логика?

zim22, опять же цитата из Мейерса: "Контейнеры auto_ptr (COAP, Containers of auto_ptr) запрещены, а программа, которая попытается их использовать, не будет компилироваться. Комитет по стандартизации С++ приложил неслыханные усилия в этом направлении."

Добавлено через 5 минут и 46 секунд

9 студия не компилирует. Говорит нет конструктора копирования.

действительно. вот облом 

Так так можно делать?

Ответь - ЗАЧЕМ?
Где это нужно?
Какой злой гений попросил тебя это вытворять с VCL? 

То что ты делаешь - это масло маслянное. Более того вообще не рекомендуются смешивать VCL и STL. 
Ты спросишь почему - а я тебе отошлю к  Холингверту, Баттерфилду и их пацанам.

Ну мне кажется это слишком категорично. Неужели vector<TDateTime> тоже не надо использовать? Некоторые простые классы почему нельзя в вектор запихивать?

Тут заметил одну интересную фишку...
А что, BrainBench совсем испортился, что за такие вещи (std::vector< const std::auto_ptr<TStringList> >) теперь уже звание Master C++ дают?   

Пусть это будет на совести авторов. Они были убедительны.   

А зачем? У VCL полно своего инструментария. Я лично никогда не мешаю бормановские классы со стандартными. Как то спокойнее. Да и необходимости в этом не вижу.

У меня так как правило само собой получается, но этот конкретный пример я привел из своей практики - ну понадобился мне массив дат. Причем размер изначально непонятный, в процессе работы меняется. Что вы мне порекомендуете из стандартных средств VCL? Может я просто чего-то не знаю. TList? Неудобно - чистить надо.

Второй момент - собственные классы, в состав которых входит та же дата либо еще какой-нибудь объект VCL. Тоже иногда вектор вполне подходит. Просто если такие ограничения действительно аргументированы - то надо к ним прислушаться. А если из разряда "неаккуратненько как-то" - то это чисто на вкус и на цвет.

mrbrooks, у всех свои тараканы, я вот например не стану юзать QT'шные поделки, которые есть в STL, хотя и использую QT. В этом нет ничего плохого 

а нельзя просто вычислить индекс в StringList, например тебе нужна структура данных их 3х стринг листов, каждый из которых содержит 10 строк, тогда просто создаешь 1 StringList на 30 строк, 0-9-й элементы, это условно 1-й stringlist, 10-19й - 2-й, с 20-29й - 3-й StringList

vinter, за QT ничего не скажу. Не стал бы я в этом плане сравнивать VCL и QT   


Его родимого. Можно TBaseArray, TValueArray. Насчет чистки - ну а кто сказал что будет легко.   


Авторы были убедительны. Правда речь шла о шестом Бормане - но сомневаюсь я что  что - то изменилось. 

Вот и я про то же. Зачем изобретать велосипед? Если приложение однозначно должно работать без VCL, то все понятно. Но почему объекты VCL нельзя запихивать в vector - для меня загадка. Vector - обычный шаблон и в нем вроде как нет ничего особенно такого, чтобы нельзя было применить конструкцию vector<TDateTime>.

Проведу аналогию (господи, только бы к баяну не привел мой пример), использовать конструкцию while(true){..... только чтобы вместо goto использовать break. Лично я не вижу здесь никакой красоты и понятности, наоборот - дополнительный отступ, лишние переносы, следить лишний раз за скобками.

Поэтому интересно было бы услышать действительно весомый аргумент: Не рекомендуется использовать vector<TDateTime> потому, что это может привести к таким-то отрицательным моментам:.......

еретик    

Я так и знал     

Сейчас пролистываю мануал в поисках - в чем же загвоздка совместного использования - найти не нашел - но строгие указатели применяются авторами к объектам VCL на лево и на право.  

Добавлено через 57 секунд

  

Поверь, это не из за "боязни" использoвать goto.

Думаю все дело в конкретных случаях. Ведь молотком надо гвозди забивать, но с дури можно и шурупы. Просто надо четко предстовлять себе как работает vector, сколько он сделает вызовов конструктора копирования, сколько создаст временных объектов и т.п.

Достаточно много примеров неумелого использования шаблонов, а потом авторы кричат - полная лажа этот STL. А на самом деле просто неправильно пользуются. Лично видел один код, когда автор потратил уйму времени на создание конструкторов копирования, операторов присваивания для класса,  котором было больше полусотни полей, причем часть из них стркутуры. Когда он все это запихал в вектор, да еще размером больше 100 тысяч элементов и получил ужасающие тормоза, он начал кричать, что STL писали полные ламеры и никакой оптимизации алгоритмов там нет. Он очень удивился, когда узнал, что через указатели все это делается гораздо проще и летает круче самолета.

Добавлено через 3 минуты и 31 секунду
  


  
goto здесь не обсуждаем! Это был пример! 
Никто goto не должен боятся - он мирный и не кусается!
  

Обсуждаем опасность конструкции vector<TDateTime>

Почему я должен использовать TList в данном случае. И что будет плохого, если все-таки использую vector. Вопрос не праздный - я действительно использовал vector<TDateTime> и если это опасно - я срочно переделаю код, пока помню где это.

Хочу знать: почему опасно?

Про нечто подобное и писали авторы. 


Я честно говоря таких не встречал. Наоборот в STL сила С++ имхо.

Добавлено через 1 минуту и 9 секунд
По памяти вспомнить не могу - давно читал - но помню два слова относительно VCL - осторожно и Дельфи.

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

Если вспомните, скажите пожалуйста. Очень интересно, если честно.

Предполагаю из за бинарной совместимости, std::vector не рекомендуется передавать между приложением и библиотекой. 
насчет VCL не знаю есть ли, но по идеи они должны гарантировать совместимость для "своих" типов. 

Это сообщение отредактировал(а) mes - 23.3.2009, 16:41

Что значит бинарная совместимость? Ведь объект vector создается налету - как же он бинарно может быть не совместим? Копипастим vector и делаем его нешаблонным, что изменится?

отсутствие бинарной совместимости означает что в двух приложениях(откомипилированных разными компиляторами или разными версиями одного) один и тот же объект (vector) , будет иметь разную  бинарную структуру и в таком случае передавать объект одного другому приложению нельзя.

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

Это сообщение отредактировал(а) mes - 23.3.2009, 16:55

Ну так можно сказать про любой класс. Почему это только на вектор распространяется? Ведь любой класс, откомпилированный разными компиляторами (да даже и одним и тем же с разными настроуками выравнивания) может оказаться бинарно несовместимым.

вектор был для примера, речь идет о библиотеках в целом : std и VCL
первый абзац :
http://qt.osdn.org.ua/binarycompat.html


Это сообщение отредактировал(а) mes - 23.3.2009, 17:10

Как можно в VCL работать с динамическими массива любого типа?

Это сообщение отредактировал(а) Alca - 23.3.2009, 17:38

успокойся, это НЕОПАСНО. Можно использовать VCL и STL вместе. И с boost можно. Никаких противопоказаний нет. Требования к VCL классам такиеже как и к обычным классам при использовании с STL.
Другое дело, что в лит-ре встречаются рекомендации наподобии:
"если Вы используете какую-то библиотеку, то пользуйтесь ею по-максимуму" 
т.е. если вы пользуетесь VCL, то используйте ее динамический массив (совсем необязательно TList, который нешаблонный и хранит указатели и нужно кастить). В VCL есть вроде как шаблонные классы что-то типа DynamicArray<> и они вполне адекватная альтернатива STL.

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

Имхо, этот в вопрос лучше задать в ветке по борланду. 
интуитивно предполагаю, что это должен быть TArray<>

Это сообщение отредактировал(а) mes - 23.3.2009, 17:54

ИМХО
STL входит в стандарт языка (думаю boost тоже войдет). 
Касаемо других библиотек - согласен. Но STL - это уж вроде как незыблемо.

А вот аналога vector я в VCL не знаю, если честно.

А в MFC (CLR) есть? 

глупый совет

Вообще-то билиотека в обычном понимании - библиотека объектных модулей и библиотека стандартных шаблонов это принципиально разные вещи.

Может из-за этого путаница? В библиотеке STL при использовании vector не используются никакие бинарные объекты - все рождается на этапе компиляции. На то это и шаблоны. Может в boost есть отдельные функции, которые находятся в библиотеке в двоичном виде, но само название STL говорит, что это не более чем набор заголовочных файлов с шаблонами.

Я чета не понял.    Кто-нибудь читал тему топика? 

а зачем?   

нету никакой путаницы. Помоему ты слишком близко к сердцу все это принимаешь...


а чего его читать? По существу вопроса достаточно первых 5-6 сообщений. 
Дальше народ использует возможность блестнуть эрудицией. Так что не мешай... 

   Если это так выглядит то нет, просто интересно.

Если есть вещь, которую я использую, но оказывается не все про нее знаю - интересно выяснить.

А вообще-то на пустом месте баян получился   

на то и пустое место -  было бы что интересного по теме, текло бы нормальное обсуждение