навеяло про boost::lexical_cast и схожие темы.
Знаю что баян, но ответа так толком для себя не сформулировал.
Возьмем к примеру std::vector. Требует copy ctor и потому часто приходится держать в нем shared_ptr. Наверное будет move ctor в будущем. Но непонятно другое — 95% (а может и больше) применений вполне обошлись бы простым realloc. Почему было не предоставить пользователю право выбора?
аналогично с deque и размером непрерывной области.
Может есть какие-то глубинные причины и я просто туплю, но я не понимаю почему я должен платить за тот выбор который мне не подходит?

Здравствуйте, 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( ; ; )

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>realloc будет работать только для POD. И, вообще говоря, нет принципиальной проблемы сделать соответствующую специализацию std::vector для подов, чтоб она делала именно realloc, так что ты проверь, вдруг в твоей реализации STL это уже сделано.
а в каких есть? по-моему с оптимизацией заморачивается только stl-port

J>Но shared_ptr — это не POD, и применять к нему realloc нельзя.
J>P.S. У тебя 95% типов в программе — поды?
для большого количества типов relloc будет вполне успешно работать
у меня часто shared_ptr в векторе появляется когда необходим хранить большие типы — например std::vector<std::vector> — не виже причин по которым здесь не буде работать realloc

WA>>Может есть какие-то глубинные причины и я просто туплю, но я не понимаю почему я должен платить за тот выбор который мне не подходит?

J>Спокойнее, ты никому ничего не должен
J>Я вот не могу одного понять — что, в стандарте написано что-то вроде "использование контейнера/алгоритма не из STL — undefined behavior"?
J>Подходит для твоих целей — используй на здоровье.
J>Не подходит — используй своё.
J>А то каждый второй приходит на форум и выступает, что, мол, STL не дает мне использовать мой супер-контейнер или там запрещает писать цикл for( ; ; )
фактически я всего лишь спросил почему при проектировании stl было принято именно такое решение.
Использовать свое- это понятно . Просто удивляет, что возможность задавать аллокатор есть а других возможностей настройки нет.

Здравствуйте, jazzer, Вы писали:

J>Но shared_ptr — это не POD, и применять к нему realloc нельзя.
А почему, собственно? Какие к этому есть препятствия?

J>А то каждый второй приходит на форум и выступает, что, мол, STL не дает мне использовать мой супер-контейнер или там запрещает писать цикл for( ; ; )
Ну спрашиваете -- отвечаем

Здравствуйте, Erop, Вы писали:

J>>Но shared_ptr — это не POD, и применять к нему realloc нельзя.
E>А почему, собственно? Какие к этому есть препятствия?

если он используется в нескольких потоках (ИМХО)

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:

J>>Но shared_ptr — это не POD, и применять к нему realloc нельзя.
E>А почему, собственно? Какие к этому есть препятствия?

Потому что есть user-defined destructor (в котором, собственно, и происходит удаление объекта, без него смысла в shared_ptr немного).

J>>А то каждый второй приходит на форум и выступает, что, мол, STL не дает мне использовать мой супер-контейнер или там запрещает писать цикл for( ; ; )
E>Ну спрашиваете -- отвечаем

Не понял, пояснишь?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Потому что есть user-defined destructor (в котором, собственно, и происходит удаление объекта, без него смысла в shared_ptr немного).

можно пояснить как на это воздействует realloc ?

Здравствуйте, WiseAlex, Вы писали:

WA>Здравствуйте, jazzer, Вы писали:

J>>Потому что есть user-defined destructor (в котором, собственно, и происходит удаление объекта, без него смысла в shared_ptr немного).

WA>можно пояснить как на это воздействует realloc ?

realloc можно использовать только для подов, а тип с определенным деструктором — это не под.
По стандарту.

Естественно, в определенных компиляторах это может работать, но гарантий, понятно, никаких.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>realloc можно использовать только для подов, а тип с определенным деструктором — это не под.
J>По стандарту.

J>Естественно, в определенных компиляторах это может работать, но гарантий, понятно, никаких.

Понятно что в общем случае не POD объект не может быть просто скопирован куском памяти,
но при копировании shared_ptr никаких user-defined деструкторов вроде не должно вызываться?

Здравствуйте, WiseAlex, Вы писали:

WA>если он используется в нескольких потоках (ИМХО)
В смысле? Пример кода не покажешь?

Здравствуйте, jazzer, Вы писали:

J>>>Но shared_ptr — это не POD, и применять к нему realloc нельзя.
E>>А почему, собственно? Какие к этому есть препятствия?
J>Потому что есть user-defined destructor (в котором, собственно, и происходит удаление объекта, без него смысла в shared_ptr немного).

Ну мы вызовем деструктор у "передвинутой" realloc'ом копии. Только и всего. В чём проблема-то?

Здравствуйте, Erop, Вы писали:


E>Ну мы вызовем деструктор у "передвинутой" realloc'ом копии. Только и всего. В чём проблема-то?
Проблема только в том, что по стандарту нельзя гарантировать, что это будет работать.
Больше проблем никаких.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

E>>Ну мы вызовем деструктор у "передвинутой" realloc'ом копии. Только и всего. В чём проблема-то?
J>Проблема только в том, что по стандарту нельзя гарантировать, что это будет работать.
J>Больше проблем никаких.

IMHO -- это баг в стандарте. Есть какие-то объективные проблемы?

Здравствуйте, WiseAlex, Вы писали:

WA>навеяло про boost::lexical_cast и схожие темы.
WA>Знаю что баян, но ответа так толком для себя не сформулировал.
WA>Возьмем к примеру std::vector. Требует copy ctor и потому часто приходится держать в нем shared_ptr. Наверное будет move ctor в будущем. Но непонятно другое — 95% (а может и больше) применений вполне обошлись бы простым realloc. Почему было не предоставить пользователю право выбора?
WA>аналогично с deque и размером непрерывной области.
WA>Может есть какие-то глубинные причины и я просто туплю, но я не понимаю почему я должен платить за тот выбор который мне не подходит?

Бодатся с stl — пустая трата времени. Более продуктивно использовать свои велосипеды и настраивать их по своим нуждам.

По теме: vector для POD и вектор для обьектов — это два разных контейнера, и в одну кучу их лучше не валить.
например для вектора с POD можно делать ресайз не инициализируя данные. это уместно если, например, ты инициализируешь данные сам в цикле строчкой ниже.
для обьектов в общем случая предварительная инициализация обязательна.

vector<shared_ptr> — фейлдизайн. лучше использовать умный контейнер если это возможно.

кроме всего прочего stl была включена в стандарт в слишком сыром состоянии и теперь поезд уже ушел.
немаловажно так же, что stl разрабатывал человек с религиозной неприязнью к ООП и непонятно для кого, поэтому некоторые вещи сделаны мягко говоря неадекватно.
то что не вписалось в концепцию итераторов не было включено вообще. Например двумерные массивы. Дефолтный dictionary (std::map) использует заведомо проигрышную схему: красно-черные деревья вместо хэширования. Видимо Степанов посчитал С++ программистов неспособными написать хеш-функцию или же хеш не вписался в чистоту концепции.
Так же некоторые хорошие идеи получили отвратительную реализацию, например, аллокатор — хорошая идея, но как это реализованно? если планируется использование аллокаторов, то фактичеески любая функция должна быть шаблонной

template <class Allocator>
void get_some_data(vector<double, Allocator> &result);

это позволит использовать аллокаторы, но такую функцию уже не бросишь в cpp-файл.
Имхо, более правильным решением были бы базовые классы контейнера с виртуальными функциями выделения/освобождения памяти и несколько шаблонных реализаций с аллокаторами.
Для себя я написал велосипед постренный по таким принципам и позволяющий использовать статический буффер на борту вектора

void get_some_data(ArrayRef<double> &result);
void test()
{
   Array<double,20> res; // 20 элементов в статическом буффере, если не хватает делаем malloc
   get_some_data(res);
}

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:

E>>>Ну мы вызовем деструктор у "передвинутой" realloc'ом копии. Только и всего. В чём проблема-то?
J>>Проблема только в том, что по стандарту нельзя гарантировать, что это будет работать.
J>>Больше проблем никаких.

E>IMHO -- это баг в стандарте. Есть какие-то объективные проблемы?

баг или не баг — таково реальное положение дел.
Если у тебя есть компилятор, у которого явно прописано, в каком случае объекты можно двигать, даже если они не удовлетворяют условиям POD (у тебя есть такой компилятор?) — ради бога, пиши нестандартный код и пользуйся им на здоровье, никто не запрещает.

Объективная проблема — данные, которые могут лежать по отрицательному смещению. realloc, естественно, ничего о них не знает.
Наверняка еще можно вспомнить проблем, если подумать.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, WiseAlex, Вы писали:

WA>Здравствуйте, jazzer, Вы писали:

J>>realloc можно использовать только для подов, а тип с определенным деструктором — это не под.
J>>По стандарту.

J>>Естественно, в определенных компиляторах это может работать, но гарантий, понятно, никаких.

WA>Понятно что в общем случае не POD объект не может быть просто скопирован куском памяти,
WA>но при копировании shared_ptr никаких user-defined деструкторов вроде не должно вызываться?

а компилятору откуда об этом знать?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Объективная проблема — данные, которые могут лежать по отрицательному смещению. realloc, естественно, ничего о них не знает.
J>Наверняка еще можно вспомнить проблем, если подумать.

Мы всё ещё о буфере std::vector? Или уже о чём-то ещё? Данных по отрицательному смещению у объекта быть не может из-за того, что объекты можно складывать в массивы

Вообще-то всё ровно наоборот, я не знаю компиляторов, у которых возникнут проблемы при бинарном перемещении вектора из shared_ptr'ов...

Здравствуйте, Kluev, Вы писали:

K>...

А почему красно-черные деревья заведомо более проигрышные чем хеш таблица? Вы уверены 100%, что std::map должен был быть обязательно построенным на основе хеш-таблиц?

> то что не вписалось в концепцию итераторов не было включено вообще. Например двумерные массивы.
Почему же к таким коллекциям нельзя применить концепцию итераторов?
— итератор по одному измерению — т.е. разыменуемый в одномерный массив и итератор по одномерному массиву. Можно так же написать итератор для обхода всего двухмерного массива, кто против?
Или я чего то не понимаю?

Здравствуйте, Erop, Вы писали:

WA>>если он используется в нескольких потоках (ИМХО)
E>В смысле? Пример кода не покажешь?
Мда. внимательнее подумав — полагаю, что погорячился

Здравствуйте, jazzer, Вы писали:

J>а компилятору откуда об этом знать?
так и я об этом — пусть пользователь решает