привет

нормально ли так делать?

а зачем тебе это?
да и выглядит как-то убого..  

Ничего плохого не вижу.
Для работы с динамической памятью посоветовал бы еше добавить const auto_ptr, чтобы избежать возможных проблем с утечками памяти.
А для какой задачи это тебе нужно.
В стандартной библиотеке есть специальные контейнеры для булевых величин.

один из них как раз и есть vector<bool>   

плохо воспринимается 

Это сообщение отредактировал(а) zkv - 14.4.2007, 13:30

Зато удобно используется.
Ну используй typedef.





  
А точно, специализация.
Второй это bitset.

на самом деле vector<bool> - плохо.
Нужно избегать vector<bool>. Это не контейнер STL и он не содержит bool....

В требованиях стандарта говорится, что если v контейнер объектов T , с оператором [] , то должно компиллится

но с bool такая конструкция не скомпилится. vector<bool> - это псевдоконтейнер. 

спасибо,

меня еще немного напрягает


я думаю наверно лучше всего использовать





Это сообщение отредактировал(а) Woo - 15.4.2007, 00:07

а чего не синхрофазотрон?

Имхо - нафиг. Слишком много граблей будет да и читабельность...


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

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

По начальному вопросу - кроме громоздкого объявления, проблем не вижу. Можно, как предлагали, сделать typedef разве что.

Обоснуй, пожалуйста.
В c++ есть по крайней мере 2 бича - приведение типов и проблемы с памятью (нет автоматической сборки, выход за пределы массива). Существуют даже языки, специально сделанные для устранения этих проблем (ну и для кое-чего другого), например, java.
О каких граблях ты говоришь. Если о передачи владельца, то эти проблемы снимает const. Если о читабельности - есть typedef  ,
отступы, комментарии. Мне кажется читабельность менее важна чем стабильная работа программы (отсутствие утечек памяти). Или ты имеешь в виду другой smart pointer вместо этого.
Я слышал уже такое мнение и мне интересны его причины.

Ну, во-первых, если мне понадобятся смарт-поинтеры, то я первую очередь посмотрю на boost::shared_ptr.

Про грабли с std::auto_ptr - вот не вспомню сейчас, где и у кого читал, но использование std::auto_ptr чревато очень многими граблями. Я тогда прочитал про эти грабли и для себя поставил галочку - "да, грабли опасные, auto_ptr "ф топку".
Например, передача такого ptr в функцию. И как раз const эти проблемы не снимает. Их снимает частично const&. Да и то там...

Но это далеко не все. Если как-нибудь пороюсь, то найду дли-и-инный список, почему потенциально плохо юзать std::auto_ptr.
Сейчас уже не вспомню все грабли.

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


Да, кстати, насчет typedef... А приведи-ка пример, как ты его применишь в данном случае.

нельзя хранить это в контейнерах STL. Семантика копирования у std::auto_ptr спецефическая. По стандарту это даже компиллится не должно.


не менее важна. Сопровождение длится намного дольше чем разработка

Это и не понадобится, stl контейнеры сами работают с памятью, auto_ptr там не причем.

auto_ptr p1,p2;
выражение p1=p2 приводит к модификации правой части, в этом и выражается специфика.
здесь работает механизм передачи владельца, он призван ограничить количество указателей на
1н объект.
Когда такое поведение нежелательно (с трудом представляю себе когда оно может быть желательно)
ставят модификатор const. При передаче в функцию в ее сигнатуре объявляют как const &.
Другими словами применение const auto_ptr при объявлении указателей на объект и 
const auto_ptr & при объявлении в функции должно гарантировать отстствие любых "граблей".


Нууу, если твоя программа работает в 40% ситуаций, сопровождать ее будет сложнее, чем, скажем, покопаться в не столько
самопонятном коде раз в месяц.


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

ну на счет typedef'а. что-то он слишком ного внимания получает   

typdef std::auto_ptr<ClassA> CLASSAAUTOPTR;
CLASSAAUTOPTR ptr(new ClassA);

но auto_ptr нельзя положить в контейнер.

ага... опять 25...
Кто Вам сказал, что правильность работы программы и читабельность ее - это вещи взаимоисключающие ? Код пишется в первую очередь не для компиллятора, а для человека, который будет читать его