Вот, сегодня обнаружил такой неприятный факт, что объекты с константными полями нельзя помещать в std::vector, потому что в его недрах используется оператор присваивания.
Вот и приходится решать мучительный вопрос, то ли не использовать константные поля, то ли вот так извращаться:

Обидно и непонятно. Этого, что, предусмотреть не могли? Обязательно operator=() в векторе надо было использовать? Я понимаю, что можно в исходники залезть и понять, что на самом деле все круто, и, раз умные дядки так сделали, то так и надо. Но времени туда залазить нету...

Это сообщение отредактировал(а) SaDFromSpb - 9.12.2006, 20:14

а что ещё? Это семантика языка - никуда не деться.

Daevaorn, Нет, я все-таки не понимаю. Оператор присваивания может пригодиться, когда старое содержимое вектора копируется в новое место при увеличении его объема. Но и в этом случае можно (а это будет и логичнее) обойтись конструктором копирования.
Хотя для этого они по-ходу все таки используют копирование:

Отваливается при первом push_back'e (видимо при ресайзе)
Зачем они так поступают? (Кстати, это цитата из файла stl_algobase.h, то есть vector для переразмещения вызывает некий общий метод для контейнеров...)

А может в других реализациях STL делают по-другому? У меня STL от gcc 3.3.3.

Это сообщение отредактировал(а) SaDFromSpb - 9.12.2006, 20:39

По стандарту теребования для объекта, чтобы он мог применяться в контейнерах: CopyConstructible и Assignable. Объеты содержащие const члены данных не являются Assignable.
Решение - храни в контейнере указатели в какой-нибудь оболочке(т.е. "умные указатели")

Понятно, надо было читать главу о контейнерах в целом =)
Как в все-таки много в этом языке всяческих нюансов, я просто поражаюсь! Вот уже больше года работаю и все поражаюсь... Может я тупой? =)))

Это сообщение отредактировал(а) SaDFromSpb - 9.12.2006, 20:56

Интересно, какой смысл запрещать копирующее присвоение для объектов, предназначенных для хранения в контейнере-последовательности? :-)
Вероятно, тут достаточно всего лишь по-людски обеспечить неизменность key:



Это сообщение отредактировал(а) UnrealMan - 9.12.2006, 21:41

UnrealMan, Хм.. Ну можно и так конечно =) Просто там в коде очень много всего, и хотелось отдельные классы как можно компактнее описывать. К тому же операций с этой структурой будет очень-очень много. - Будет время теряться из-за доступа через метод (хотя... в методе можно константную ссылку возвращать, а не копировать int ...).
Принципиально проблем у меня с этим нет. Просто одна вещь удивила и все. Вообще я там с const_cast намудрил конечно =)) В таком случае уж точно лучше с помощью private делать...

SaDFromSpb, может использовать mutable?
СТОП!!!! гоню!!!!

Это сообщение отредактировал(а) zabivator - 10.12.2006, 23:00

Нет большого смысла делать данные-члены класса константными. С точки зрения скомпилированного кода - вообще никакой. С точки зрения защиты - сделай private, внутри класса уж как-нибудь проконтролируешь. Если речь идет о "совсем" константах - используй static или enum.
Кроме того, концепция copy-constructable подразумевает и адекватно-реализованный оператор присваивания.
Если не требовать (в контейнерах STL) оператор присваивания, то придется требовать конструктор по умолчанию (для реализации некоторых операций), что гораздо хуже...
Смирись и привыкай: объекты, которые хранятся в контейнерах должны иметь семантику значений (т.е. быть copy-constractable). И вообще, удобства, предоставляемые STL (а также boost), требуют некоторых самоограничений. В конечном итоге это только улучшает дизайн.

+1!!!