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

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

E>>Ну, бустовый shared_ptr неэффективен по памяти. А это порой критично.

B>Ну там где память критична (микроконтроллеры, firmware и пр...) там и подходы совсем иные.
B>Там вообще до сих пор С с ассемблером властвуют

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

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

B>Но если ты вообще не пользуешься умными указателями, то и спорить не о чем.
Пользуюсь, конечно

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

B>Преимущество буста только в том, что он войдет в стандарт.
Ну в целом умный указатель -- это тема настолько уже разработанная, что есть вагоны реализаций. Примерно одинаково хороших. ИМХО переходить с одной на другую -- просто тратить деньги даром

B>Т.е. станет стандартным решением стандартной проблемы.
Ну "умный указатель" уже и так стал стандартным решением. То, что его не было в STL ничего хорошего о STL, ИМХО, не говорит...

А так я со всем согласен

Господа несогласные! Вы не согласились со следующим утверждением:

E>Есть такая штука, как экономическая эффективность. ИМХО она и имеет решающую роль.
E>Мой опыт говорит, что у буста она отрицательная, а у STL нулевая, при чём скорее меньше нуля, чем больше.
E>В других конторах другие бизнес-процессы и традиции программирования. И что?
E>ИМХО Винда или Linux от того, что в них буст и STL не используются не стали провальными проэктами...

Вы бы хоть прокомментировали с какой из трёх частей не согласны?
С тем, что экономическая эффективность играет решающую роль?
С тем, что говорит мой опыт? (Заметьте, что на ваш опыт я не претендую. Я просто делюсь своим )
С тем, что Винда и Лялих не пользуются STL или с тем что они не являются провальными проэетками?

А то я как-то даже и совсем понимаю с чем нет согласия у народа-то

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

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

Память вообще много где критична. Например под виндой память -- это рабочее множество, а рабочее множество -- это скорость...

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

E>Ну, бустовый shared_ptr неэффективен по памяти. А это порой критично.
Ну кроме того, что он неэффективен по памяти, он ещё не позволяет хранить обычные указатели на объект. Соответсвенно, в случае каких-то сложных конструкций, надо ещё и слабые указатели какие-то прикручивать, ну и т. д.

А>>Какой смысл ждать и хранить "чистоту" неопределенное время?
E>Ну у многих контор есть какие-то свои библиотеки. Зачем на буст переходить?

Эта, не веришь в "свои библиотеки" или не согласен с вопросом "зачем?"?
Про библиотеки -- это правда. Во всяком случае у больших контор. Ну а вопрос "зачем?" в деятельности программиста, ИМХО, правомерен всегда и является "самым главным вопросом"
Так с чем не согласие-то возникло?

Erop wrote:

> E>Ну, бустовый shared_ptr неэффективен по памяти. А это порой критично.
> Ну кроме того, что он неэффективен по памяти, он ещё не позволяет
> хранить обычные указатели на объект. Соответсвенно, в случае каких-то
> сложных конструкций, надо ещё и слабые указатели какие-то прикручивать,
> ну и т. д.
shared_ptr работает в паре с weak_ptr. И по-другому тут просто не сделать (конечно, если тебе нужны гарантии
thread/exception safety).

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

B>Вот представь, прихожу я к тебе в команду.
B>До сих пор я пользовался бустом.
B>Если вы пользуетесь бустом, то на умные указатели
B>мне вообще времени не нужно. Я продолжаю их использовать как и раньше.
B>Это в общем-то обычное преимущство стандартных решений перед самопальных.

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

B>А вообще я уверен, что ты все понимаешь.
B>Я тебе ничего нового не скажу, и Америку не открою
Ну есть такое наблюдение за бустом, что он тянется в проект одно за другим. А всё вместе слишком много получается. ИМХО если есть возможность не связываться, то лучше и не связываться.
Во всяком случае, если есть свой умный указатель, то на буст переходить только заради него однозначно не стоит. ИМХО.

B>Ты лучше признайся, что ты сам написал свой умный указатель,
B>он тебе дорог и ты его просто любишь
B>Тогда я все пойму.
Увы, но я его не писал и пользуюсь конторским. И он мне в чём-то даже не нравится. Но бустовкий, кстати, не нравится ещё больше

B>Иначе, ни менеджменту, ни пользователям умного указателя (твоим коллегам)
B>нету никакого резона пользоваться самопальным решением стандартной проблемы.
Ну буст ещё не стандарт вроде бы как.
Да и фирменная библиотека вроде бы не "самопальное решение". В чём-то она хуже буста, в чём-то лучше. Однозначно намного проще и меньше
А ещё переносима на довольно чахлые платформы, кстати

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

.>shared_ptr работает в паре с weak_ptr. И по-другому тут просто не сделать (конечно, если тебе нужны гарантии
.>thread/exception safety).

Да я понимаю, что не сделать. Я собственно про то же самое и пишу
Бывают и разные другие конструкции, тем не менее...

Erop wrote:
> .>shared_ptr работает в паре с weak_ptr. И по-другому тут просто не
> сделать (конечно, если тебе нужны гарантии
> .>thread/exception safety).
> Да я понимаю, что не сделать. Я собственно про то же самое и пишу
> Бывают и разные другие конструкции, тем не менее...
В Бусте есть и intrusive_ptr с нулевым оверхедом — какие проблемы-то?

Erop wrote:

> .>shared_ptr работает в паре с weak_ptr. И по-другому тут просто не
> сделать (конечно, если тебе нужны гарантии
> .>thread/exception safety).
>
> Да я понимаю, что не сделать. Я собственно про то же самое и пишу
> Бывают и разные другие конструкции, тем не менее...
Ну дык нет просто "умного указателя", это целое семейство алгоритмов управления ресурсами. В бусте (+std::auto_ptr) есть
самые "полезные".

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

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

J>>менеджеры программеров, решающие вопросы уровня "запретить/разрешить использование библиотеки Х" (т.е. менеджеры первого, максимум второго звена), редко определяют финансовые показатели.

E>Ну и зачем же тогда буст использовать, если это решение не увеличивает эффективность бизнеса?
E>Сотрудники-то для буста нужны дороже...

Тут уже сказали про стандартные решения.
Я только могу добавить, что эффективность бизнеса можно мерять по-разному.
Например, по тому, насколько персонал счастлив работать в этой конторе.
Или по тому, насколько большому риску подвергается разработка.
Другое дело, что в России к риску относятся наплевательски в том смысле, что народ просто сидит до полуночи, пока не найдет и пофиксит баг, и, естественно, сверхурочные не оплачиваются с аргументацией типа "надо писать аккуратнее, без багов, вам не за баги деньги платят".
А там, где используются нормальные библиотеки и таких багов не возникает, люди уходят домой вовремя.

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

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

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

A>>>Плюс не во всех конторах разрешено его использовать.
J>>Ну что я могу сказать о состоянии сознания менеджеров таких контор...

E>Нет ты скажи, скажи. С удовольствием послушаю
E>И заказчикам потом перескажу, которые от VC 6.0 отказаться не могут. Или просят портироваться на какую-нибудь платформу, где поддержка C++ шаблонов в бета-версии компилятора находится.

И скажу, а ты как думал

Во-первых, нет проблем использовать некоторые библиотеки буста с вц6.0 — они вполне на нем работают.
И я использовал буст в программах для смартфонов, опять же без каких-либо проблем с производительностью.

Во-вторых, для меня есть большая разница между административным запретом типа "В нашей конторе буст, STL и прочие шаблоны запрещены. Навсегда. Я сказал" и техническим типа "На платформах, для которых разрабатывается конкретный продукт, из 5 опробованных библиотек лучшей по таким-то критериям показала себя библиотека №3, так что используем ее".

Первое — глупость, так и передай своим заказчикам

E>Что до всяких shared_ptr, то в многопоточной программе еще не факт, хорошая это штука или нет.
Это тема отдельного большого разговора, и boost::shared_ptr будет занимать в нем крайне незначитальную часть

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

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


B>>Преимущество буста только в том, что он войдет в стандарт.
E>Ну в целом умный указатель -- это тема настолько уже разработанная, что есть вагоны реализаций. Примерно одинаково хороших. ИМХО переходить с одной на другую -- просто тратить деньги даром

B>>Т.е. станет стандартным решением стандартной проблемы.
E>Ну "умный указатель" уже и так стал стандартным решением. То, что его не было в STL ничего хорошего о STL, ИМХО, не говорит...

Это вообще ничего про СТЛ не говорит. В СТЛ был auto_ptr, его хватало для кучи вещей. А насчет указателя, который отслеживает ссылки — так тема "настолько уже разработанная" и ставшая "стандартным решением", что была смертельная битва между Александреску и бустовцами по поводу того, какая же реализация должна войти в стандарт. (Как мы знаем, буст в результате победил.)
так что не все так просто.

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

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

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

E>>Ну, бустовый shared_ptr неэффективен по памяти. А это порой критично.
E>Ну кроме того, что он неэффективен по памяти, он ещё не позволяет хранить обычные указатели на объект. Соответсвенно, в случае каких-то сложных конструкций, надо ещё и слабые указатели какие-то прикручивать, ну и т. д.

Есть auto_ptr, scoped_ptr, intrusive_ptr, у которых вообще нет оверхеда.
А если тебе нужен отслеживатель ссылок, да еще и с циклическими зависимостями — очень интересно, как ты без концепции "слабого указателя" обойдешься.
И что значит — "не позволяет хранить обычные указатели на объект"? Он, вроде, именно их и хранит

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

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

E>Вот представь, пользуешься ты boost::regex. Приходишь ко мне в команду, а тут PCRE. И что?
E>Или ты пользуешься boost::asio, а у меня ACE.
E>Или пользуешься ты FOX Toolkit, а у меня Qt.

E>Для C++ таких примеров можно перечислять множество. Когда tr1 и shared_ptr станут частью стандарта и будут входить в поставку компилятора, тогда и можно будет говорить о стандартных решениях. А пока все это вопрос личных предпочтений.

И даже после того, как это станет частью стандарта и будут входить в поставку компилятора, это не будет мешать людям ещё как минимум лет 10 говорить, что это всё лажа/криво/медленно/сделано ламерами/не поддерживается на наших компиляторах/может не поддерживаться на компиляторах, на которые нам могут сказать перейти...
Особенно в контексте С++.
А если хочется использовать, то это вполне уже можно делать и сейчас (и уже как лет 5 точно).


E>Стандартная проблема -- это ручное управление памятью, а вот то -- что у нее есть стандартное решение, и что это стандартное решение -- набор умных указателей из boost-а -- это уже черезчур, имхо. Уж если и есть у этой проблемы, стандартное решение, так это GC.

Стандартная проблма — это управление не памятью, а управление ресурсами. На этой маленькой детали просела и Java и С#. С памятью-то всё хорошо (более менее, пока не умничаешь и делаешь что и все). А вот с остальными ресурсами — проблема. И код типа:

...
mutex1.lock();
try
{
  mutex2.lock();
  try
  {
    ...
  }
  finally
  {
    mutex2.unlock();
  }
}
finally
{
  mutex1.unlock();
}

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

И С++ в этом плане предлагает как раз универсальное решение — это скопе-семантика + конструктор/деструктор. И умные указатели есть воплощение этого универсального решения.
Единственное чего не хватает, так это scoped/shared_handle/resource. Но надо надеяться, что у каждого желающего уже есть свой.


з.ы. с++/cli сделал ещё один шаг вперёд в этом направлении. Там ко всем вкусностям C#/Java (в плане управления ресурсами) добавлена ещё и скопе-семантика и "синхронный деструктор". Убийца!

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

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

Т.е. в игрушках оверхед по памяти умные указатели сравним с памятью,
которая используется на "полезные" дела?
Ну я даже не знаю, как этого достичь
Хотя... Если везде вместо

std::vector<int>

пользоваться исключительно

std::vector< boost::shared_ptr<int> >

то да, проблемы скорей всего будут

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

E>Есть такая штука, как экономическая эффективность. ИМХО она и имеет решающую роль.
E>Мой опыт говорит, что у буста она отрицательная, а у STL нулевая, при чём скорее меньше нуля, чем больше.
У меня противоположное мнение, основанное на моем опыте.

E>В других конторах другие бизнес-процессы и традиции программирования. И что?
E>ИМХО Винда или Linux от того, что в них буст и STL не используются не стали провальными проэктами...
Дык они и не на С++ написаны. К тому же, ИМХО, некто и не утверждает, что проект не использующий буст и STL, будет провальным. Речь идет об уменьшении издержек, которые появляются из-за "полировки велосипедов" и обучения нового персонала. Если Microsoft может себе это позволить, это их дело. А может просто STL от студии полное дерьмо...

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

S>Дык они и не на С++ написаны. К тому же, ИМХО, некто и не утверждает, что проект не использующий буст и STL, будет провальным. Речь идет об уменьшении издержек, которые появляются из-за "полировки велосипедов" и обучения нового персонала. Если Microsoft может себе это позволить, это их дело. А может просто STL от студии полное дерьмо...
Микрософт не имеет отношения к коду STL от студии За код STL от студии отвечает P.J. Plauger , кстати и в переписке по 0Х он присутствует

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

R>И даже после того, как это станет частью стандарта и будут входить в поставку компилятора, это не будет мешать людям ещё как минимум лет 10 говорить, что это всё лажа/криво/медленно/сделано ламерами/не поддерживается на наших компиляторах/может не поддерживаться на компиляторах, на которые нам могут сказать перейти...
R>Особенно в контексте С++.
Ну моё личное мнение -- это то, что шаблоны в C++ очень сложные, соответсвенно доступны сильно не всем программистам, и сильно не всем компиляторам.

Конечно если ты уж решился на "шаблоны по полной", то есть набрал "подходящий для использования шаблонов" персонал (ну либо ты сам "подходящий"), и решил, что если компилятор С++ на платформе плохо поддерживает шаблоны, то это не твоя платфорома, а если клиенту нужен код под такой компилятор, то это не твой клиент, то да. Риски от использования STL сильно снижаются и тогда и заметная часть буста приемлема тоже.
А вот если ты пока что не решился на "шаблоны по полной", то STL конечно неоправданно оптимистическое решение. Только и всего.

R>А если хочется использовать, то это вполне уже можно делать и сейчас (и уже как лет 5 точно).
Ну скорее если можешь себе позволить

Проблема же не в том, что STL там, или буст написали криворукие маньяки. Обе библиотеки сделаны весьма на высоком уровне. Проблема в другом. Обе библиотеки сделаны в предположении, что С++ шаблоны надо использовать на полную катушку. Если это предположение тебе подходит, то автоматически подходит и STL.

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

Чтобы быть более понятным, приведу пример. Я знаю людей, которые перенесли одну весьма сложную и наукоёмкую прогу в один девайс. В целом перенсли с какими-то проблемами, но перенесли. Всё типа было прекрасно. Но люди не использовали STL, а использовали другую, намного более простую библиотеку шаблонных контейнеров.

Потом производитель девайса по каким-то своим юридическим причинам был вынужден срочно сменить платформу. УПС. Ребятам пришлось на ходу переноситься ещё раз. А вот на новой платформе шаблонов в С++ просто не было
В качестве выхода они нагенерили из своих шаблонных контейнеров все нужные специализации, на том и спаслись. А вот что бы они делали, если бы "ввязались в шаблоны по полной"? Выбросили бы проект?

Зависимость от "качественной поддержки шаблонов" -- это такой же риск, как зависимость от платформы вообще (непереносимый код), зависимость от ресурсов, вообще любая зависимось. Нужно просто оценивать существеннен такой риск или нет.
Но для многих контор конечно не существенен. Это-то всё и определят. А не идеологические тёрки нравится там кому-то STL или не нравится...