Здравствуйте, WiseAlex, Вы писали:
WA>навеяло про boost::lexical_cast и схожие темы.
WA>Знаю что баян, но ответа так толком для себя не сформулировал.
WA>Возьмем к примеру std::vector. Требует copy ctor и потому часто приходится держать в нем shared_ptr. Наверное будет move ctor в будущем. Но непонятно другое — 95% (а может и больше) применений вполне обошлись бы простым realloc. Почему было не предоставить пользователю право выбора?
WA>аналогично с deque и размером непрерывной области.
realloc будет работать только для POD. И, вообще говоря, нет принципиальной проблемы сделать соответствующую специализацию std::vector для подов, чтоб она делала именно realloc, так что ты проверь, вдруг в твоей реализации STL это уже сделано.
Но shared_ptr — это не POD, и применять к нему realloc нельзя.
P.S. У тебя 95% типов в программе — поды?
WA>Может есть какие-то глубинные причины и я просто туплю, но я не понимаю почему я должен платить за тот выбор который мне не подходит?
Спокойнее, ты никому ничего не должен
Я вот не могу одного понять — что, в стандарте написано что-то вроде "использование контейнера/алгоритма не из STL — undefined behavior"?
Подходит для твоих целей — используй на здоровье.
Не подходит — используй своё.
А то каждый второй приходит на форум и выступает, что, мол, STL не дает мне использовать мой супер-контейнер или там запрещает писать цикл for( ; ; )
