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

.>Ага, я тоже так и не понял. Мало того, выяснилось, что хаш-таблица слегка тяжелее мапа, т.к. помимо самих строк,
.>хранятся ещё и хеши. А разница лишь в сложности поиска по ключу.

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

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

I>Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>>В этом Страуструп не столько "не прав", сколько допускает черезмерное упрощение, ориентируясь на начинающего программиста (его книга изобилует такими упрощениями).

I>Да? А можно ссылку, где Страуструп в этом признался? И может где-нибудь есть список "таких упрощений" Страуструпа?
а зачем тебе ссылка?
Просто возьми его книжку и стандарт и сравни.

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

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

E>Есть намного более разумно обустроенные библиотеки контйнеров, вообще-то. Ориентированные на реальные сценарии, а не так как в std::basic_string. Они, INHO лучше чем STL...

E>Всё таки в сравнении познаётся...

Еслия правильно помню, ты говоришь о библиотеке, которую сам и написал?
Наверное, в твоей библиотеке вектор можно проитерировать за O(log(N)) или даже за O(1), в отличие ориентированного не на реальные сценарии std::vector?

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

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

J>Если я правильно помню, ты говоришь о библиотеке, которую сам и написал?
J>Наверное, в твоей библиотеке вектор можно проитерировать за O(log(N)) или даже за O(1), в отличие ориентированного не на реальные сценарии std::vector?

Я пользуюсь несколькими библиотеками контейнеров. Все лучше STL.
А про итерацию вектора -- это ты наверное иронизировал?
Или я тебя не понял.
А вот если мы говорим про пополнение вектора векторов, например, то уже интересное обсуждение начинается...

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

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

J>>Если я правильно помню, ты говоришь о библиотеке, которую сам и написал?
J>>Наверное, в твоей библиотеке вектор можно проитерировать за O(log(N)) или даже за O(1), в отличие ориентированного не на реальные сценарии std::vector?

E>Я пользуюсь несколькими библиотеками контейнеров. Все лучше STL.

Имя, сестра! Имя!

E>А про итерацию вектора -- это ты наверное иронизировал?
E>Или я тебя не понял.
E>А вот если мы говорим про пополнение вектора векторов, например, то уже интересное обсуждение начинается...

std::vector< std::vector<int> > vv;
vv.reserve( XXX );
vv.push_back( std::vector() );
vv[0].reserve( YYY );
vv[0].push_back( 5 );

reserve по ситуации, естественно

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

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

E>STL лучше чем ничего, конечно. И лучше безумных коллекций со встреонными в них иетраторами.
E>Но, если воспринимать STL, именно как библиотеку колелкций, то он явно очень слабый и недоделанный (смотрите буст тот же, в конце концов). И сделан как-то так, "грубой силой оптимизирующего компилятора".
Ну недаделность — это факт, да и устарела STL сильно. Ей уже больше 10 лет, как-никак. Я воспринимаю STL скорее как "руководство к действию" для создания коллекций.

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

J>Имя, сестра! Имя!
Приватные конторские и моя любимая биюлиотека.

E>>А вот если мы говорим про пополнение вектора векторов, например, то уже интересное обсуждение начинается...

J>

J>std::vector< std::vector<int> > vv;
J>vv.reserve( XXX );
J>vv.push_back( std::vector() );
J>vv[0].reserve( YYY );
J>vv[0].push_back( 5 );
J>

J>reserve по ситуации, естественно

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

А вот если ты не знаешь какой reserve сделать, тогда вся мощь контейнеров STL становится видна миру
Убогая недоделанная переусложнённая поделка прошедших веков...

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

E>А вот если ты не знаешь какой reserve сделать, тогда вся мощь контейнеров STL становится видна миру
E>Убогая недоделанная переусложнённая поделка прошедших веков...
Если ты не можешь сделать reserve — тебе в любом случае придётся делать какой-то вариант экспоненциального увеличения буффера.

Тебе в любом случае как-то придётся делать копирование/перемещение элементов из старой коллекции в новую.

Единственный минус STL — она не поддерживает перемещаемые объекты, ей приходится их всегда копировать.

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

C>Единственный минус STL — она не поддерживает перемещаемые объекты, ей приходится их всегда копировать.
О чём и речь...
Но это довольно существенный минус, IMHO.
Кроме того он не единственный.

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

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

E>>А вот если ты не знаешь какой reserve сделать, тогда вся мощь контейнеров STL становится видна миру
E>>Убогая недоделанная переусложнённая поделка прошедших веков...
C>Если ты не можешь сделать reserve — тебе в любом случае придётся делать какой-то вариант экспоненциального увеличения буффера.

ну либо воспользоваться std::deque.
Это при условии, что не нужно последовательное размещение элементов в памяти, естественно.

C>Тебе в любом случае как-то придётся делать копирование/перемещение элементов из старой коллекции в новую.
+1

C>Единственный минус STL — она не поддерживает перемещаемые объекты, ей приходится их всегда копировать.
Это в "поделке прошедших веков" так
А уже в текущем драфте стандарта красным по белому перечеркнуто требование "T is CopyConstructible".
И, естественно, все методы вставки принимают ссылки на rvalue.

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

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

E>2) Во многих случаях было бы, IMHO, последовательно, для всяких действий использовать внешине функции.

Согласен. И думаю даже, что возможно через какое-то время появится рекомендация по возможности использовать даже друзей, но не члены. Для меня это последовательное продолжение рекомендации по возможности не делать функции членами. Иначе сначала у нас функция f выражается в терминах функции g, и потому f — не член, g — член; потом дизайн класса меняется, и наоборот g выражается в терминах f, соответственно f становится членом, а g — нет; и всем клиентам приходится переходить на новый синтаксис.

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

>> например qt... когда станет свободной
v_m> билл гейтс будет против
А владельцев QT никто не спросит?

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

J>а зачем тебе ссылка?

Просто рекомендация Страуструпа по возможности использовать int даже если отрицательные значения не используются мне в свое время не понравилась. И вот, хочу поторжествовать.

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

I>Просто рекомендация Страуструпа по возможности использовать int даже если отрицательные значения не используются мне в свое время не понравилась. И вот, хочу поторжествовать.

Ну дык верная рекомендация-то...

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

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

J>>Имя, сестра! Имя!
E>Приватные конторские и моя любимая биюлиотека.
твоя любимая библиотека общедоступна?

E>Это если ты сам можешь всю работу за контейнер сделать и предугадать заранее что кому когда и как.
E>Тогда и встроенный С'шный массив справится...
ну контейнер еще много чего делает, кроме угадывания своего размера.

E>А вот если ты не знаешь какой reserve сделать, тогда вся мощь контейнеров STL становится видна миру
E>Убогая недоделанная переусложнённая поделка прошедших веков...
см. мой ответ Cyberax-у.

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

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

S>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?
Дело не в STL, а в синтаксисе шаблонов.

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

J>твоя любимая библиотека общедоступна?
AFAIK, нет, во всяком случае пока. Она самописная (не совсем "само", но группой товарищей) и так и называется MFL

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

S>>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?
LVV>Дело не в STL, а в синтаксисе шаблонов.

IMHO они органично оба в паре работают на дело снижения читабельности

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

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

S>>>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?
LVV>>Дело не в STL, а в синтаксисе шаблонов.

E>IMHO они органично оба в паре работают на дело снижения читабельности
Предлагаю сойтись на том что "это заговор", и закрыть тему Ибо уже не возможно это читать, а каждый раз интересно почитать мнение "отцов форума"

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

E>Ну дык верная рекомендация-то...

Так ведь это упрощение.