Даже смарт пойнтеры? Сомневаюсь. Что касается "кушания памяти" и тормозов, то это в 99% случаев неправильное использование контейнеров или использование вообще не тех контейнеров, а также ненаписание своих аллокаторов памяти там, где это даст большой эффект. Нет, я не спорю, что собственноручно написанный велосипед будет работать быстрее, если руки откуда надо растут, но он не будет универсальнее, плюс на его написание будет потрачено время, а время - как известно деньги.
как правило, не использующие stl и boost просто херово в ней разбираются, и по умолчанию считают себя умнее алекса степанова и иже с ним. а по поводу неэффективности boost'а - я, например, видал людей, которые не хотели использовать c++ вместо c, потому что он неэффективен, правда затруднялись показать механизмы c++, которые неэффективны
потому что буст писан очень неглупыми людьми. он часто избавляет от проблем выдумывания интерфейсов и позволяет ценой небольших дополнительных усилий правильно организовать программу. также он позволяет здорово повторно использовать код. вот реальный пример - чтобы использовать named pipe я написал pipe_stream вместо прямого использования ReadFile, WriteFile. что мне это дало? я смог практически бесплатно задействовать бустовскую сериализацию. в случае более 100 сериализуемых типов, некоторые из которых содержат stl контейнеры мне сериализация не стоила ничего. как потенциальнаую выгоду я рассматриваю то, что могу легко сменить транспортный уровень, просто написав другой стрим. конечно, для небольших проектов выгода менее очевидна
Я хоть и не большой любитель наворотов C++ в виде STL и Boost Library, но, по-моему, это очевидно, что они помогают в разы ускорить написание программы путём незначительного повышения расхода памяти/процессорного времени. И уверяю вас, что STL, Boost и другие опенсорсные решения активно используются в больших проектах, поскольку оверхед незначителен, однако, это сильно экономит время. А, как уже сказали, время это деньги.
Не хотел ввязываться в холивар, но не удержался. Всё равно бессмысленно что-то доказывать человеку с предвзятым отношением. На сем умолкаю, и, пожалуй соглашусь с _DEN_
_DEN_ троль пока что только ты) по факту ничего кроме "попкорна" и "толсто" не сказал)) Ezrah у меня предвзятое отношение? ок, отбрасываем map берем boost asio который все так любят сколько он там весит ? метр с кепочкой в архиве топаем в wiki и читаем что такое реактор и за часик набросаем простенький код на 60кил универсального реактора для unix/win платоформы 60кил и метр с кепочкой буст асио в архиве = есть с чем сравнить ps да еще забыл за сокет+буффер+чего то там = 120 кил равноценной замены буст асио
сорвал покровы, показал всё что скрыто. весь код asio уменьшается в 500 строк, а остальное i = 0; i = 0; а все как слепые котята, ей-богу
sergegers сходите расскажите на http://sourceforge.net/projects/asio/files/ где сечас asio занимает 5.4 М в архиве, о том что они бараны и не умеют программировать а у какого то sergegers asio занимает всего 500 строк хотя ректор да - занимает приблизительно 500 строк, час писанины. вообщем то болтовню я заканчиваю) толку то? если из участвующих даже qt v "1.0" никто не застал а с пеной у рта доказывают что boost ихнее всё (: Ezrah sergegers свет вам да любовь) больше реверсите и смотрите во что в итоге разворачиваются горячо вами любимые библиотеки (:
--- База! База! Прямо по курсу - баттхерт! Повторяю: прямо по курсу - баттхерт! База, как слышно, ответьте!
Да это ещё что. Это фигня. Из уст C++ программистов так часто доносятся какие-то глупости, что они даже не удивляют. Мне как-то один деятель доказывал что javascript изучать бессмысленно, javascript -- фигня, а вот jQuery рулит. Вот это было действительно круто. Мы втроём разубеждали его в его заблуждении. И еле-еле справились.
Если посмотреть содержимое того архива, отбросить все лишнее, оставить только код asio и выкинуть из него все комментарии и снова запаковать, то вряд ля там будет больше чем 100 Кб архив Тем более там не один класс для асинхронных сокетов, а куча всего остального. qt 1.0? Не помню такого мастодонта, я наверно еще в школу тогда ходил, а вот qt 2.0 уже застал
интересно посмотреть на мапу в вашей реализации. Как Вы за пару минут реализуете работу с красно чёрным деревом.. Неужто действительно всё так тривиально получится.. Мне нужна мапа std::map<size_t, size_t>. Как обойтись без красно чёрного дерева или как его "легко" реализовать, я не представляю.
Легко можно обойтись, если не нужно упорядочивание элементов в контейнере. Обычная хэш-таблица решает эту задачу.
И какого размера должна быть хеш таблица, вы не подумали? Кроме того, упорядочивание элементов необходимо.
srm По-любому меньше дерева. Поскольк меньше накладных расходов на хранение указателей. Значит ты попал. Придётся тебе до конца жизни использовать лишь красно-чёрные деревья из C++. Прими мои соболезнования, и не переживай сильно. Говорят не так уж и страшен чёрт как его малюют. Живут же люди программируя на C++? Живут, и ничего. И ты притерпишься. Всё будет хорошо.
С грамотным аллокатором ~12*N байт на 32-битной системе. И кстати, можно еще использовать сортированный вектор, если нужно упорядочивание, нет частых изменений структуры, но часто нужен поиск данных. И это будет уже максимально эффективно по используемой памяти (~8*N байт). Под каждую конкретную задачу есть подходящая структура данных, их надо знать и уметь применять.
Если нет частых добавлений, но надо упорядочивание, то можно скомбинировать хэш-таблицу указателей на объекты и связный список из этих объектов. Добавление - долго, поиск и удаление - моментально.
