[c++] какие контейнеры использовать?

> Это как интересно?

Не допускать копирования за пределы вектора, естественно. В результате разыменование итератора получается ссылка, так что никаких проблем при осторожной работе обычно нет. Естественно, вектор auto_ptr заводят не для того, что бы его сортировать или тому подобное.

Если использовать только STL, то вектор с auto_ptr является наиболее простым способом обеспечить автоматическое освобождение ресурсов для описанной задачи. Если доступен boost, то, конечно, вектор с shared_ptr или ptr_vector будут более подходящими решениями.

> Ну, вообще-то нужды такой нет, mv отмечался в топиках вполне вменяемо и по достаточно тонким вопросам, так что за школоту его принять затруднительно. ))

не спорю, но есть маленький нюанс - некоторые люди слишком увлекаются теорией, иногда доходит до абсурда, для примера на ЛОР есть пользователи вроде iZEN и Love5an, которые ничего на практике не умеют - но тоже «отмечаются в топиках вполне вменяемо и по достаточно тонким вопросам»; хотя я согласен, что на 99% mv и на практике совсем не новичок, но хотелось бы узнать - к чему привели его теоретические изыскания на практике и насколько оторвана теория о том, что лисп лучше всех, от «земли»

> Но я ничего не нашёл в нём радикально крутого,

синтаксический сахар, gc да пожалуй и всё

Языка лисп нет, это такое семейство довольно разных языков, так о каком лиспе ты говоришь?

Чем оно принципиально лучше явы, питона, .Net?

Если интересно, то создайте отдельную тему, хоть это уже и было проговоренно много раз. Но, для завравки, могу посоветовать посмотреть на CLOS, что бы не начинать с того, что кроме «синтаксического сахара и gc» больше и нет ничего (потом смогу предложить ещё несколько тем).

C++ это более нузкоуровневый язык, с вышеперечисленными языками

его не очень корректно сравнивать.

Что C++ плохой и т.п. здесь, кажется, говорил только lester. Никто подобных сравнений не проводит и, кажется, все вполне себе адекватно представляют (ну, опять же, видимо кроме lester) место и роль C++.

> Что C++ плохой и т.п. здесь, кажется, говорил только lester

пруфлинк или цитата?

Страшные вещи рассказываете.

Вот цитата:

лисперы так любят заходить в топики по С++ и рассказывать какой он плохой и кривой

Никто из лисперов (коих тут два) не говорил, что С++ плохой и слово «плохой», как характеристика C++ употреблял только ты, и не один раз.

> Никто из лисперов (коих тут два) не говорил, что С++ плохой и слово «плохой», как характеристика C++ употреблял только ты, и не один раз.

вы оба утверждали, что на С++ большая часть программ «течет» - так что не надо, насчет «слово „плохой“, как характеристика C++ употреблял только ты» - это детский сад, не надо мне приписывать то, чего я не говорил

> вы оба утверждали, что на С++ большая часть программ «течет»

Ну так это действительно так, будешь отрицать очевидное?. Но текут они не потому, что «C++ плохой», а потому что мало пользуются интеллектуальными указателями.

> Ну так это действительно так, будешь отрицать очевидное?

не в обиду опенсорсу будь сказано - но это больше его проблема, а также индусов на аутсорсинге, в больших долгосрочных коммерческих проектах( можешь сам вспомнить самые популярные программы ) таких проблем практически нет

Но текут они не потому, что «C++ плохой», а потому что мало пользуются интеллектуальными указателями.

еще раз, «интеллектуальные указатели» - это не С++, вон в msvc вообще gc прикрутили в качестве расширения к С++, от этого в самом языке его не появилось

> а потому что мало пользуются интеллектуальными указателями.

чтоб расставить точки над i - я повторюсь, что сам пользуюсь ими часто, но по делу, а не везде и не всегда

> еще раз, «интеллектуальные указатели» - это не С++

Я, конечно, понимаю, что здравый смысл и опыт это тоже «не C++», однако они необходимы и при программировании на C++. Язык это не только стандарт, но и накопленный опыт, и сообщество, и имеющийся набор библиотек, в общем, и дух, так сказать. И интеллектуальные указатели это одна из мощных коцепций, которая имеет смысл в основном именно в контексте C++.

в больших долгосрочных коммерческих проектах( можешь сам вспомнить

самые популярные программы ) таких проблем практически нет

Да ладно, не надо рассказывать мне сказки про превосходство коммерческого ПО. Я несколько лет писал под AutoCAD с ObjectARX - так в этом (кстати, одном из самых прибыльных коммерческих пакетов) такое г.. внутри...

Хорошо работают (и вероятно неплохо написаны) продукты, которыми пользуются десятки миллионов, ибо огромная тестовая, да армия тестеров внутри компаний тоже огромна. Так что, если говорить о продуктах MS или там Adobe, то там, конечно, на поверхности всё хорошо, но только лишь небольшая часть C++ программистов работает в этих компаниях. Остальные не нужны?

> я, конечно, понимаю, что здравый смысл и опыт это тоже «не C++», однако они необходимы и при программировании на C++

да - поэтому мои программы/библиотеки не падают и не текут, и работают значительно быстрее аналогов

Хорошо работают (и вероятно неплохо написаны) продукты, которыми пользуются десятки миллионов, ибо огромная тестовая, да армия тестеров внутри компаний тоже огромна. Так что, если говорить о продуктах MS или там Adobe, то там, конечно, на поверхности всё хорошо, но только лишь небольшая часть C++ программистов работает в этих компаниях. Остальные не нужны?

не все - но многие не нужны, ты вроде сам в свое время это понял, как и mv и т.д.

да - поэтому мои программы/библиотеки не падают и не текут,
и работают значительно быстрее аналогов

Хм, ты просил тут mv рассказать, чего он сделал, а твой код можно посмотреть? У меня из open-source на C++ есть только popen++, я правда уже давно её не трогал.

не все - но многие не нужны

Хм, предлагаешь расстрелять программистов Autodesk? Я только за, ибо у меня к ним столько претензий накопилось в своё время...

Мир не идеален, в идеальном ведь и C++ был бы не нужен, ведь он никогда не проектировался как идеальный, это скорей такой компромиссный рабочий инструмент. Есть много причин, когда мы на самом деле вынужденны использовать C++. Не стоит говорить категорично. И, кстати, что бы те же Adobe или Google могли нанять пару тысяч спецов C++ нужного им уровня, ведь для этого нужна целая армия программистов на C++. А ситуация, когда небольшая группа «ацкой элиты» остаётся без сообщества, такое как бы было в истории как раз Common Lisp, результаты не очень. Так что, либо на C++ будут писать «милионны», либо вообще никто.

> Хм, ты просил тут mv рассказать, чего он сделал, а твой код можно посмотреть?

по работе - только в собранном виде, по вполне понятным причинам, хотя я тут писал совсем недавно про свое хобби: гуишный тулкит - и приводил примеры, сейчас его активно привожу в порядок - и как только он будет вылизан, закончено написание тестов, документации и он станет «стабильным», я обязательно напишу об этом новость на ЛОР и выложу исходники, ориентировочно это будет уже летом; и я буду очень рад всем претензиям и замечаниям по нему, потому прошу немного подождать - я с ЛОРа за это время никуда не денусь и создавать пачками топики, что вот-вот уже - тоже не собираюсь :)

Хм, предлагаешь расстрелять программистов Autodesk?

а есть варианты лучше чем у них?

> а есть варианты лучше чем у них?

А долго рассказывать, Autocad это как бы не лучший продукт, но вероятно самый распространенный (включая основанные на нём продукты), тому есть масса причин, далёких от качества самого ПО.

Прошу прощения, если не в тему, может быть пригодится.

Есть такая штука omptl --- реализация STL на OpenMP. Там наверняка внутри можно посмотреть, что и как.

http://tech.unige.ch/omptl/

> Можно

Нельзя. Потому что копии auto_ptr не эквивалентны. И при изменении размера вектора (например, при добавлении элемента) это может выйти боком.

> И при изменении размера вектора (например, при добавлении элемента)

это может выйти боком.

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

Archimag, а можно рабочий пример кода с std::vector< std::auto_ptr<Something> >? По идее, в режиме строго соответствия стандарту код даже не скомпилируется.

> По идее, в режиме строго соответствия стандарту

код даже не скомпилируется.

Точно! Попробовал - хрен. Вектор то создать можно, а вот изменить его размер уже дудки. Проверял с gcc-4.3.3, другого компилятор у меня под рукой нет. Однако, лет 5 тому назад подобный код, по крайней мере компилятор от MS, хавал без проблем и работало (при осторожном использовании) тоже всё без проблем.

Согласен, из предлагавшихся мной вариантов можно серьёзно говорить только о std::vector< boost::shared_ptr<..> > и boost::ptr_vector.

предлагаешь расстрелять программистов Autodesk? Я только за, ибо у меня к ним столько претензий накопилось в своё время...

нет-нет-нет! даже и не думайте облегчать им жизнь :) саппорт и развитие ихнего зоопарка кода - это похуже ада на земле, должно быть

а там у них очередная светлая голова, глядишь, и третью систему рендеринга в параллель у существующим двум запилит и все они будут вместе хвататься за голову и есть кактус, со стороны знаете это так весело наблюдать :)

Согласен, из предлагавшихся мной вариантов можно серьёзно говорить только о std::vector< boost::shared_ptr<..> > и boost::ptr_vector.

а вообще можно ещё посмотреть на std::tr1::shared_ptr и boost::shared_array вместе с boost::scoped_array

>Попробовал - хрен.
Конечно, у auto_ptr явный конструктор.

Дело в том, что vector::insert()/vector::push_back() берут const value_type& (const ::std::auto_ptr<Something>&), а конструктор копирования/оператор присваивания у ::std::auto_ptr<> берут не const ::std::auto_ptr<>&, а просто ::std::auto_ptr<>&. В результате получаем ошибку компиляции из-за несоответствия типов.

компилятор от MS, хавал без проблем

Ну Microsoft известен «поддержкой» стандартов.

>Ну Microsoft известен «поддержкой» стандартов.
Он уже давно такое не хавает.

> Дело в том, что vector::insert()/vector::push_back() берут

Спасибо, я уже понял :)

Он уже давно такое не хавает.

Ну а я перестал писать такой код когда открыл для себя boost. Да и под MS уже кода 3 ничего не писал. С учётом того, что я уже пару лет на C++ практически не пишу, то мне, я думаю, простительно ;)

> а кстати, что сейчас для стартапов выбирают?

Смотря какого рода стартап?

ну те которые Вы имели в виду говоря:

Я всё больше на стартапы и интересные проекты смотрю

и кстати, раз уж заговорили, какие стартапы для Вас интересны?

PS не ради острого словца, действительно интересно, сам порой оказываюсь перед выбором инструмента, вот и приходится в промежутках между выборами внимательно водить жалом, дабы срок этих выборов сокращать

и кстати, раз уж заговорили, какие стартапы для Вас интересны?

Стартапы, в основной своей массе, завязаны на web (который мне сам по себе не интересен совсем), но на задворках там очень интересные задачи решаются: хранилища данных, кластеры, облака. Вот это мне интересно, и руку на пульсе стараюсь держать.

Вот ещё одни товарищи используют Common Lisp для финансового DSL'я, который генерит код в VHDL, зашиваемый в ПЛМ (FPGA). В результате имеют копеечные задержки (latency) при обработке финансовых данных, раз в 50 минимум быстрее самых шустрых чисто программных решений. Очень интересно и необычно!

Common Lisp для финансового DSL'я, который генерит код в VHDL, зашиваемый в ПЛМ (FPGA)

что-то вроде Lava для CL? а можно подробней?

что-то вроде Lava для CL? а можно подробней?

Глянул мельком. По-моему, Lava сильно низкоуровневая. http://www.hpcplatform.com/

http://www.hpcplatform.com/

занятно, спасибо

заюзал vector с reserve

работает

кто-нибудь отговорит?

> кто-нибудь отговорит?

Не надёжно, потом забудешь, потеряешь осторожность и несколько дней на отладку ;)

Так чем boost::ptr_vector не устраивает? Он ведь специально для этих целей предназначен.

как у него со скоростью? любая потеря в проходке по сравнению с vector была бы очень нежелательна

> как у него со скоростью? любая потеря в проходке по сравнению

с vector была бы очень нежелательна

Хорошо, собственно, он для этого и был создан, что бы минимизировать накладные расходы, характерные для std::vector<boost::shared_ptr< > > и т.п. решений. Наверное чём то и есть разница с std::vector по скорости, но вряд ли ты сможешь её обнаружить на реальном коде.