Здравствуйте, ., Вы писали:
.>Ага, я тоже так и не понял. Мало того, выяснилось, что хаш-таблица слегка тяжелее мапа, т.к. помимо самих строк, .>хранятся ещё и хеши. А разница лишь в сложности поиска по ключу.
А почему должна быть тяжелее?
Казалось бы в хэш-таблице надо хэши хранить (хотя это и не обязательно, кстати), а в std::map надо дерево организовывать...
Кроме того, даже если хэши и хранить, то их можно хранить отдельно, компакто, что лучше ложится на современные архитектуры с многоуровневым кэшированием памяти...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Андрей Тарасевич, Вы писали:
АТ>>В этом Страуструп не столько "не прав", сколько допускает черезмерное упрощение, ориентируясь на начинающего программиста (его книга изобилует такими упрощениями).
I>Да? А можно ссылку, где Страуструп в этом признался? И может где-нибудь есть список "таких упрощений" Страуструпа?
а зачем тебе ссылка?
Просто возьми его книжку и стандарт и сравни.
Здравствуйте, Erop, Вы писали:
E>Есть намного более разумно обустроенные библиотеки контйнеров, вообще-то. Ориентированные на реальные сценарии, а не так как в std::basic_string. Они, INHO лучше чем STL...
E>Всё таки в сравнении познаётся...
Еслия правильно помню, ты говоришь о библиотеке, которую сам и написал?
Наверное, в твоей библиотеке вектор можно проитерировать за O(log(N)) или даже за O(1), в отличие ориентированного не на реальные сценарии std::vector?
Здравствуйте, 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>А вот если мы говорим про пополнение вектора векторов, например, то уже интересное обсуждение начинается...
Здравствуйте, Erop, Вы писали:
E>STL лучше чем ничего, конечно. И лучше безумных коллекций со встреонными в них иетраторами. E>Но, если воспринимать STL, именно как библиотеку колелкций, то он явно очень слабый и недоделанный (смотрите буст тот же, в конце концов). И сделан как-то так, "грубой силой оптимизирующего компилятора".
Ну недаделность — это факт, да и устарела STL сильно. Ей уже больше 10 лет, как-никак. Я воспринимаю STL скорее как "руководство к действию" для создания коллекций.
Здравствуйте, jazzer, Вы писали:
J>Имя, сестра! Имя!
Приватные конторские и моя любимая биюлиотека.
E>>А вот если мы говорим про пополнение вектора векторов, например, то уже интересное обсуждение начинается...
J>
Это если ты сам можешь всю работу за контейнер сделать и предугадать заранее что кому когда и как.
Тогда и встроенный С'шный массив справится...
А вот если ты не знаешь какой 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.
Здравствуйте, 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-у.
Здравствуйте, Symon, Вы писали:
S>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы?
Дело не в STL, а в синтаксисе шаблонов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, jazzer, Вы писали:
J>твоя любимая библиотека общедоступна?
AFAIK, нет, во всяком случае пока. Она самописная (не совсем "само", но группой товарищей) и так и называется MFL
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LaptevVV, Вы писали:
S>>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы? LVV>Дело не в STL, а в синтаксисе шаблонов.
IMHO они органично оба в паре работают на дело снижения читабельности
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, LaptevVV, Вы писали:
S>>>Интересно, кто-нибудь ещё кроме меня считает, что в целом семантика STL не способствует читаемости программы? LVV>>Дело не в STL, а в синтаксисе шаблонов.
E>IMHO они органично оба в паре работают на дело снижения читабельности
Предлагаю сойтись на том что "это заговор", и закрыть тему Ибо уже не возможно это читать, а каждый раз интересно почитать мнение "отцов форума"