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

> Сказки. Собственно, в этом суть разногласия

далеко не сказки - лучше сразу писать нормально, а профайлер несомненно нужен - но не для того, чтоб переписывать код, когда выяснится, что тот же std::vector< boost::shared_ptr<MyClass> > ВНЕЗАПНО на цикле в миллиард итераций не так уж и эффективен, а чтоб довести состояние проекта до оптимального

> когда выяснится, что тот же std::vector< boost::shared_ptr<MyClass> >

ВНЕЗАПНО на цикле в миллиард итераций не так уж и эффективен

Что значит не так уж и эффективен? Объекты в цикле что, просто так перебирают? Или с ними что-то делают? А если что-то делают, то сколько стоит эта операция? И сколько стоят накладные расходы на boost::shared_ptr ОТНОСИТЕЛЬНО стоимости основной операции? А то ведь там может быть сутки будет код выполняться, а ты хочешь на пару секунда его сократить, при этом спровоцировать потенциальные утечки памяти, которые на «миллиарде итераций» уже точно ничего хорошего не принесут.

> Объекты в цикле что, просто так перебирают?

нет - объекты еще «соседей» опрашивают, т.е. все еще хуже при использовании shared_ptr

А если что-то делают, то сколько стоит эта операция?

как я уже говорил, ничего серьезного - просто расчет «цвета» в зависимости от соседей, кстати то, что ты не зная задачи, решаешь, что быстро, а что нет - уже говорит, что тебе все-равно, лишь бы по-твоему

А то ведь там может быть сутки будет код выполняться

два года минимум

спровоцировать потенциальные утечки памяти

тебе четко написали условия задачи - «создать контейнер, заполнить его 10000 объектами. Далее в цикле (I) миллион раз запустить цикл», где ты тут видишь «потенциальные утечки памяти»?

>лучше сразу писать нормально

premature optimization is the root of all evil

> то, что ты не зная задачи, решаешь, что быстро, а что нет

- уже говорит, что тебе все-равно

Я то как раз ничего подобного не решаю, предпочитаю ориентироваться на показания профайлера.

где ты тут видишь «потенциальные утечки памяти»

Это описание всей программы или только одной её части? Трудно ошибиться в 10 строчках, но ещё труднее написать идеально 10 000. Если думать только об одной частной проблеме, то всё выглядит просто, а потом память начинает течь, угу.

> premature optimization is the root of all evil

епт :) еще раз - это не оптимизация, никто в здраво уме не назовет вектор с указателями - оптимизацией

> никто в здраво уме не назовет вектор с указателями - оптимизацией

Всё познаётся в сравнении. Если сравнивать вектор с указателями vs вектор с интелектуальными указателями, которые во всём лучше, кроме производительности, то ты утверждаешь, что отказ от интелектуальных указателей не является оптимизацией?

> Всё познаётся в сравнении. Если сравнивать вектор с указателями vs вектор с интелектуальными указателями, которые во всём лучше, кроме производительности, то ты утверждаешь, что отказ от интелектуальных указателей не является оптимизацией?

да - потому-что таких указателей даже с стандарте нет

> Я то как раз ничего подобного не решаю, предпочитаю ориентироваться на показания профайлера.

такое ощущение, что профайдер за вас код пишет

Трудно ошибиться в 10 строчках, но ещё труднее написать идеально 10 000

у вас все трудно

а потом память начинает течь, угу.

да сколько можно :) а еще в С++ используются небезопасные указатели, и программы начинают падать, угу.

> да - потому-что таких указателей даже с стандарте нет

Хм, и даже std::auto_ptr не из таких? Он бы, кстати, тоже вполне мог подойти для данной задачи. И накладных расходов на него почти нет. Просто пользоваться надо им осторожней.

у вас все трудно

а еще в С++ используются небезопасные указатели,

и программы начинают падать, угу.

Ну, дык, это же объективная реальность, что очень часто в программах на C++ течёт память и они падают. А всё потому, что кому-то не трудно работать с голыми указателями. А писали бы нормально, и лишь при реальной необходимости оптимизировали - может и не кричали бы все вокруг, какое C++ г...

> Хм, и даже std::auto_ptr не из таких?

хм, а ты разве про него говорил?

А всё потому, что кому-то не трудно работать с голыми указателями.

ты так и не смог объяснить, зачем нужен С++ - если не для «работы с голыми указателями»

А писали бы нормально, и лишь при реальной необходимости оптимизировали - может и не кричали бы все вокруг, какое C++ г...

я повтоюсь, называть неиспользование shared_ptr оптимизацией - это нонсенс

> называть неиспользование shared_ptr оптимизацией - это нонсенс

shared_ptr это всего лишь один из вариантов интеректуальных указателей, просто самый простой и понятный, и я делал акцент не на него, а на smart pointers. Если бы ты предложил другой вариант интеллектуального указателя или предложил бы использовать boost::ptr_vector (я вот про него малость подзабыл, но мне простительно, я уже давно на C++ ничего не писал), то и вопросов бы не было. Но ты зачем-то упорно настаиваешь, что истинный путь это использовать голые указатели.

ты так и не смог объяснить, зачем нужен С++ -

если не для «работы с голыми указателями»

Есть замечательная книга «Дизай и эволюция C++», почитай на досуге, поймёшь, что не для этого.

> Но ты зачем-то упорно настаиваешь, что истинный путь это использовать голые указатели.

facepalm.tiff, я тебе 100 раз повторил, что задачи бывают разные - и использовать везде «умные» указатели глупо

Есть замечательная книга «Дизай и эволюция C++», почитай на досуге, поймёшь, что не для этого.

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

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

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

а то что-то я не припомню, чтоб там писалось про то, что голые

указатели зло и надо использовать обертки

Там нигде не сказано, что C++ нужен для работы с голыми указателями, если что, то напомню:

зачем нужен С++ - если не для «работы с голыми указателями»

Так чем тебе boost::ptr_vector не угодил?

> но по нынешним временам использовать голые указатели без ясной информации от профайлера что это действительно необходимо многократно более глупо, а также самонадеянно.

срочно всем напиши - а то над тем же Qt одни дураки работают

Там нигде не сказано, что C++ нужен для работы с голыми указателями

там написано, что С++ призван быть максимально быстрым и совместимым с С

Так чем тебе boost::ptr_vector не угодил?

boost - не стандарт

> срочно всем напиши - а то над тем же Qt одни дураки работают

Qt с какого кода ведёт свою историю?

там написано, что С++ призван быть максимально быстрым

и совместимым с С

Там много чего написано, целая книга. Что такое максимально быстрым? Как ассемблер? Нет, если помнишь, Страструп хотел язык как Simula, но только более быстрый. И поэтому сказано - вы не должны платить за то, что не используете. Но это ведь не значит, что надо использовать только то, за что не надо платить. А совместимость с C не означает, что надо программировать в стиле С.

boost - не стандарт

И что? На одном стандарте далеко уедешь? Автор ведь указал, что не обязательно контейнер должен быть из STL.

> Qt с какого кода ведёт свою историю?

тебе привести примеры других библиотек на С++?

Там много чего написано, целая книга

кроме того, что ты доказываешь

И что? На одном стандарте далеко уедешь? Автор ведь указал, что не обязательно контейнер должен быть из STL.

сначала люди используют boost, а потом понимают, что С++ им не нужен - т.к. он хуже чем встроенные решения в других языках и медленнее чем «голый» С++, но почему-то некоторые из них считают, что при этом знают как надо писать на С++ и могут учить других

> тебе привести примеры других библиотек на С++?

Я их видел достаточно.

кроме того, что ты доказываешь

Да ну, std::auto_ptr как в стандарт попал? А то, что при работе с голыми указателями теряется добрая половина мощи концепции «Выделение ресурса есть инициализация» тебя не на какие мысли не навивает?

сначала люди используют boost, а потом понимают, что С++ им не нужен

boost делает использование C++ терпимым, но бывает, что люди быстро привыкают к хорошему и вдруг понимают, что та боль, которую им приходилось терпеть раньше, действительно была болью, при чём сильной, и что можно жить гораздо проще. А производительность для большинства реальных программ не так уж и важна, так что не важно, что на самом деле быстрее.

т.к. он хуже чем встроенные решения в других языках

и медленнее чем «голый» С++

Ссылку пожалуйста на данные, что использование boost делает программы на С++ более медленными. Или опытному программисту и так всё ясно?

а потом понимают, что С++ им не нужен

Намёк на кого? С++ единственный язык со статической типизацией, который я признаю (С не в счёт, это данность). Мне сейчас больше нравиться, а для задач больше подходит, динамическая, но от этого моё отношение к C++ не изменилось. Кстати, на boost::iostreams и на asio до сих пор смотрю с завистью (наверное потому, что там много интеллекта и мало указателей). И я достаточно написал кода на C++, в том числе в командах, что бы знать об опасностях работы с голыми указателями.

>лучше сразу писать нормально

premature optimization is the root of all evil

преждевременная пессимизация куда более худшее зло

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

вот в этом и вся разница - ты просто не понимаешь, что если производительность ненужна, то и С++ не надо не по делу приплетать

П.С. надоело мусолить одно и тоже, пусть каждый останется при своем

> Я то как раз ничего подобного не решаю, предпочитаю ориентироваться на показания профайлера.

Хорошо, тогда *как* ты практически будешь профайлить оверхед от юзания умных указателей? (они ведь инлайнятся, а если их не инлайнить, то оверхед будет совсем другой)

> если производительность ненужна, то и С++

не надо не по делу приплетать

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

> *как* ты практически будешь профайлить оверхед от юзания

умных указателей? (они ведь инлайнятся

Расскажешь, как это они инлайняться?

>> лучше сразу писать нормально

premature optimization

Оптимизейшн - да, а вот проектирование (вклчающее выбор правильных инструментов под задачу) - совсем наоборот.

> shared_ptr это всего лишь один из вариантов интеректуальных указателей

shared_ptr это один из вариантов интеректуальных указателей

shared_ptr это один из интеректуальных указателей

один из интеректуальных указателей

интеректуальных указателей

интеректуальных указателей

интеректуальных

Хм. Оговорочка по фрэйду. )))

Ну да, небольшая экономия на smart-указателях приводит к тому, что большинство программистов на C++ начинают допускать ошибки при управлении ресурсами и память течёт. Зато течёт оптимально...

Со свистом!

Хорошо, тогда *как* ты практически будешь профайлить оверхед от юзания умных указателей? (они ведь инлайнятся, а если их не инлайнить, то оверхед будет совсем другой)

А какие проблемы с инлайном? Вытащить результат заинлайненного кода будет проблематично, потому что он после peephole optimization в неведомом регистре будет, а вот определить entry и return точки вполне можно.

> Со свистом!

знаешь по примеру своего кода?

знаешь по примеру своего кода?

Конечно. Утверждать обратное - равносильно утверждению, что в штаны ни разу в жизни не гадил.

Два дня потратил на поиск проблемы, потом пришёл злой начальник, и за 15 минут shared_ptr решил проблему. С тех пор я и смартпойнтеры стали лучшими друзьями. Всё равно критичный к скорости код (обработка видео) писал на Си и ассемблере. А C++ там вообще не нужен было, Питон сканал бы, только его предыдущие авторы не знали. Плюсы за последние лет 5 изо всех ниш, практически, выдавили.

> Два дня потратил на поиск проблемы

маловато, что-то

Плюсы за последние лет 5 изо всех ниш, практически, выдавили.

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

маловато, что-то

Сроки поджимали :)

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

Инертность массы. На Коболе тоже новый код продолжают писать, и какие-то там инновации на z/Architecture делают, хотя они оба ногами из 60-х растут, и весьма крепко. Или вот ещё АвтоВАЗ есть...

хотя конечно завистливым лисперам видней

Я не завислив (но диагнозы ставить люблю), а вот ты имеешь слабость к излишним обощениям.

> Инертность массы.

то сначала С++ вытеснили, то инертность - ты уж определись

Я не завислив (но диагнозы ставить люблю), а вот ты имеешь слабость к излишним обощениям

я не виноват, что лисперы так любят заходить в топики по С++ и рассказывать какой он плохой и кривой, а еще, как оказывается, все они на нем писали по работе, причем использовали буст, - ну как тут вас не обобщить

то сначала С++ вытеснили, то инертность - ты уж определись

Я всё больше на стартапы и интересные проекты смотрю, там плюсов мало. Мигрирующее с делфей на qt, жертвы отечественного IT-образования и прочие несчастные люди меня мало интересует.

я не виноват, что лисперы так любят заходить в топики по С++ и рассказывать какой он плохой и кривой, а еще, как оказывается, все они на нем писали по работе, причем использовали буст, - ну как тут вас не обобщить

Вот видишь, мы опираемся на собственный опыт и широкий кругозор. Нам можно верить. В реальной жизни нужна платформа, а не язык. C# без .NET не нужен. Java без EE не нужна. C++ без того же boost или подобных тоже не нужен.

Вот ты на скольки работах и на скольки проектах сам работал? Если на одной-двух, с фазой полувялого пинания одного древнего монстра, то там и не увидишь той надобности в платформе, которая нужна в аутсорсерских конторах, где новые полутиповые проекты просто валом прут, и времени и денег на неиспользование shared_ptr просто нет.

> Хм, и даже std::auto_ptr не из таких?

В векторе std::auto_ptr хранить нельзя, если что.

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

много - просто не там смотришь, мне даже в Херсоне предлагают время от времени работу связанную с ними, но я предпочитаю иметь свой личный долгосрочный проект и отсутствие графика работы

Вот видишь, мы опираемся на собственный опыт и широкий кругозор

ага - особенно Love5an, ну и опять же - свои работы ты так и не показывал, так что не верю

Вот ты на скольки работах и на скольки проектах сам работал?

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

которая нужна в аутсорсерских конторах

я сразу сказал - что С++ в этом случае не нужен, т.к. в результате получится и медленно и небезопасно

> В векторе std::auto_ptr хранить нельзя, если что.

Можно, если что, только надо быть осторожным, о чём я и говорил.

> Можно, если что, только надо быть осторожным, о чём я и говорил.

It is never safe to put auto_ptrs into standard containers. Some people will tell you that their compiler and library compiles this fine, and others will tell you that they've seen exactly this example recommended in the documentation of a certain popular compiler; don't listen to them.

The problem is that auto_ptr does not quite meet the requirements of a type you can put into containers, because copies of auto_ptrs are not equivalent. For one thing, there's nothing that says a vector can't just decide to up and make an «extra» internal copy of some object it contains. For another, when you call generic functions that will copy elements, like sort() does, the functions have to be able to assume that copies are going to be equivalent. At least one popular sort internally takes a copy of a «pivot» element, and if you try to make it work on auto_ptrs it will merrily take a copy of the pivot auto_ptr object (thereby taking ownership and putting it in a temporary auto_ptr on the side), do the rest of its work on the sequence (including taking further copies of the now-non-owning auto_ptr that was picked as a pivot value), and when the sort is over the pivot is destroyed and you have a problem: At least one auto_ptr in the sequence (the one that was the pivot value) no longer owns the pointer it once held, and in fact the pointer it held has already been deleted!

So the standards committee bent over backwards to do everything it could to help you out: The Standard auto_ptr was deliberately and specifically designed to break if you try to use it with the standard containers (or, at least, to break with most natural implementations of the standard library). To do this, the committee used a trick: auto_ptr's copy constructor and copy assignment operator take references to non-const to the right-hand-side object. The standard containers' single-element insert() functions take a reference to const, and hence won't work with auto_ptrs.

и эти люди говорят о безопасном программировании в С++ ...

> то сначала С++ вытеснили, то инертность - ты уж определись

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

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

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

Смотря какого рода стартап? Ну Erlang с OCaml'ом популярны, и вот ещё Clojure начал появляться.

даже в Херсоне

Как будто мне это о чём-то говорит... ;)

ну и опять же - свои работы ты так и не показывал, так что не верю

Моя деанонимизация на раз-два делается.

я сразу сказал - что С++ в этом случае не нужен, т.к. в результате получится и медленно и небезопасно

По твоему мнению, в каких случаях он нужен?

> Как будто мне это о чём-то говорит... ;)

небольшой забитый областной центр в области где всего два города( если считать и Херсон ) :)

Моя деанонимизация на раз-два делается.

ну так почему не написать тут?

По твоему мнению, в каких случаях он нужен?

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

> Ну Erlang с OCaml'ом популярны, и вот ещё Clojure начал появляться.

вы явно оторваны от действительности :)

>Можно, если что, только надо быть осторожным, о чём я и говорил.
Это как интересно?

вы явно оторваны от действительности :)

Действительность такая, какой человек её воспринимает. Моя действительность - интересная.

ну так почему не написать тут?

Нужды пока нет.

> Действительность такая, какой человек её воспринимает. Моя действительность - интересная.

у сумасшедших по такому определению действительность еще интереснее

> Нужды пока нет

зато есть нужда упоминать, что вы такой опытный программист и т.д., странно это все

Вот тут лиспом восхищаетесь, говорите что у лисперов кругозор и прочее. Но я ничего не нашёл в нём радикально крутого, синтаксический сахар, gc да пожалуй и всё. Чем оно принципиально лучше явы, питона, .Net? C++ это более нузкоуровневый язык, с вышеперечисленными языками его не очень корректно сравнивать.

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

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