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

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

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

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

B>std::vector<int>
B>

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

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

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

struct MySuperPuper
{ int a,b,c, .... z;
};
boost::shared_ptr<MySuperPuper>  p;
p->a++; p->b++; .... p->z++;

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

E>>Ну у многих контор есть какие-то свои библиотеки. Зачем на буст переходить?
E>Эта, не веришь в "свои библиотеки" или не согласен с вопросом "зачем?"?

Я не против собственных велосипедов как класса. Однако на практике принятие решение о написании собственных библиотек взмен использования стандартных зачастую диктуется не недостатками последних, а тем что "софт плох, потому что что его писали не мы".

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

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

P>struct MySuperPuper
P>{ int a,b,c, .... z;
P>};
P>boost::shared_ptr<MySuperPuper>  p;
p->>a++; p->b++; .... p->z++;
P>

К чему приведет?

Оверхед на shared_ptr зависит от числа копий объектов типа shared_ptr,
а не от размера динамических объектов, на которые указывают умные указатели.
В этом смысле оверхед на
boost::shared_ptr<MySuperPuper> p;
ровно такой же, как и на
boost::shared_ptr<int> p;

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

J>Другое дело, что в России к риску относятся наплевательски в том смысле, что народ просто сидит до полуночи, пока не найдет и пофиксит баг, и, естественно, сверхурочные не оплачиваются с аргументацией типа "надо писать аккуратнее, без багов, вам не за баги деньги платят".
J>А там, где используются нормальные библиотеки и таких багов не возникает, люди уходят домой вовремя.

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

*Уточнение 2* Список "нормальных библиотек" бустом и STL'ем ИМХО не исчерпывается...

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

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

Автор: Erop
Дата: 23.08.07

Второе касается того, что, например, в нашей конторе, где STL и использование своих шаблонов без писменного разрешения начальника по поводу каждого случая применения, большинству программистов просто запрещено, свободный график посещения. А ещё в одной конторе, где тоже запрещено, вообще нет графика посещения. Елинственное ограничение -- нельзя программировать для кого-то, кроме этой конторы Обе пока что весьма эффективны

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

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

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

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

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

Но а вообще, нет смысла обсуждать ситуацию именно у вас.
Я вполне могу согласиться, что у вас оптимально именно так, как есть.
У нас тоже есть пара самописных велосипедов, до которых руки не доходят.
Вопрос больше в общей стратегии и преимуществах стандартных подходов перед самопальных.
Понятно, что есть исключения, особые обстоятельства и давняя история уже существующих проектов.

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

E>>Ну "умный указатель" уже и так стал стандартным решением. То, что его не было в STL ничего хорошего о STL, ИМХО, не говорит...
J>Это вообще ничего про СТЛ не говорит. В СТЛ был auto_ptr, его хватало для кучи вещей.
К чему лицемерие? Мы же все знаем, что речь идёт на самом деле о конструкции std::vector<xxx::shared_ptr<my_fat_class> >...
То, что в STL нет нормального способа родить такую конструкцию, ИМХО, недоработка авторов библиотеки. ИМХО это одна из самых неудобных недоделок STL.

J>А насчет указателя, который отслеживает ссылки — так тема "настолько уже разработанная" и ставшая "стандартным решением", что была смертельная битва между Александреску и бустовцами по поводу того, какая же реализация должна войти в стандарт. (Как мы знаем, буст в результате победил.)
J>так что не все так просто.

Она разработана в том смысле что есть куча реализаций и всё уже обсуждено. Битва же была не потому, что чего-то непонятно, а потому что удобного для всех случаев решения просто нет
Видимо по этой же причине shared_ptr отсутствовал в STL. ИМХО корень этой ситуации -- плохой дизайн шаблонов в C++ вообще. Слишком уж там перепутана реализация и интерфейс. Но это уже совсем далеко нас заведёт в область абстракции.
Короче, сейчас у любой вменяемой конторы есть способ где-то взять какой-то sharel_ptr или разработать самостоятельно. ЗАДЁШЕВО. И пользоваться им с радостью...

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

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

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

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

E>>Мой опыт говорит, что у буста она отрицательная, а у STL нулевая, при чём скорее меньше нуля, чем больше.
S>У меня противоположное мнение, основанное на моем опыте.
Ну это же только опыт. Я понимаю, что он бывает разным. Возможно дело в том, что известные тебе альтернативы были хуже STL+буст. Возможно что-то ещё. Это же ещё от культуры программирования в конторе зависит и от возможных требований заказчиков

Автор: Erop
Дата: 23.08.07

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

S>...Если Microsoft может себе это позволить, это их дело. А может просто STL от студии полное дерьмо...

Ну он не совсем от них, вроде
Но в целом трудно отрицать как бизнес, так и технологическое лидерство Microsoft в программировании, а вовсе и не HP, или где там STL зародился?

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

C>В Бусте есть и intrusive_ptr с нулевым оверхедом — какие проблемы-то?
А его тоже в STL переносят?

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

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

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

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

B>std::vector<int>
B>

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

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

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

Зачем использовать криво написанную вещь, половиной фич которой ты просто не пользуешься?
Не имеет значение, какой оверхед? Главное, что он будет заведомо.

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

J>И что значит — "не позволяет хранить обычные указатели на объект"? Он, вроде, именно их и хранит

Так писать нельзя:

shared_ptr<T> p1 = CreateT();
T* p2 = p1;
shared_ptr<T> p3 = p2;

Evgeniy13!
А ты с чем не согласен в этой просьбе пояснить?
Тебе очевидно что не так в исходном посте? Может тогда лучше бы объяснить?

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

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

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

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

Так я и думал, что скажешь

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

Речь не о проблемах производительности. А о том, что только некоторые библиотеки из boost-а будут работать с тем же vc.6.0. Но ведь тогда в чем смысл boost-а?

Ладно бы он представлял из себя что-то типа RubyGems или дебиановских deb-файлов -- набор маленьких дистрибутивчиков библиотек с отслеживанием зависимостей. Тогда захотелось мне shared_ptr -- взял, захотелось еще чего-нибудь -- опять взял. И все стандартными средствами с отслеживанием зависимостей. И на таком уровне, чтобы вчерашний студент мог прочитать страничку how-to и выцепить себе из boost-а нужные библиотеки. И чтобы потом был простой и удобный способ проверять и устанавливать обновления для библиотек.

А так сейчас либо качай весь буст. Либо бери какой-то bcp и сам себе выдергивай нужные части. А затем сам себе контролируй их актуальность.

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

Я не говорил про полный маразм вроде запрещения шаблонов, исключений или STL. А о том, что как-то априори сейчас считается, что boost -- это наше все. Что он самый лучший по определению. А ведь не факт. Особенно в коллективах, которые начинали работать лет 10-7-5 назад. Тогда ведь принимались решения совсем в других условиях. И много отлаженного кода с тех пор было написано. Просто так от него отказываться сейчас тоже не дело.

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

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

Неоднократно. Только ведь заказчик -- он же всегда прав. Его не пугает даже то, что MS уже давно прекратила поддержку VC.6.0 (помнится, сие знаменательное событие произошло пару лет назад).

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

Вот-вот. А горячие головы при этом будут говорить: стандартная проблема, стандартное решение /прошу никого не обижаться, все совпадения с реальными участниками дискуссии являются совершенно случайными :beer:/

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

B>Ну вы же наверяка не ограничились умными указателями
B>Предположу, что у вас и строки, контейнеры и стандартные алгритмы тоже самобытные
B>Так, по мелочам, только на ознакомление точно удет ненулевое время.

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

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

E>Зачем использовать криво написанную вещь, половиной фич которой ты просто не пользуешься?
E>Не имеет значение, какой оверхед? Главное, что он будет заведомо.

Все понял

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

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

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

B>Замечательно.
B>Это же известные и проверенные решения, а не самопальные велосипеды.
B>Я вообщем-то за них (известные решения) и агитирую

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

И если кто-то при переходе в новую команду не сможет адаптироваться к новым инструментам, то это не столько проблема инструментов. Имхо.

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

B>Ну вы же наверяка не ограничились умными указателями
B>Предположу, что у вас и строки, контейнеры и стандартные алгритмы тоже самобытные
B>Так, по мелочам, только на ознакомление точно удет ненулевое время.

Да всё равно время уйдёт на въезд в манеру программирования. Кроме всего прочего у нас программы сложные, и обычно программисту сложнее въехать не в массив там или строку, а в предметные вопросы. Тем более что и массив и строка довольно похожи на известные образцы. Строка, скажем, похожа на MFC'шную CString...

B>Но а вообще, нет смысла обсуждать ситуацию именно у вас.
B>Я вполне могу согласиться, что у вас оптимально именно так, как есть.
Ну это обмен опытом, как бы. Хотя глобального смысла нет, да и противозаконно

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

Автор: Erop
Дата: 23.08.07

.

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

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

B>>Ну вы же наверяка не ограничились умными указателями
B>>Предположу, что у вас и строки, контейнеры и стандартные алгритмы тоже самобытные
B>>Так, по мелочам, только на ознакомление точно удет ненулевое время.

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

Я не адекватен
У меня уйдет точно больше времени.
Насколько больше — это сильно зависит от самобытности контейнеров.
Предела самобытности не существует

Здравствуйте, Андрей Коростелев, Вы писали:

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

E>>>Ну у многих контор есть какие-то свои библиотеки. Зачем на буст переходить?
E>>Эта, не веришь в "свои библиотеки" или не согласен с вопросом "зачем?"?

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

Не нужно обобщать. Взять те же STL-ные строки — они так и просят велосипеда.
Ну и "софт плох, потому что я не уверен, что он работает как надо" крайне весомый аргумент. Копаться в исходниках STL — увольте. К тому же, ничего подправить не получится.
Можно, конечно, брать (в случае STL) STL port и переписывать его под себя. Но это уже тот же "велосипедизм".

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

E>Потом производитель девайса по каким-то своим юридическим причинам был вынужден срочно сменить платформу. УПС. Ребятам пришлось на ходу переноситься ещё раз. А вот на новой платформе шаблонов в С++ просто не было :)

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

Вот если бы тот код скомпилировали с помощью EDG front end, который переводит C++ в C, то что, этот код на C не скомпилировался бы?

Кстати, «шаблонов в С++ просто не было» — с логической точки зрения это утверждение всегда ложно :-)