Re[13]: велосипеды vs boost и пр "стандартные" решения - C/C++

Здравствуйте, 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 или не нравится...

Здравствуйте, 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+буст -- это на самом деле решение о том, что тебе не понадобится версия этой программы на компиллере с не особо хорошо реализованными шаблонами + о том, что ты не будешь занимать на этом проекте программистов, которые не супер спецы в шаблонах

Второе касается того, что, например, в нашей конторе, где 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+буст. Возможно что-то ещё. Это же ещё от культуры программирования в конторе зависит и от возможных требований заказчиков.
Конечно анархия хуже любой системы. Но если у конторы уже есть какое-то хорошо работающее решение, скорее всего переход на STL и буст не окупится, кроме того он может привлечь доп. риски.

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

Ну он не совсем от них, вроде

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

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

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

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>Понятно, что есть исключения, особые обстоятельства и давняя история уже существующих проектов.
Ну, ИМХО, в стратегической плоскости всё определяется ответом на один вопрос о шаблонах.

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

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

B>>Ну вы же наверяка не ограничились умными указателями

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

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

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

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

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

E>>Эта, не веришь в "свои библиотеки" или не согласен с вопросом "зачем?"?

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

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

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

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

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

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

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

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

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

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

Во-вторых, ИМХО, совсем крупным конторам такая логика выгодна и естественна, так как контора большая, а риски из-за того, что ты не контролируешь часть кода, пропорциональны размеру конторы, а затраты на велосипеды пропорциональны размеру велосипедов

Для мелких, ИМХО, в вопросе STL всё упирается совсем в другой вопрос.

Но по многим вопросам можно действовать непрагамтически. В том числе и в области STL + буст...
Это обычно в области STL неспецифично

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

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

"А включаешь не работает". Шаблоны в доступном компилере были в режиме беты

Что бы было, если спользовать компилятор в C -- не известно. ИМХО легко могло бы не сойтись и отлаживаться очень неудобно.

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

B>Я не адекватен

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

Ну значит твой удел -- конторы, которые буст + STL

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

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

E>Ну значит твой удел -- конторы, которые буст + STL

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

А для тебя будет трагедией, если ты приходишь в фирму, а там boost с STL'ем ?

auto_ptr< My > ptr( new My() );
...
ptr.reset();

то при переходе на VC.6.0 тебе придется все эти вызовы заменить на:

ptr = auto_ptr< My >();

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

А все потому, что в VC.6.0 auto_ptr появился еще до выхода стандарта.

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

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

R>

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

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

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

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

Я то же долгое время думал, что управление памятью -- это часть проблемы управления ресурсами. Может быть где-то на высоком уровне абстракции это и так, но на практике лучше иметь отдельное стандартное решение для управления памятью (GC + возможность ручного управления) и набор решений для управления ресурсами.

Вот, можно взять несколько языков с GC, но особых проблем с управлением ресурсами там не много. В C# есть конструкция using.

В Ruby можно использовать блоки кода для scoped-ресурсов:

def lock_and_do_something( mutex, &blk )
  mutex.lock
  blk.call
ensure
  mutex.unlock
end
...
lock_and_do_something( mutex1 ) do
  lock_and_do_something( mutex2 ) do
    ...
  end
end

В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:

scope class Lock
  {
  this( Mutex m )
    {
      m_ = m;
      m_.lock;
    }
  ~this()
    {
      m_.unlock;
    }
  }
...
scope Lock l( mutex1 );
mutex2.lock;
scope(exit) mutex2.unlock;
...

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

Вот поэтому я с сарказмом и говорю о стандартных решениях стандартных проблем.

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

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

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

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

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

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

Такая проблема есть. Естественно изначально надо сделать ряд предположений. Причём они касаются далеко не только шаблонов в С++. Шаблоны в С++ — это только верхушка айсберга.
Можно сделать минимум предположений. Но работать в такой обстановке будет на порядок труднее, когда нельзя ни на что полагаться. Зато код [в идеале] будет действительно мало от чего зависеть.
Можно сделать много предположений. Тогда работать будет на порядок проще. Зато код будет зависимым.
И тут получается стандартная палка о двух концах. Самые крайние позиции скорее всего абсурдны. Основной вопрос — кто где найдёт для себя золотую середину.

Если идти в сторону снижения предположений дальше, то скорее всего выбором будет С, а не С++, и уж точно не Java/C#. Не С99, а С89. Так же, если это сетевое приложение, то рассчитывать надо на модемное дайл-апное подключение. На ОС вообще надежды мало. Всё надо делать самому — включая юзер-левел тридинг и т.д... Разработка превращается в сущий ад — всё что хочешь сделать, и что сделать быстро, ты сделать не можешь.

Если идти в сторону увеличения предположений. То выбором будет С++ с полной поддержкорй шаблонов, а то и C#. ОС только одна. Сеть быстрая. И т.д. Разработка превращается в удовольствие. Но работать будет только на этой платформе...

Т.ч. с стоим выводом согласен — проблема не в шаблонах.

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

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

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

E>Да, только тогда эти люди должны будут объяснять, почему они не пользуются стандартными вещами.

Потому что:

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

E>то при переходе на VC.6.0 тебе придется все эти вызовы заменить на:

"при переходе на VC.6.0" сейчас звучит забавно

E>Я то же долгое время думал, что управление памятью -- это часть проблемы управления ресурсами. Может быть где-то на высоком уровне абстракции это и так, но на практике лучше иметь отдельное стандартное решение для управления памятью (GC + возможность ручного управления) и набор решений для управления ресурсами.

Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
С++ будет одним из первых — если примут GC в стандарт, либо С++ + Boehm GC.

А чем умные-указатели не разновидность GC?

E>Вот, можно взять несколько языков с GC, но особых проблем с управлением ресурсами там не много. В C# есть конструкция using.

Это всё равно, что в С есть free(), поэтому проблем с управлением памятью там нет

E>В Ruby можно использовать блоки кода для scoped-ресурсов:

E>В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:

Это уже лучше, но это в точности до константы тоже, что и в С++.

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

Для управления scoped ресурсами (в т.ч. памятью) решение С++ имхо близко к идеалу.
Для shred ресурсов появляется некое неудобство в необходимости везде использовать shared_ptr вместо простого указателя.
Моя лично практика применения RAII для управления всеми типов ресурсов в проектах на С++ показывает, что подход не имеет существенных минусов и достаточно адекватен.

А в языках со сборкой мусора своих проблем тоже хватает — в Java, например, патчем догружади WeakRef...

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

R>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
MS CLI. Но это монстр ещё тот.

Erop wrote:

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

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

Можно, только что ты хочешь этим сказать??

Posted via RSDN NNTP Server 2.1 beta

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

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

E>>Да, только тогда эти люди должны будут объяснять, почему они не пользуются стандартными вещами.

R>Потому что:
R>

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

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

Насколько я помню по различным историям на RSDN случаи, когда люди отказывались от STL и получали серьезный прирост производительности. В Философии Программирования когда-то был рассказ о системе обработки информации о переговорах в биллинге какого-то мобильного оператора.

К сожалению, случаи, когда STL поставляется с какими-то глюками, случаются. Тут недавно DEADBEAF приводил ссылки на блоги MS-овских разработчиков VC, так там был пример просада производительности в STL из VC++8.0.

E>>то при переходе на VC.6.0 тебе придется все эти вызовы заменить на:

R>"при переходе на VC.6.0" сейчас звучит забавно

А вот мне, периодически, грусно.

E>>Я то же долгое время думал, что управление памятью -- это часть проблемы управления ресурсами. Может быть где-то на высоком уровне абстракции это и так, но на практике лучше иметь отдельное стандартное решение для управления памятью (GC + возможность ручного управления) и набор решений для управления ресурсами.

R>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.

D

R>С++ будет одним из первых — если примут GC в стандарт, либо С++ + Boehm GC.

R>А чем умные-указатели не разновидность GC?

Из-за различия в принципах работы.

E>>В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:

R>Это уже лучше, но это в точности до константы тоже, что и в С++.

Передергивание

В C++ (стандартном) нет finally и нет scope(exit) (который в D может быть разным).

R>Моя лично практика применения RAII для управления всеми типов ресурсов в проектах на С++ показывает, что подход не имеет существенных минусов и достаточно адекватен.

Ну тут я с тобой буду согласен до того момента, как придется совмещать RAII и управление памятью.

Я в последний год-полтора столкнулся с несколькими случаями, когда GC сильно бы облегчил жизнь и сделал бы мою работу гораздо проще. В двух случаях это было сопряжение с ACE-овскими штуками. Когда внешние по отношению к ACE-овским Event_Handler-ам объекты должны были держать ссылки на эти Event_Handler-ы. Но проблема была в том, что когда Event_Handler обнаруживал разрыв соединения и должен был отключится от реактора и исчезнуть. Но так, чтобы не повисла ссылка на него. С другой стороны, клиент Event_Handler-а мог завершить свою работу до разрыва соединения. И тогда Event_Handler должен был исчезнуть уже без опасений за ссылки на него.

Еще один случай -- попытка сделать объект, производный от FOX-овского виджета и агента. Оказалось, что как только FOX-овский виджет закрывается, соответствующий ему объект сразу уничтожается. Без какой-либо возможности отложенных действий (агент не мог исчезнуть в одночасье).

Во всех этих случаях GC был бы идеальным решением.

А в остальном да, RAII очень классная штука.

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

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

R>>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
S>MS CLI. Но это монстр ещё тот.

Это читерство. CLI — это не язык, а платформа.
Вопрос — есть ли эта возможность в каком-либо языке.
З.Ы. наверное правильнее MS .NET, либо ISO CLI.

Кстати, если ты про delete для управляемых объектов в c++/cli, то это ж вроде только вызов синхронного деструктора, а само освобождение памяти по прежнему делается GC.

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

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

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

R>>>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
S>>MS CLI. Но это монстр ещё тот.

R>Это читерство. CLI — это не язык, а платформа.
CLI — язык со своим синтаксисом.
.NET — платформа для CLI.

R>Вопрос — есть ли эта возможность в каком-либо языке.
R>З.Ы. наверное правильнее MS .NET, либо ISO CLI.

R>Кстати, если ты про delete для управляемых объектов в c++/cli, то это ж вроде только вызов синхронного деструктора, а само освобождение памяти по прежнему делается GC.
Нет, я про то, что можно использовать как managed, так и unmanaged.

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

R>Если идти в сторону снижения предположений дальше, то скорее всего выбором будет С, а не С++, и уж точно не Java/C#. Не С99, а С89. Так же, если это сетевое приложение, то рассчитывать надо на модемное дайл-апное подключение. На ОС вообще надежды мало. Всё надо делать самому — включая юзер-левел тридинг и т.д... Разработка превращается в сущий ад — всё что хочешь сделать, и что сделать быстро, ты сделать не можешь.

R>Если идти в сторону увеличения предположений. То выбором будет С++ с полной поддержкорй шаблонов, а то и C#. ОС только одна. Сеть быстрая. И т.д. Разработка превращается в удовольствие. Но работать будет только на этой платформе...

R>Т.ч. с стоим выводом согласен — проблема не в шаблонах.

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

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

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

К сожалению, STL так спроектирован, что при его последовательном использовании для абстрагирования от шаблонов прийдётся переписывать весь код

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

E>Во всех этих случаях GC был бы идеальным решением.
Ну, вообще-то, тут всё понятно что делать. Эти объекты какие-то уведомления наверное же рассылают о своей смерти? Или как-то можно проверить, что объект уже сдох? По хэндлу там, скажем?

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

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

B>А для тебя будет трагедией, если ты приходишь в фирму, а там boost с STL'ем ?
Нет. Я ими иногда пользуюсь даже.
Просто они мне кажутся часто не лучшим выбором.

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

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

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

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

нет, корень ситуации с почти любой фичей, которая существовала к 98-му году, но не попала в стандартную библиотеку (например, хеши) — это огромное желание получить наконец стандарт. Иначе мы бы первой версии стандарта ждали бы до 2009 года.

E>Короче, сейчас у любой вменяемой конторы есть способ где-то взять какой-то sharel_ptr или разработать самостоятельно. ЗАДЁШЕВО. И пользоваться им с радостью...
Не сказал бы, что это настолько простая вещь, чтоб ее можно было задешево разработать самостоятельно.
Особенно если контора не нацелена на работу с нормальными программистами, а предпочитает брать студентов.

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

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

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

.>Можно, только что ты хочешь этим сказать??

А разве не получится проблем с владением?
Если я модефицирую код так:

T* p2 = p1.get();
shared_ptr<T> p3 = p2;
{
    shared_ptr<T> p1 = CreateT();
    p2 = p1.get();
    p3 = p2;
}
p3->my_method();

ничего не взорвётся?

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

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

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

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

R>>>>Кстати, на практике, какие есть языки, где есть "GC + возможность ручного управления"? На ум ни одного не приходит.
S>>>MS CLI. Но это монстр ещё тот.

R>>Это читерство. CLI — это не язык, а платформа.
S>CLI — язык со своим синтаксисом.
S>.NET — платформа для CLI.

Не путаешь с c++/cli?
А как тогда называется платформа, которую стандартизировала ISO? И каков синтаксис у языка CLI?

R>>Вопрос — есть ли эта возможность в каком-либо языке.
R>>З.Ы. наверное правильнее MS .NET, либо ISO CLI.

R>>Кстати, если ты про delete для управляемых объектов в c++/cli, то это ж вроде только вызов синхронного деструктора, а само освобождение памяти по прежнему делается GC.
S>Нет, я про то, что можно использовать как managed, так и unmanaged.

Хммм. Ну это не совсем то, что я имел в виду. Т.к. никакой объект нельзя либо подвергнуть GC, либо удалить явно.

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

[]

R>>Это читерство. CLI — это не язык, а платформа.
S>CLI — язык со своим синтаксисом.

строго говоря, cli — common language infrastructure

ты имеешь ввиду c++/cli?

S>.NET — платформа для CLI.

имплементация

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

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

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

Шаред птр в данном случае — абсолютно не критичны

Правда практически обычно используют интрузивные шаред птр.

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

R>Не путаешь с c++/cli?
R>А как тогда называется платформа, которую стандартизировала ISO? И каков синтаксис у языка CLI?
Пута

. Спасибо, за поправку

. Я не силен во всем, что связанно с .NET

.
Хотя последнее время приходится много на этом c++/cli программировать. Хорошо, что хоть не на C#

.

R>>>Вопрос — есть ли эта возможность в каком-либо языке.
S>>Нет, я про то, что можно использовать как managed, так и unmanaged.
R>Хммм. Ну это не совсем то, что я имел в виду. Т.к. никакой объект нельзя либо подвергнуть GC, либо удалить явно.
Угу. Понятно.
Тогда интересует теоретическая возможность такого подхода.
ИМХО, никакой сложности нет. Или есть?

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

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

КЛ>[]

R>>>Это читерство. CLI — это не язык, а платформа.
S>>CLI — язык со своим синтаксисом.

КЛ>строго говоря, cli — common language infrastructure

КЛ>ты имеешь ввиду c++/cli?

S>>.NET — платформа для CLI.

КЛ>имплементация

Да, спасибо. Был неправ.

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

J>Если мне это было нужно, я всегда пользовался std::vector<my_fat_class*> с явным временем жизни.
J>Более того, я на полную катушку использовал std::vector<xxx::auto_ptr<my_fat_class> > (естественно, с соответствующей версией СТЛ), потому что мне вектор нужен был просто для удобного хранения, и я никогда не пытался его сортировать или делать еще что-то в этом роде.
Ну это опасно, потому, что получается довольно незаметный подводный камень, о котором никто кроме тебя не помнит, пока ты не забудешь. ИМХО чем так использовать STL лучше совсем его не использовать

Хотя проще конечно привинтить свой какой-нибудь shared_ptr

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

J>нет, корень ситуации с почти любой фичей, которая существовала к 98-му году, но не попала в стандартную библиотеку (например, хеши) — это огромное желание получить наконец стандарт. Иначе мы бы первой версии стандарта ждали бы до 2009 года.
Ну спорными оказались вещи, которые неочевидно как лучше сделать...

E>>Короче, сейчас у любой вменяемой конторы есть способ где-то взять какой-то sharel_ptr или разработать самостоятельно. ЗАДЁШЕВО. И пользоваться им с радостью...
J>Не сказал бы, что это настолько простая вещь, чтоб ее можно было задешево разработать самостоятельно.
Да можно не разработать, а в книжке Александреску прочитать, или в бусте или ещё где.
Ну не надо там уже ничего придумывать. Почитать главу в книжке и сделать. У меня это сделает стажёр под присмотром.
J>Особенно если контора не нацелена на работу с нормальными программистами, а предпочитает брать студентов.
Ну в моём понимании "нормальный программист" не включает в себя понятие "умеет прогать шаблоны".
Мало того, чисто по опыту, "нормальный программист" ещё и противоречит "любит прогать шаблоны"

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

[]

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

А что мешает инстанциировать шаблоны на нормальном компайлере и потом юзать инстанциации?

[]

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

E>Ну в моём понимании "нормальный программист" не включает в себя понятие "умеет прогать шаблоны".
E>Мало того, чисто по опыту, "нормальный программист" ещё и противоречит "любит прогать шаблоны"

Ну это смотря какую задачу ему давать. Если формочки клепать — то определённо

"Нормальный программист" так же, например, не должен читать много академических статей

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

S>Тогда интересует теоретическая возможность такого подхода.
S>ИМХО, никакой сложности нет. Или есть?

Возможность наверное есть, смысла нет. Типа по разному аллокаторы оптимизированы.

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

КЛ>А что мешает инстанциировать шаблоны на нормальном компайлере и потом юзать инстанциации?

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

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

S>Тогда интересует теоретическая возможность такого подхода.
S>ИМХО, никакой сложности нет. Или есть?

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

Как сказал eao197, в D это есть.

> Шаред птр в данном случае — абсолютно не критичны

Правда практически обычно используют интрузивные шаред птр.

Только если слабые указатели не нужны.

Posted via RSDN NNTP Server 2.1 beta

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

B>>Ну вы же наверяка не ограничились умными указателями

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

B>>Так, по мелочам, только на ознакомление точно удет ненулевое время.

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

Ерунда. Про вектор, список и shared_ptr нормальному программисту известно всё. Начиная от стратегий выделения памяти и заканчивая возможностями оптимизации. Про самопальные контейнеры это не известно и там точно есть какие-то подводные камни.

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

R>Ну это смотря какую задачу ему давать. Если формочки клепать — то определённо

R>"Нормальный программист" так же, например, не должен читать много академических статей

Во всяком случае статей про буст там и шаблоны

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

Здравствуйте, Sergey, Вы писали:
>> Шаред птр в данном случае — абсолютно не критичны

Правда практически обычно используют интрузивные шаред птр.
S>Только если слабые указатели не нужны.
Часто можно обойтись интрузивными + обычные...

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

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

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

чушь. Либо у тебя фиговый опыт, либо с тобой что-то не так.

boost::shared_ptr
boost::scoped_array
boost::intrusive_ptr
boost::regex
boost::spirit

экономят мне кучу времени. Как от этой экономии может быть отрицательный эффект?

Ну, ок, пусть так. Но про STL это вообще bullshit.

std::vector
std::list
std::map
std::set
std::auto_ptr
+std::algorithms

Покрывает 99% моих потребностей. Со мной что-то не так? Может быть дело в том, что моя прога не моделирует термоядерные взрывы и не расшифровывает геном?

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

E>Вы бы хоть прокомментировали с какой из трёх частей не согласны?
E>С тем, что экономическая эффективность играет решающую роль?

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

E>С тем, что говорит мой опыт? (Заметьте, что на ваш опыт я не претендую. Я просто делюсь своим

)

[]

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

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

E>>Во всех этих случаях GC был бы идеальным решением.
E>Ну, вообще-то, тут всё понятно что делать. Эти объекты какие-то уведомления наверное же рассылают о своей смерти? Или как-то можно проверить, что объект уже сдох? По хэндлу там, скажем?

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

Это на словах все просто. А на практике это выливается с неделю-другую выкуривания бамбука, реализации и тестирования.

А в языках с GC вообще никаких заморочек.

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

NBN>Ерунда. Про вектор, список и shared_ptr нормальному программисту известно всё. Начиная от стратегий выделения памяти и заканчивая возможностями оптимизации. Про самопальные контейнеры это не известно и там точно есть какие-то подводные камни.

Э-э-э ты много видел нетривиальных реализаций?

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

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

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

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

а он настолько lightweight и independent, что его без труда можно вытащить as is

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

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

R>>Ну это смотря какую задачу ему давать. Если формочки клепать — то определённо

R>>"Нормальный программист" так же, например, не должен читать много академических статей

R>>

E>Во всяком случае статей про буст там и шаблоны

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

Ну это так, не особо академические, скорее практические...

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

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

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

E>>>Во всех этих случаях GC был бы идеальным решением.
E>>Ну, вообще-то, тут всё понятно что делать. Эти объекты какие-то уведомления наверное же рассылают о своей смерти? Или как-то можно проверить, что объект уже сдох? По хэндлу там, скажем?

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

E>Это на словах все просто. А на практике это выливается с неделю-другую выкуривания бамбука, реализации и тестирования.

E>А в языках с GC вообще никаких заморочек.

А чем это будет отличаться от создания всех объектов динамически и использования shared_ptr или shared_ptr/weak_ptr ?

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

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

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

КЛ>boost::shared_ptr
КЛ>boost::scoped_array
КЛ>boost::intrusive_ptr
КЛ>boost::regex
КЛ>boost::spirit

Ну ко всем этим средствам у меня есть вопросы. Тем не менее у нас есть либо аналоги, как правило намного долее древние, чем бустовские, либо нам это изделие вообще не нужно (скажем мы не используем аналог boost::shared_ptr, только аналог boost::intrusive_ptr)

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

КЛ>std::vector
КЛ>std::list
КЛ>std::map
КЛ>std::set
КЛ>std::auto_ptr
КЛ>+std::algorithms

КЛ>Покрывает 99% моих потребностей. Со мной что-то не так? Может быть дело в том, что моя прога не моделирует термоядерные взрывы и не расшифровывает геном?

С тобой не так то, что ты как-то нервно обсуждаешь такие абстрактные темы

А вообще-то мне, например, в приведённом списке сильно не хватает hash_map, и не нужны совсем auto_ptr и почти все из algorithms.

Мало того, любой алгоритм из algorithms легко и быстро реализуется задёшево, потому что описан в книжках. ИМХО сильно полезен только Sort, но он есть и в нашей библиотеке...

E>>С тем, что экономическая эффективность играет решающую роль?
КЛ>Играет, но не всегда. Иногда не хочется ломать мозг, используя убогие средства, надеясь получить чуть больше, чем получишь используя нормальные.

А откуда такое уважение к себе? Почему тебе кажется, что фирменная библиотека обяательно "убогие средства"?

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

E>>С тем, что говорит мой опыт? (Заметьте, что на ваш опыт я не претендую. Я просто делюсь своим

)

КЛ>[]
Ну давай сойдёмся на таком вот резюме обмена опытом:
Ты не представляешь себе как можно эффективно и качественно программировать без буста и STL, поэтому он тебе кажется единственным вариантом,
А мне не повезло и я как-то был вынужден научиться всему тому же ещё до буста и STL и таки представляю что альтернатив много. ВОт делюсь опытом, не смотря на минусы

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

E>Возможно ты даже согласишься с обоими уточнениями

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

соглашусь

так что даже непонятно, что обсуждать теперь

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

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

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

Обе пока что весьма эффективны

Но это же ужасное ограничение! А если я пишу бустовские либы или у меня параллельный шароварный бизнес?

> E>>Во всех этих случаях GC был бы идеальным решением.
> E>Ну, вообще-то, тут всё понятно что делать. Эти объекты какие-то уведомления наверное же рассылают о своей смерти? Или как-то можно проверить, что объект уже сдох? По хэндлу там, скажем?
>
> E>Если так, то заводишь прокси-объект, которым и владеет твоя часть программы. А сам прокси убивается когда на него больше нет ссылок и грохает управляемый им объект, перед этим.
> E>Ну а когда управляемый объект присылант уведомление, что он разрушен, то прокси это дело запоминает и остаётся в таком вот получдохшем состоянии...
>
> Это на словах все просто. А на практике это выливается с неделю-другую выкуривания бамбука, реализации и тестирования.

А пару уже готовых shared/weak_ptr там использовать не получается? В либу жестко зашит голый указатель?

> А в языках с GC вообще никаких заморочек.

Зато они имеют тенденцию памяти жрать вдвое против реально необходимого

Posted via RSDN NNTP Server 2.1 beta

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

E>Не имеет значение, какой оверхед? Главное, что он будет заведомо.

Замечательный пример преждевременной оптимизации.

и его ,и еще много чего.
посмотри текущий драфт стандарта в соседней ветке.

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

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

E>А в языках с GC вообще никаких заморочек.

Вообще-то, как я понял, проблема в том, что ты не можешь контролировать момент разрушения каких-то объектов. Казалось бы, при чм тут GC? А если бы был у тебя GC, а объекты бы всё равно разрушались? Например по причине отгрузки DLL со всеми её статическими данными...

>>> Шаред птр в данном случае — абсолютно не критичны

Правда практически обычно используют интрузивные шаред птр.
> S>Только если слабые указатели не нужны.

> Часто можно обойтись интрузивными + обычные...

"Не нужны" именно это и означает — можно без проблем обойтись другими средствами. А вот чтобы не изобретать велосипеды в подобных: http://rsdn.ru/forum/message/2631426.aspx ситуациях (насчет ACE), шаред пойнтер как раз и предназначен.

Posted via RSDN NNTP Server 2.1 beta

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

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

Обе пока что весьма эффективны

J>Но это же ужасное ограничение! А если я пишу бустовские либы или у меня параллельный шароварный бизнес?
Ну вот ты там и не работаешь

Просто там все сотрудники совладельцы. Так что параллельный шароварный бизнес -- это как бы не совсем феер плей по отношению к партнёрам...

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

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

не видел ты настоящего самопального контейнера

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

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

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

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

КЛ>а он настолько lightweight и independent, что его без труда можно вытащить as is
Ну безусловно иметь счетчик на борту самое безопасное и быстрое решение. Вот только я смысла этого примера http://boost.org/libs/smart_ptr/test/intrusive_ptr_test.cpp не понимаю. Доработки самого класса фактически равны написанию маленького велосипеда.

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

J>>Но это же ужасное ограничение! А если я пишу бустовские либы или у меня параллельный шароварный бизнес?
E>Просто там все сотрудники совладельцы. Так что параллельный шароварный бизнес -- это как бы не совсем феер плей по отношению к партнёрам...

с какой это стати? Я вот работаю в банке — как мне это помешает писать и продавать игрушки для мобильников? И в каком месте это будет нечестно по отношению в банку, если мы ни в одной точке не конкуренты?

Вот если твой бизнес играет против общего — тогда оно конечно.

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

.>Erop wrote:

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

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

.>Можно, только что ты хочешь этим сказать??
да нельзя так

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

КЛ>а он настолько lightweight и independent, что его без труда можно вытащить as is

Вау!
Какие люди и за велосипеды выступают!!!
Одна из основных проблем буста в том, что его нельзя брать по частям. Он всё время как-то меняется, и надо либо перевыдёргивать нужную тебе часть, либо поддерживать её самому. Получается тот же велосипед, но неудобный. Лучше уж совсем свой тогда...

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

E>В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:

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

E>Вот поэтому я с сарказмом и говорю о стандартных решениях стандартных проблем.

http://article.gmane.org/gmane.comp.lib.boost.devel/163682

ревью закончилось вчера, но если поторопишься — успеешь послать свое

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

J>не видел ты настоящего самопального контейнера

Ну бывают и неудачные реализации спецификации "самопальный контейнер"

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

J>>>Но это же ужасное ограничение! А если я пишу бустовские либы или у меня параллельный шароварный бизнес?
E>>Просто там все сотрудники совладельцы. Так что параллельный шароварный бизнес -- это как бы не совсем феер плей по отношению к партнёрам...

J>с какой это стати? Я вот работаю в банке — как мне это помешает писать и продавать игрушки для мобильников? И в каком месте это будет нечестно по отношению в банку, если мы ни в одной точке не конкуренты?

Ну ИМ так удобно. Зато работать можно когда и где угодно...
ТЕБЕ это наверное не подходит. Тебе, видимо, больше нравится работать 8 часов в день, 5 дней в неделю...

J>Вот если твой бизнес играет против общего — тогда оно конечно.
Ну это как раб. время считать, сверхурочные там всякие. Многим работа в радость, вообще-то

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

S>А вот чтобы не изобретать велосипеды в подобных: http://rsdn.ru/forum/message/2631426.aspx ситуациях (насчет ACE), шаред пойнтер как раз и предназначен.

Так не помог ему shared_pointer...

> S>А вот чтобы не изобретать велосипеды в подобных: http://rsdn.ru/forum/message/2631426.aspx ситуациях (насчет ACE), шаред пойнтер как раз и предназначен.
>
> Так не помог ему shared_pointer...

Я думаю, он его и не пробовал...

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

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

J>>с какой это стати? Я вот работаю в банке — как мне это помешает писать и продавать игрушки для мобильников? И в каком месте это будет нечестно по отношению в банку, если мы ни в одной точке не конкуренты?

E>Ну ИМ так удобно. Зато работать можно когда и где угодно...
E>ТЕБЕ это наверное не подходит. Тебе, видимо, больше нравится работать 8 часов в день, 5 дней в неделю...

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

А проблема со временем решается заранее оговоренным объемом работы.
Вот у меня, например, в Москве группа была (музыыкальная), играли и зарабатывали (

) деньги. Тоже нечестно?

J>>Вот если твой бизнес играет против общего — тогда оно конечно.
E>Ну это как раб. время считать, сверхурочные там всякие. Многим работа в радость, вообще-то

Ну мне работа в радость, и что?

Ты так и не ответил, в чем нечестность состоит.

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

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

J>>Если мне это было нужно, я всегда пользовался std::vector<my_fat_class*> с явным временем жизни.
J>>Более того, я на полную катушку использовал std::vector<xxx::auto_ptr<my_fat_class> > (естественно, с соответствующей версией СТЛ), потому что мне вектор нужен был просто для удобного хранения, и я никогда не пытался его сортировать или делать еще что-то в этом роде.
E>Ну это опасно, потому, что получается довольно незаметный подводный камень, о котором никто кроме тебя не помнит, пока ты не забудешь. ИМХО чем так использовать STL лучше совсем его не использовать

Вот еще

Слишком много вкусностей в СТЛ, чтоб ради только этого отказаться от нее

А эту прогу писал я один и всегда помнил об этом, как "Отче наш"

E>Хотя проще конечно привинтить свой какой-нибудь shared_ptr

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

это было в черт-те-лохматом году, когда никакого буста не было еще. Была только VC6.0 (без сервиспаков)

J>>нет, корень ситуации с почти любой фичей, которая существовала к 98-му году, но не попала в стандартную библиотеку (например, хеши) — это огромное желание получить наконец стандарт. Иначе мы бы первой версии стандарта ждали бы до 2009 года.
E>Ну спорными оказались вещи, которые неочевидно как лучше сделать...

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

E>Ну в моём понимании "нормальный программист" не включает в себя понятие "умеет прогать шаблоны".
E>Мало того, чисто по опыту, "нормальный программист" ещё и противоречит "любит прогать шаблоны"

эээ... и кто же я после этого?

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

P>Ну безусловно иметь счетчик на борту самое безопасное и быстрое решение. Вот только я смысла этого примера http://boost.org/libs/smart_ptr/test/intrusive_ptr_test.cpp не понимаю. Доработки самого класса фактически равны написанию маленького велосипеда.

достаточно просто написать внешние функции

      void intrusive_ptr_add_ref(T * p);
      void intrusive_ptr_release(T * p);

все.

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

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

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

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

J>Вот еще

Слишком много вкусностей в СТЛ, чтоб ради только этого отказаться от нее

Ну можно было отказаться от STL именно в этом месте

J>А эту прогу писал я один и всегда помнил об этом, как "Отче наш"

Ну приколлективной разработке это неприемлемо. Согласись, что такой код всё-таки опасен

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

>> Так не помог ему shared_pointer...
S>Я думаю, он его и не пробовал...
Откуда знаешь?
А ещё вопрос, как бы он мог помочь, кстати?

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

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

J>Можешь объяснить, зачем тебе понадобилось так писать?
Чтобы пояснить чего не позволяет хранить shared_ptr

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

Ну в случае шаредптра эту нужду обычно покрывают за счёт слабых указателей.

скажем есть узел дерева. Он имеет указатели на детей в виде shared_ptr, а детям тоже нужен указатель на отца, но невладеющий. Так как детё нельзя укокошить раньше отца. И чего делать?

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

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

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

жуть какая

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

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

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

Ну конкретно эти люди договорились только о коммерческом программировании. Жена и гитара никак не возбранялись

У одного, кстати, была группа, где он играл, а его жена пела

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

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

P>>Ну безусловно иметь счетчик на борту самое безопасное и быстрое решение. Вот только я смысла этого примера http://boost.org/libs/smart_ptr/test/intrusive_ptr_test.cpp не понимаю. Доработки самого класса фактически равны написанию маленького велосипеда.

J>достаточно просто написать внешние функции
J>

J>      void intrusive_ptr_add_ref(T * p);
J>      void intrusive_ptr_release(T * p);
J>

J>все.

Моя версия.

namespace intrusive_ptr_details
{
   struct IntrusiveCounter
   {
      IntrusiveCounter() : count( 0 ) {}
      IntrusiveCounter( IntrusiveCounter const & ) : count( 0 ) {} 
      IntrusiveCounter & operator=( IntrusiveCounter const & ) { return *this; }
      size_t count;
   };
}

#define DECLARE_INTRUSIVE_COUNTER(name)                                            \
   intrusive_ptr_details::IntrusiveCounter _ptr_count_;                                \
   friend void intrusive_ptr_add_ref( name * p ) { ++p->_ptr_count_.count; }                \
   friend void intrusive_ptr_release( name * p ) { if( --p->_ptr_count_.count == 0 ) delete p; } 

#define INTRUSIVE_SMART_PTR(name) boost::intrusive_ptr<name>

#define DECLARE_INTRUSIVE_COUNTER_MUTABLE(name)                                          \
   mutable intrusive_ptr_details::IntrusiveCounter _ptr_count_;                              \
   friend void intrusive_ptr_add_ref( name const * p ) { ++p->_ptr_count_.count; }                \
   friend void intrusive_ptr_release( name const * p ) { if( --p->_ptr_count_.count == 0 ) delete p; } 

#define INTRUSIVE_SMART_PTR_CONST(name) boost::intrusive_ptr<name const>

Использовать так:

struct A
{
DECLARE_INTRUSIVE_COUNTER(A)
};

typedef INTRUSIVE_SMART_PTR(A) APtr;

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

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

КЛ>>А что мешает инстанциировать шаблоны на нормальном компайлере и потом юзать инстанциации?

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

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

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

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

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

J>>Можешь объяснить, зачем тебе понадобилось так писать?
E>Чтобы пояснить чего не позволяет хранить shared_ptr

аргумент из серии int *p = new int; delete p; delete p;

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

E>Ну в случае шаредптра эту нужду обычно покрывают за счёт слабых указателей.

E>скажем есть узел дерева. Он имеет указатели на детей в виде shared_ptr, а детям тоже нужен указатель на отца, но невладеющий. Так как детё нельзя укокошить раньше отца. И чего делать?

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

насчет weak_ptr — а что тебе не нравится-то, я так и не понял? слово weak?

P.S. По-моему, на какой-то такой вопрос я уже отвечал здесь, показывал, что все отлично чистится в правильном порядке независимо от сценария убиения. Дежа вю

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

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

КЛ>>чушь. Либо у тебя фиговый опыт, либо с тобой что-то не так.
E>Ну возможно у тебя нет опыта, как хорошо жить без STL и буста...
E>Конечно с голым C++ жить ещё хуже...
E>А что касается могео опыта, то я думаю, что ты, например пользуешься программой, которую писал в том числе и я

Какой? Мне серьезно интересно.

[]

Минус тебе поставил, тк ты не написал про очень важный нюанс: "Применение STL/boost может иметь отрицательный эффект по сравнению с применением аналогичных библиотек".

Тут я пожалуй, соглашусь.

>>> Так не помог ему shared_pointer...
> S>Я думаю, он его и не пробовал...
> Откуда знаешь?

А откуда знаешь, что не помог?

> А ещё вопрос, как бы он мог помочь, кстати?

Во владельце — shared_ptr на объект, в потребителях (Event_Handler в данном случае) — weak_ptr. При необходимости обращения к объекту из потребителя из weak_ptr конструируется shared_ptr. Если объект уже убит, конструктор shared_ptr кинет исключение boost::bad_weak_ptr.

Posted via RSDN NNTP Server 2.1 beta

Erop wrote:

>>> shared_ptr<T> p1 = CreateT();
>>> T* p2 = p1*.get()*;
>>> shared_ptr<T> p3 = p2;
> .>Можно, только что ты хочешь этим сказать??
> А разве не получится проблем с владением?
Дык ты сам их захотел. Вот они и появились. Или я не понял, что ты хочешь от этого кода. Может тебе нужне weak_ptr?

Posted via RSDN NNTP Server 2.1 beta

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

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

КЛ>>а он настолько lightweight и independent, что его без труда можно вытащить as is

E>Вау!
E>Какие люди и за велосипеды выступают!!!

вы мне льстите

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

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

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

КЛ>Какой? Мне серьезно интересно.
Ну я не хочу/могу разглашать место работы.
Особенно на форуме.

Одна из офисных программ, или другая, или ещё одна

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

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

S>Во владельце — shared_ptr на объект, в потребителях (Event_Handler в данном случае) — weak_ptr. При необходимости обращения к объекту из потребителя из weak_ptr конструируется shared_ptr. Если объект уже убит, конструктор shared_ptr кинет исключение boost::bad_weak_ptr.

Пардон! Если можно менять саморазрушающийся объект, то и проблем никаких. Просто он в прокси взводит фладок "я умер" и всё. Даже без shared_ptr всё получится. Хоть на автоматических объектах...

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

КЛ>ну кое-что можно брать частями. Поддерживать совсем необязательно, по крайней мере это нужно делать довольно редко. Совсем свой иногда может обойтись в копеечку/время. И не забывай, что буст пишут профи, велосипеды — в основном нет.

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

3) Перед актом велосипелостроительства, в буст можно заглянуть и подумать зачем им всё это. И не только в буст...

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

.>Дык ты сам их захотел. Вот они и появились. Или я не понял, что ты хочешь от этого кода. Может тебе нужне weak_ptr?

Ну а теперь читаем исходное сообщение

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

J>P.S. По-моему, на какой-то такой вопрос я уже отвечал здесь, показывал, что все отлично чистится в правильном порядке независимо от сценария убиения. Дежа вю

Я знаю как пользоваться бустовскими умными указателями.
Я просто скромно указывал, что за shared_ptr неизбежно приползёт weak_ptr...

> S>Во владельце — shared_ptr на объект, в потребителях (Event_Handler в данном случае) — weak_ptr. При необходимости обращения к объекту из потребителя из weak_ptr конструируется shared_ptr. Если объект уже убит, конструктор shared_ptr кинет исключение boost::bad_weak_ptr.
>
> Пардон! Если можно менять саморазрушающийся объект, то и проблем никаких. Просто он в прокси взводит фладок "я умер" и всё. Даже без shared_ptr всё получится. Хоть на автоматических объектах...

Понятно, что и без shared_ptr всё получится. Просто придется повторять часть его функциональности. Зачем, если оно уже есть готовое и отлаженное?

Posted via RSDN NNTP Server 2.1 beta

> S>Понятно, что и без shared_ptr всё получится. Просто придется повторять часть его функциональности. Зачем, если оно уже есть готовое и отлаженное?
>
> Возможно без shared_ptr будет даже проще.

Без shared_ptr получилось следующее: "А на практике это выливается с неделю-другую выкуривания бамбука, реализации и тестирования"

> Но это не важно. Главное, что в приведённом случае это всё не помогает

С чего ты взял? От ACE_Event_Handler один черт наследоваться надо, чего б туда shared_ptr не впихнуть?

Posted via RSDN NNTP Server 2.1 beta

Erop пишет:
>
> 2) Профи или не профи пишут внутренние библиотеки зависит от персонала.
> Конечно если у вас в комании работают чуваки, которые вовсе и не профи а
> ламеры ламерами и ничего кроме, как использовать буст не умеют...

> 3) Перед актом велосипелостроительства, в буст можно заглянуть и
> подумать зачем им всё это. И не только в буст...

О это еще что, а вот когда и буст не умеют и stl не умеют и С++ — это С
со структурами с методами (тьфу, классами). И такое бывает, видал и не раз.
Вот тогда чаще всего велосипеды и строят.

З.Ы. Но это так оффтоп было.

Posted via RSDN NNTP Server 2.0

Erop wrote:

> .>Дык ты сам их захотел. Вот они и появились. Или я не понял, что ты
> хочешь от этого кода. Может тебе нужне weak_ptr?
>
> Ну а теперь читаем исходное сообщение
> <http://rsdn.ru/forum/message/2631025.1.aspx>
Я так и не понял что он не позволяет. Всё он позволяет, особенно в купе с weak_ptr. А "неэффективности" тоже ты
насочинял. Скажи чего там лишнего?

Posted via RSDN NNTP Server 2.1 beta

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

E>Я знаю как пользоваться бустовскими умными указателями.
E>Я просто скромно указывал, что за shared_ptr неизбежно приползёт weak_ptr...

Естественно, приползет, хотя бы потому, что он вцементирован в сам shared_ptr — есть соответствующий конструктор:
template<class Y> explicit shared_ptr(weak_ptr<Y> const & r);

Я никак не пойму, в чем "пойнт" этих выступлений. Если о том, что одна библиотека тянет за собой другую, так они оба — части одной библиотеки smart_ptr: http://boost.org/libs/smart_ptr/smart_ptr.htm

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

NBN>>Ерунда. Про вектор, список и shared_ptr нормальному программисту известно всё. Начиная от стратегий выделения памяти и заканчивая возможностями оптимизации. Про самопальные контейнеры это не известно и там точно есть какие-то подводные камни.

E>Э-э-э ты много видел нетривиальных реализаций?

Всякие видел

Видел даже круче чем STL, контейнеры на стратегях. Например можно было варьировать — использовать аллокатор или нет и какой именно, или к примеру алгоритм расчета длины списка.
Видел _очень_ нетривиальные контейнеры, которые написал некий "гениальный" программист. В мою задачу входило прорефакторить код и избавиться от этих контейнеров (перевести код на STL), если честно я так и не смог осознать — как они работают. Пришлось догадываться по коду — что они делают и, фактически, писать некоторые функции с нуля. Правда, проблема неадекватных контейнеров была далеко не на первом месте среди проблем того кода

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

Ну смотря, что понимать под "владением". Добавить/удалить элемент? Или понимать как будет выделяться память, понимать идеологию библиотеки, представлять оптимальные решения типовых задач?

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

E>Во всяком случае статей про буст там и шаблоны

<offtop>
Вспоминаю ужос академических исходников... Брррр...

</offtop>

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

J>>не видел ты настоящего самопального контейнера

E>Ну бывают и неудачные реализации спецификации "самопальный контейнер"

Хм... Как правило бывают...
Конкретно я видел много самопала, но хороший был только мой. И то не весь

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

S>Понятно, что и без shared_ptr всё получится. Просто придется повторять часть его функциональности. Зачем, если оно уже есть готовое и отлаженное?

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

Именно поэтому, кстати, крайне редкий сборщик мусора реализован на подсчете ссылок. Пайтон пока, кажется, еще сопротивляется, но и они что-то сделают с этим, в конце концов, я думаю.

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

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

КЛ>>Какой? Мне серьезно интересно.
E>Ну я не хочу/могу разглашать место работы.
E>Особенно на форуме.

E>Одна из офисных программ, или другая, или ещё одна

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

Название компании из 5-ти букв?

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

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

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

если я правильно понял, то все жалобы выше сводятся лишь к тому, что нужно пользоватсья bcp, чтобы выдрать кусочек библиотеки? И все?
Так я тебе скажу, что надо делать

Не надо пользоваться bcp вообще. Устанавливаешь буст целиком, благо практически все библиотеки в нем header-only. И юзаешь только то, что тебе необходимо или только то, что поддерживается твоим компилятором (скажем, только shared_ptr). А другое просто не юзаешь. Очень просто

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

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

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

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

Очевидно, отказываться (т.е. переписывать весь код) не надо.
Я, вроде, к этому и не призывал

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

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

Надо исследовать. Естественно, представяя себе хотя бы примерно, через какие платформы придется пройти.
А то, может, лучше сразу отказаться от С++ и писать на чистом С.
Потому что на другой платформе вообще может не оказаться компилятора С++, и может оказаться, но до безобразия кривой и генерирующий такой же код.
Далее, эти все соображения относятся не только к использованию или неиспользованию буста, а к более чувствительным вещам, например: работают ли в принципе на данной платформе исключения, есть ли многопоточность и если есть, то в каком виде, какие возможности кучи/стека и т.д. Вполне может оказаться, что придется переписывать (и перепроектировать) программу с нуля, несмотря на то, что он в смысле буста девственно чиста.

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

Вообще странно, что заказчик диктует среду разработки. Вроде как, ему не шашечки должны быть нужны, а ехать. Ну да всякое в жизни бывает.

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

E>Вот-вот. А горячие головы при этом будут говорить: стандартная проблема, стандартное решение

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

Почему горячие? Ведь действительно стандартная библиотека и т.д. — посмотри драфт стандарта.
Другое дело, что (вот ты меня все-таки хочешь вытянуть на этот долгий разговор, да?) с многопоточностью в С++ вообще большие проблемы, встроенные, в дизайне языка. И свет пока что виден только в C++0x — собственно, это главный приоритет следующего стандарта: нормальная поддержка многопоточности со стороны языка (атомарные типы, барьеры и т.д.)

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

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

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

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

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

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

Компиляторы-то не дороге валяются. Erop может неверно выразился, но суть-то ясна.

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

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

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

B>>>Ну вы же наверяка не ограничились умными указателями

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

B>>>Так, по мелочам, только на ознакомление точно удет ненулевое время.

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

B>Я не адекватен

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

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

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

Ну, в принципе, бывают уроды, конечно, но интересно бы посмотреть на достижения велосепедостроительства в области массивов, например.

Итак, кто какой самый "самобытный" массив видел? Такой, чито фиг въедешь?

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

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

NBN>Ну смотря, что понимать под "владением". Добавить/удалить элемент? Или понимать как будет выделяться память, понимать идеологию библиотеки, представлять оптимальные решения типовых задач?

Ну вот примерно на это и надо час где-то. Может ещё час на иделологию библиотки в целом (там есть некоторая фишка по поводу тонкостей работы с памятью)

Вот в целом-то и всё...
Во всяком случае всё с контейнерами.

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

NBN>Конкретно я видел много самопала, но хороший был только мой. И то не весь

Ну весь не весь, но бывают "самопальные" контейнеры, которые, по крайней мере, не хуже STL уж точно...

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

J>Так я тебе скажу, что надо делать

Увы, есть пара подводных камней.
1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста
2) Когда гром таки грянет не всегда просто понять, а что же таки наиспользовали господа разработчики и что же из буста реально работает, и что использовани переносимо...
В этом смысле своя библиотека радикально лучше управляема и поддерживаема.

J>Насчет поддерживать актуальность....Автоматика здесь слишком дорого может встать.
+1
Проблема не в том, что актуальность, а в том, что находятся ошибки и их надо править синхронно в своей версии. Вторая проблема в том, что разнеые части проекта заимствуют разные версии библиотеки (если она не поддерживается актуальной), а потом ты наблюдаешь довольно прикольные интерферреционные эффекты

E>>Я не говорил про полный маразм вроде запрещения шаблонов, исключений или STL.
J>А он-таки встречается в реальной жизни.
Ну я в реальной жизни встречал запрет в такой форме: "обоснуй, пожалуйста, выгоду от использования предлагаемого средства"

J>Но если ты начинаешь писать новый код, и вместо того, чтобы обойтись одной строчкой, тебе приходится неделю корпеть над _макросами_ и прогулками по куче (я не шучу, это случай из реальной жизни) — я не вижу ну ни одного вменяемого аргумента против этой строчки, за исключением "мы набираем дешевых идиотов, так что не умничай и гоняй макросы, как все"

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

J>Далее, эти все соображения относятся не только к использованию или неиспользованию буста, а к более чувствительным вещам, например: работают ли в принципе на данной платформе исключения, есть ли многопоточность и если есть, то в каком виде, какие возможности кучи/стека и т.д. Вполне может оказаться, что придется переписывать (и перепроектировать) программу с нуля, несмотря на то, что он в смысле буста девственно чиста.
У меня есть заметный опыт в переносе кода на разные платформы. А у нашей конторы такого опыта вообще вагоны. В том числе на экзотические и довольно убогие. Среди убогих были и такие, где не было возможности иметь конструкторы статических объектов и такие, гед не было исключений, и такие, где шаблоны были не супер. ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.
Второй источник гемора -- это конечно исключения. Но при некотором подходе к использованию исключений можно получить все адвантез, и при этом не сильно попасть, в случае, если таки надо от исключений избавится.

Короче мой выбор такой: Надо выбрать такой компромисный способ использования и шаблонов и исключений и конструкторов статических объектов (включая синглетоны и объекты из DLL), чтобы пользу более или менее всю иметь от этих механизмов, а зависить от них не очень драматически.
К сожалению STL в эту парадигму совсем не укладывается по многим причинам. Вот мы его и не используем

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

J>Почему горячие? Ведь действительно стандартная библиотека и т.д. — посмотри драфт стандарта.
J>Другое дело, что (вот ты меня все-таки хочешь вытянуть на этот долгий разговор, да?) с многопоточностью в С++ вообще большие проблемы, встроенные, в дизайне языка. И свет пока что виден только в C++0x — собственно, это главный приоритет следующего стандарта: нормальная поддержка многопоточности со стороны языка (атомарные типы, барьеры и т.д.)

Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения

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

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

AA>Название компании из 5-ти букв?
Ну я и так много сказал. Но на одном из языков одно из слов действительно из пяти букв

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

AA>К сожалению, да. И в этом плане, внешний счетчик выглядит безопаснее внутреннего, так как кто попало не может захватить указатель, нарастив ссылку. Ибо как с подсчетом ссылок основная забава при работе в довольно большой команде — это отлов циклических "захватов". Обнаруживается, как правило, в самый неподходящий момент и иногда ведет к серьезным изменениям в дизайне...

А как shared_ptr помогает от циклического захвата ссылок? "Кто-нибудь" -- это очень мощный персонаж обычно

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

>> 2) Профи или не профи пишут внутренние библиотеки зависит от персонала.
V>О это еще что, а вот когда и буст не умеют и stl не умеют и С++ — это С
V>со структурами с методами (тьфу, классами). И такое бывает, видал и не раз.
V>Вот тогда чаще всего велосипеды и строят.

Но моё ИМХО, кстати такое, что даже это не критично. Это всё неприятно конечно, но обычно такой параметр, как "качество и поддерживаемость кода" зависит не от того "С с классами" или "STL с бустом", а от каких-то других характеристик кода.

В целом лично я скорее согласен иметь дело с хорошим кодом на "С с классами/структурами" или вообще просто на С, чем с плохим, с использованием любых самых продвинутых идей и средств

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

>> Ну а теперь читаем исходное сообщение
>> <http://rsdn.ru/forum/message/2631025.1.aspx>
.>Я так и не понял что он не позволяет. Всё он позволяет, особенно в купе с weak_ptr. А "неэффективности" тоже ты
.>насочинял. Скажи чего там лишнего?

1) Про неэффективность по памяти писал не я.
2) ИМХО хуже не то, что он по памяти неэффективен, а то, что он не позволяет произвольно использовать код, в котором пользуются просто указатели. Хотя это всё решается конечно, но ценой усложнения то там, то сям.
Ну, например, просто указатели можно хранить как POD и особо не церемониться. С weak_ptr так уже не погоняешь...

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

J>Я никак не пойму, в чем "пойнт" этих выступлений. Если о том, что одна библиотека тянет за собой другую, так они оба — части одной библиотеки smart_ptr: http://boost.org/libs/smart_ptr/smart_ptr.htm

поинт в том, что усложняется несколько весь работающий с shared/weak_ptr код, по сравнению с интрузивным указателем + просто указатель + продуманная схема владения объектами.

Лично мне, кстати, больше всего нравится такая конструкция:

1) Заводим аллокатор, который просто выдаёт память, сколько попросят из большого буфера (скажем докомичивает или довыделяет куски по мере исчерпания, не суть)
2) Какой-то алгоритм весь проделываем на таком аллокаторе. Всё, что аллокируется -- аллокируется там.
3) Результаты переносятся на другой аллокатор (или сразу на другом рожаются)
4) По окончании работы нашего алгоритма весе объекты "теряются", а всеь аллокатор грохается целиком.

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

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

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

Фиг знает. Заглючил че-то

E>Короче мой выбор такой: Надо выбрать такой компромисный способ использования и шаблонов и исключений и конструкторов статических объектов (включая синглетоны и объекты из DLL), чтобы пользу более или менее всю иметь от этих механизмов, а зависить от них не очень драматически.
E>К сожалению STL в эту парадигму совсем не укладывается по многим причинам. Вот мы его и не используем

да, я забыл ещё один мегаисточник -- когда закладываются явно или не явно на порядок вызова конструкторов статических объектов.
Ну и эндиан с выравниваеним, конечно...

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

Erop wrote:

> 1) Про неэффективность по памяти писал не я.
Кто? Где?

> 2) ИМХО хуже не то, что он по памяти неэффективен, а то, что он не
> позволяет произвольно использовать код, в котором пользуются просто
> указатели. Хотя это всё решается конечно, но ценой усложнения то там, то
> сям.
А кто позволяет? И за счёт чего?

> Ну, например, просто указатели можно хранить как POD и особо не
> церемониться. С weak_ptr так уже не погоняешь...
Дык храни просто указатели, weak_ptr просто позволяет обнаруживать умирание объекта. Просто указатели в принципе не могут.

Posted via RSDN NNTP Server 2.1 beta

Erop wrote:

> Вот такая вот замена GC. Дёшево, быстро и сердито. Есть проблемы.
> Главная -- требуется поддержка такой парадигмы библиотекой, чего от STL
> добиться нелегко
Нее... Проблема в том, что такая парадигма неуниверсальна, далеко не все алгоритмы и структуры данных в неё ложатся.

Posted via RSDN NNTP Server 2.1 beta

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

.>А кто позволяет? И за счёт чего?
Ну интрузивный, например, позволяет...

.>Дык храни просто указатели, weak_ptr просто позволяет обнаруживать умирание объекта. Просто указатели в принципе не могут.
Ну так от них неудобно потом к shared_ptr возвращаться

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

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

Конечно не все

Тогда удобны другие бывают. В том числе и умные указатели...

Erop wrote:

> .>А кто позволяет? И за счёт чего?
> Ну интрузивный, например, позволяет...
Ну и что что позволяет, зато он не позволяет другое.

> .>Дык храни просто указатели, weak_ptr просто позволяет обнаруживать
> умирание объекта. Просто указатели в принципе не могут.
> Ну так от них неудобно потом к shared_ptr возвращаться
А зачем?

Posted via RSDN NNTP Server 2.1 beta

Erop wrote:

> .>Нее... Проблема в том, что такая парадигма неуниверсальна, далеко не
> все алгоритмы и структуры данных в неё ложатся.
> Конечно не все Тогда удобны другие бывают. В том числе и умные указатели...
Т.е. проблема буста в том, что он не решает абсолютно все задачи абсолютно эффективно?

Posted via RSDN NNTP Server 2.1 beta

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

.>Т.е. проблема буста в том, что он не решает абсолютно все задачи абсолютно эффективно?
Проблема буста совсем в другом. Я уже в принципе объяснял свой мнеие по этому поводу.

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

Лишь бы практический выход был.

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

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

J>если я правильно понял, то все жалобы выше сводятся лишь к тому, что нужно пользоватсья bcp, чтобы выдрать кусочек библиотеки? И все?
J>Так я тебе скажу, что надо делать

Да, надцати мегабайтный дистрибутив за собой таскать, заказчикам передавать. И все ради пары классов, которые есть в составе других библиотек.

Не, я в 96-97-м наглотался с нестандартной STL в составе тогдашних C++ компиляторов. Проще подождать. Вот станет tr1 частью стандарта, будет в составе компиляторов, можно будет от заказчиков требовать "От С++ компилятора требуется поддержка стандарта C++09, в частности, наличие библиотек tr1", тогда другое дело.

J>Насчет поддерживать актуальность. Я лично никогда не рискну положиться на какой-то автоматический тул, который будет по своему усмотрению курочить библиотеку, на которой основан мой продукт. Никакой автоматики. Надо каждую версию ставить руками и тщательно тестировать на предмет "не сломалось ли чего". Автоматика здесь слишком дорого может встать.

Я пользуюсь RubyGems, где есть автоматическое отслеживание зависимостей и обновление -- и это работает. В C++ я использую подход на основе svn-свойств svn:externals. У нас даже PCRE, Crypto++, ACE в репозиториях лежат, и на конкретные их версии в проектах svn:externals настраиваются. Хотя наличие аналога RubyGems для C++ было бы лучше.

Так что твои опасения не оправданны. Естественно, что при переходе на новую версию подпроекта происходит тестирование всего проекта. Но сам переход оказывается проще, когда автоматический тул скажет, что подпроект версии такой-то зависит от другого подпроекта версии такой-то.

E>>Я не говорил про полный маразм вроде запрещения шаблонов, исключений или STL.
J>А он-таки встречается в реальной жизни.

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

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

J>Очевидно, отказываться (т.е. переписывать весь код) не надо.
J>Я, вроде, к этому и не призывал

Так и я не призывал к бойкоту boost-а. Имхо, какая-то нетерпимость проявляется к тем, кто boost не используется. Вот это и не нравится.

J>Но если ты начинаешь писать новый код, и вместо того, чтобы обойтись одной строчкой, тебе приходится неделю корпеть над _макросами_ и прогулками по куче (я не шучу, это случай из реальной жизни) — я не вижу ну ни одного вменяемого аргумента против этой строчки, за исключением "мы набираем дешевых идиотов, так что не умничай и гоняй макросы, как все"

Максим, а мы сейчас вообще о чем говорим? Макросы откуда-то взялись, проходы по куче...

C++ -- это мультпарадигменный язык. Мне он временами как раз за это и нравится. Вот если сравнивать с Eiffel-ем, в Eiffel-е все строго -- ООП и ни шагу, прыжок на месте провокация. Даже если на простом процедурном подходе можно проще все сделать. А в C++ -- как захочется, так и сделаешь.

Я, например, предпочитаю стиль "C с классами", с использованием шаблонов и STL. Но без фанатизма. Все более сложное, в том числе и метапрограммирование на шаблонах (когда в одну строку полтонны кода записывается), для меня лично слишком трудно. Для меня, например, ACE -- это практически идеальное соотношение полезности библиотеки к сложности ее исполнения. Crypto++ -- это уже перебор. А boost (в таких проявлениях, как spirit) -- это вообще overkill.

Посему как-то modern C++ design как-то не по мне, сложновато, некрасиво местами.

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

J>Надо исследовать. Естественно, представяя себе хотя бы примерно, через какие платформы придется пройти.

Бывают случаи, когда даже не представляешь. У меня было, как минимум, два случая, когда приходилось портировать код на платформы, о которых до этого я даже не слышал (в первый раз это была OS-9000, во второй -- HP NonStop).

Так что то, что ты написал -- все правильно. Но жизнь преподносит интересные сюрпризы.
А на чистом C писать -- это уже слишком, лучше в технические писатели переквалифицироваться.

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

J>Вообще странно, что заказчик диктует среду разработки. Вроде как, ему не шашечки должны быть нужны, а ехать. Ну да всякое в жизни бывает.

Да все просто -- мы ему библиотеки делаем, а они используют VC.6.0. Поэтому библиотеки должны работать под VC.6.0.

E>>Вот-вот. А горячие головы при этом будут говорить: стандартная проблема, стандартное решение

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

J>Почему горячие? Ведь действительно стандартная библиотека и т.д. — посмотри драфт стандарта.

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

Как только, так сразу

J>Другое дело, что (вот ты меня все-таки хочешь вытянуть на этот долгий разговор, да?) с многопоточностью в С++ вообще большие проблемы, встроенные, в дизайне языка. И свет пока что виден только в C++0x — собственно, это главный приоритет следующего стандарта: нормальная поддержка многопоточности со стороны языка (атомарные типы, барьеры и т.д.)

Нет, я тебя не в это хочу втянуть

Просто хочу объяснить, что возможна точка зрения, согласно которой boost -- это всего одна из C++ных библиотек. И может быть масса условий, при которых, например, boost::regex ничем не лучше pcre, boost::spirit -- antlr или bison/flex.

Более того, есть целые фреймворки (ACE, Poco, wxWidgets, Qt, FOX), которые включают в себя очень и очень много всего. В том числе и того, что пытаются заново перетащить в boost. Еще можно понять, зачем boost-е своя реализация нитей и примитивов синхронизации. Но вот зачем в boost-е пытаются сделать asio не обращая внимания на ACE? Единственное объяснение: у ACE есть фатальный недостаток -- его писали не мы.

Вещи типа boost::spirit и boost::expressive вообще за гранью моего понимания. Ну да ладно, тут уже доказали, что я тугодум и не могу простеньких задачек с использованием shared_ptr/weak_ptr решать. Уж ничего не поделаешь, такие люди тоже на C++ программируют. О нас так же нужно думать, мы тоже пользу приносить можем. Наверное

Да, так вот о boost-е. Мне кажется, что boost уже давно не столько библиотека (это ACE или Poco библиотеки), это социальный феномен. Это как "наш ответ Чемберлену" (в виде JVM, JDK и .NET). Мол все лучшее и прогрессивное в C++ концентрируется в boost-е.

Как центр консолидации усилий C++ников boost гораздо важнее, чем реализованные в нем вещи (имхо). И пусть так и будет. Пусть процветает, пухнет и монстроузнеет. Долгие лета, как говорится.

Только грусно становится, когда вдруг наталкиваешься на отношение: "Кто не с boost-ом, тот против нас".

Не правильно это.

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

E>Ну тут уж проще, имхо, место работы сменить. Если люди не понимают, за счет чего C++ отличается от C и какую пользу можно извлекать от RAII, шаблонов, STL-я и пр. -- то даже высокая оплата не в состоянии компенсировать безвозвратно утерянного времени, имхо.

Что-же это вы так плохо, о высокой оплате

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

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

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

J>>Вот еще

Слишком много вкусностей в СТЛ, чтоб ради только этого отказаться от нее

E>Ну можно было отказаться от STL именно в этом месте

не. Мне гораздо важнее было иметь автоматическое хранение и прочее.
Ни о какой сортировке и речи не могло идти по логике приложения — там строгая последовательность.

J>>А эту прогу писал я один и всегда помнил об этом, как "Отче наш"

E>Ну приколлективной разработке это неприемлемо. Согласись, что такой код всё-таки опасен

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

template<> void sort(BadVector::iterator i1, BadVector::iterator i2)
{
   int i[-1];
}

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

J>на самом деле, все это легко объезжается — просто специализируются опасные алгоритмы как-нть типа
J>

J>template<> void sort(BadVector::iterator i1, BadVector::iterator i2)
J>{
J>   int i[-1];
J>}
J>

Опасен такой путь, так как зависит от версии STL

А почему бы не сделать какой-нибудь простой умный указатель?
Ну или простого владельца вектора объектов, с delete[] в деструкторе?

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

E>Опасен такой путь, так как зависит от версии STL

Конечно, опасен, я же и не спорил с этим никогда

но ты сделай скидку на то, когда это писалось, и на то ,что проект был тупиковым (т.е. он должен был просто заработать, и после этого никакой дальнейшей разработки не предполагалось).
так что там много веселого кода было, например, мне часто нужно было сдвинуть итератор на 2 позиции, поэтому я просто писал ++++it;

E>А почему бы не сделать какой-нибудь простой умный указатель?
E>Ну или простого владельца вектора объектов, с delete[] в деструкторе?

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

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

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

.>>А кто позволяет? И за счёт чего?
E>Ну интрузивный, например, позволяет...
Что он позволяет? Разрулить циклические ссылки?
Если я правильно помню, в СОМ проблем предостаточно было с цикличискими ссылками, а там как раз интрузивный счетчик.

.>>Дык храни просто указатели, weak_ptr просто позволяет обнаруживать умирание объекта. Просто указатели в принципе не могут.
E>Ну так от них неудобно потом к shared_ptr возвращаться

это как это неудобно, когда соответствующей конструктор есть?
weak_ptr p;
shared_ptr s(p);
куда уж удобнее-то...

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

J>потому что мне нужно было все, что умеет вектор, но без извратов типа сортировки оного.
J>и для этого варианта тогдашний нестандартный auto_ptr работал.
А что нужно-то было? Аллокировать буфер и в конце разрушить?
Метод size и итернаторы?
По идее это реализуется в полчаса где-то. Итератор -- указатель просто, квадратные скобки там, то, сё...

J>По-хорошему, конечно, нужно было сделать
Конечно нада было. ИМХО именно такое вот "надо было сделать по-хорошему" портит код намного хуже, чем неиспользование/использование буста

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

.>>>Дык храни просто указатели, weak_ptr просто позволяет обнаруживать умирание объекта. Просто указатели в принципе не могут.
E>>Ну так от них неудобно потом к shared_ptr возвращаться

J>это как это неудобно, когда соответствующей конструктор есть?

J>weak_ptr p;
J>shared_ptr s(p);
J>куда уж удобнее-то...

Просто перечитай внимательно...
А ещё тэги рулят...

>>> Ну а теперь читаем исходное сообщение
>>> <http://rsdn.ru/forum/message/2631025.1.aspx>
> .>Я так и не понял что он не позволяет. Всё он позволяет, особенно в купе с weak_ptr. А "неэффективности" тоже ты
> .>насочинял. Скажи чего там лишнего?
>
> 1) Про неэффективность по памяти писал не я.
> 2) ИМХО хуже не то, что он по памяти неэффективен, а то, что он не позволяет произвольно использовать код, в котором пользуются просто указатели. Хотя это всё решается конечно, но ценой усложнения то там, то сям.
> Ну, например, просто указатели можно хранить как POD и особо не церемониться. С weak_ptr так уже не погоняешь...

Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.

Posted via RSDN NNTP Server 2.1 beta

> Просто хочу объяснить, что возможна точка зрения, согласно которой boost -- это всего одна из C++ных библиотек. И может быть масса условий, при которых, например, boost::regex ничем не лучше pcre, boost::spirit -- antlr или bison/flex.
>
> Более того, есть целые фреймворки (ACE, Poco, wxWidgets, Qt, FOX), которые включают в себя очень и очень много всего. В том числе и того, что пытаются заново перетащить в boost. Еще можно понять, зачем boost-е своя реализация нитей и примитивов синхронизации. Но вот зачем в boost-е пытаются сделать asio не обращая внимания на ACE? Единственное объяснение: у ACE есть фатальный недостаток -- его писали не мы.

Да нет, просто автор ACE видимо не предлагал включить ее в буст (и в общем-то не надо это никому — все на свете в буст тащить). А автор asio — предложил. И сумел всех убедить, что asio нужна в бусте. Типа это будет "ACE without the cruft.", "it would be 'lighter weight' than an ACE/TAO solution", "Unlike ACE, this library chooses not to expose the mechanism by which asynchronous operations are initiated. Furthermore, ACE does not guarantee that asynchronous operations will be available on a particular platform, whereas this proposed library does (the reference implementation demonstrates that asynchronous I/O can be efficiently emulated when native support is unavailable)." и т.д. Хотя лично мне asio не особо понравилась. Но ACE — это ж вообще ужос какой-то. В примеры asio я за полчаса въехал, про ACE же надо сначала толстый фолиант хотя бы бегло просмотреть.

> Вещи типа boost::spirit и boost::expressive вообще за гранью моего понимания. Ну да ладно, тут уже доказали, что я тугодум и не могу простеньких задачек с использованием shared_ptr/weak_ptr решать. Уж ничего не поделаешь, такие люди тоже на C++ программируют. О нас так же нужно думать, мы тоже пользу приносить можем. Наверное

Насчет спирита пожалуй соглашусь — штука занятная, но практически малополезная. Недавно переписал грамматику для xml-архивов из boost::serialization без спирита — получилось несколько объемнее (1100 строк против 600), зато работает быстрее и без переполнения стека. И самое главное — теперь можно зайти внутрь отладчиком и понять, что как парсится

> Да, так вот о boost-е. Мне кажется, что boost уже давно не столько библиотека (это ACE или Poco библиотеки), это социальный феномен. Это как "наш ответ Чемберлену" (в виде JVM, JDK и .NET). Мол все лучшее и прогрессивное в C++ концентрируется в boost-е.
>
> Как центр консолидации усилий C++ников boost гораздо важнее, чем реализованные в нем вещи (имхо). И пусть так и будет. Пусть процветает, пухнет и монстроузнеет. Долгие лета, как говорится.
>
> Только грусно становится, когда вдруг наталкиваешься на отношение: "Кто не с boost-ом, тот против нас".

> Не правильно это.

Ну просто иногда боязнь буста переходит разумные границы. Когда например человек пытается скормить в stl-алгоритм сложный функтор, сляпанный из bind2nd, mem_fun и подобных ужасов, а на предложение вместо этого воспользоваться boost::bind отвечает, что это слишком для него сложно, то и отношение к нему соответствующее.

Posted via RSDN NNTP Server 2.1 beta

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

NBN>>Конкретно я видел много самопала, но хороший был только мой. И то не весь

E>Ну весь не весь, но бывают "самопальные" контейнеры, которые, по крайней мере, не хуже STL уж точно...

Не, самопал не вариант. Я, например, изучил определенное количество популярных библиотек (BOOST, Qt, и проч.), включая STL ессно. Что-то очень хорошо, что еще не очень, что в процессе. Кое что применял и применяю на практике, кое что на примерах. Зато я это знаю. Знаю большинство проблем и их решение, знаю где мне быстро найти интересующую справочную инофрмацию. Знаю что по любой из этих библиотек я могу спросить здесь или где-либо еще — и мне ответят. Мне всего лишь надо будет привести версию используемой библы, компилятор и платформу. И этого хватит, чтобы мне помогли. Мне не нужно приводить тонну "самопального" кода, я не считаю что в нем остальные должны сидеть и копаться разбираться. Также как не считаю что я должен. Какие еще аргументы нужны?

Это удобно. Это плюс.

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

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

Это как нефть добывать. МОжно своими ведрами черпать и бурить лопатами кучей народу, все равно ведь окупиться

... << RSDN@Home 1.2.0 alpha rev. 710>>

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

S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект. Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

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

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

Просьба не воспринимать мои слова буквально. Они относятся только к пропагандам вида "STL, Boost и прос. зло потому что у нас без них все типа зашибись!"... Тут требуется сказать, что хорошо когда есть варианты, чтобы все конкретно в STL например не упиралось, но в качестве рекомендации самое то. Зачем создавать противоречия?

Создай свою альтернативную библиотеку, покажи народу, выложи в свободный доступ, а уже ПОТОМ остальные разговоры. А безосновательные "а у нас..." только сбивают с толку.

... << RSDN@Home 1.2.0 alpha rev. 710>>

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

E>2) ИМХО хуже не то, что он по памяти неэффективен, а то, что он не позволяет произвольно использовать код, в котором пользуются просто указатели. Хотя это всё решается конечно, но ценой усложнения то там, то сям.
E>Ну, например, просто указатели можно хранить как POD и особо не церемониться. С weak_ptr так уже не погоняешь...

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

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

E>Увы, есть пара подводных камней.
E>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста

есть такая штука — code review (она ведь у вас есть, не так ли?)

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

J>>Насчет поддерживать актуальность....Автоматика здесь слишком дорого может встать.
E>+1
E>Проблема не в том, что актуальность, а в том, что находятся ошибки и их надо править синхронно в своей версии. Вторая проблема в том, что разнеые части проекта заимствуют разные версии библиотеки (если она не поддерживается актуальной), а потом ты наблюдаешь довольно прикольные интерферреционные эффекты

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

E>>>Я не говорил про полный маразм вроде запрещения шаблонов, исключений или STL.
J>>А он-таки встречается в реальной жизни.
E>Ну я в реальной жизни встречал запрет в такой форме: "обоснуй, пожалуйста, выгоду от использования предлагаемого средства"

Значит, тебе везло с начальством

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

Рефакторить существующий код тоже сплошь и рядом запрещено административно.

Ибо "оно сейчас в таком виде работает и приносит деньги."

E>Идея в том, что если в конторе нормально поставлено дело и она старая, то тами без буста и без STL всё более или менее нормально. А что ненормально -- выпрямляют, безотносительно к внедрению STL'я.

Чаще менее нормально, чем более. И выпрямлять ни у кого духа не хватает, наоборот, ненормальность объявляется священной коровой

E>У меня есть заметный опыт в переносе кода на разные платформы. А у нашей конторы такого опыта вообще вагоны. В том числе на экзотические и довольно убогие. Среди убогих были и такие, где не было возможности иметь конструкторы статических объектов и такие, гед не было исключений, и такие, где шаблоны были не супер. ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.

Буст в этом смысле довольно неплох, кстати — там уже существует куча workarounds для разных странных платформ, и часто бывает так, что (если у тебя экхотическая платформа) один из этих хаков тебе подойдет (хаки эти включаются/выключаются соответствующими дефайнами в config.hpp). Буст все-таки разрабатывается и тестируется довольно интенсивно, особенно библиотеки общего назначения типа умных указателей и т.п. Пользователей буста все же всяко больше, чем любой доморощенной библиотеки, и условиях, в которых попробовали буст погонять, тоже больше, чем для самописной.

E>Второй источник гемора -- это конечно исключения. Но при некотором подходе к использованию исключений можно получить все адвантез, и при этом не сильно попасть, в случае, если таки надо от исключений избавится.

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

E>Короче мой выбор такой: Надо выбрать такой компромисный способ использования и шаблонов и исключений и конструкторов статических объектов (включая синглетоны и объекты из DLL), чтобы пользу более или менее всю иметь от этих механизмов, а зависить от них не очень драматически.
E>К сожалению STL в эту парадигму совсем не укладывается по многим причинам. Вот мы его и не используем

По каким конкретно, если не секрет?

J>>Вообще странно, что заказчик диктует среду разработки. Вроде как, ему не шашечки должны быть нужны, а ехать. Ну да всякое в жизни бывает.
E>Ну, например, ты делаешь плагин или библиотеку какую и уже автоматически зависишь по рантайму, скажем...
Ну для таких случаев — это да.

E>

J>>Почему горячие? Ведь действительно стандартная библиотека и т.д. — посмотри драфт стандарта.
J>>Другое дело, что (вот ты меня все-таки хочешь вытянуть на этот долгий разговор, да?) с многопоточностью в С++ вообще большие проблемы, встроенные, в дизайне языка. И свет пока что виден только в C++0x — собственно, это главный приоритет следующего стандарта: нормальная поддержка многопоточности со стороны языка (атомарные типы, барьеры и т.д.)

E>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения

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

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

А насчет языка для супер-параллельности — посмотри на Clik

Думаю, тебе понравится

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

V>...Создай свою альтернативную библиотеку, покажи народу, выложи в свободный доступ, а уже ПОТОМ остальные разговоры. А безосновательные "а у нас..." только сбивают с толку.

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

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

Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...

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

E>поинт в том, что усложняется несколько весь работающий с shared/weak_ptr код, по сравнению с интрузивным указателем + просто указатель + продуманная схема владения объектами.

Я бы сказал даже короче: продуманная схема владения объектами рулит

А уж на чем ты ее реализовал — пофиг, хоть на голых указателях.

E>Лично мне, кстати, больше всего нравится такая конструкция:

E>1) Заводим аллокатор, который просто выдаёт память, сколько попросят из большого буфера (скажем докомичивает или довыделяет куски по мере исчерпания, не суть)
E>2) Какой-то алгоритм весь проделываем на таком аллокаторе. Всё, что аллокируется -- аллокируется там.
E>3) Результаты переносятся на другой аллокатор (или сразу на другом рожаются)
E>4) По окончании работы нашего алгоритма весе объекты "теряются", а всеь аллокатор грохается целиком.

E>Вот такая вот замена GC. Дёшево, быстро и сердито. Есть проблемы. Главная -- требуется поддержка такой парадигмы библиотекой, чего от STL добиться нелегко

А в чем проблема? В том, что все объекты аллокатора должны быть одинаковыми?

Я делал проще (в том проекте, в котором было запрещено вообще все, кроме жутких контейнеров на макросах). Просто читал из БД все объекты в один контейнер, и они там лежали. Все остальные контейнеры хранили голые указатели внутрь этого главного контейнера, и к этим указателям, ессно, никогда delete не применялся. По окончании работы все прибивалось, после чего уничтожался главный контейнер, уже со всем содержимым.

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

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

V>>...Создай свою альтернативную библиотеку, покажи народу, выложи в свободный доступ, а уже ПОТОМ остальные разговоры. А безосновательные "а у нас..." только сбивают с толку.

E>Хорошие библиотеки обычно проприетарные и выложить их в общий доступ просто так нельзя.

E>Кроме того приватные библиотеки обычно хороши потому, что соответсвуют конторовскому стилю разработки. STl-то он общий очень. И понятно, что как общее решение проигрывает частному...

Только в частном случае. В общем случае же выигрывает. СИтуация прямо один в один с тем временем когда был переход с С на С++, тоже самое почти

.

Все таки программирование это практическая вещь, как ты правильно сам говоришь. Поэтому для общих случаев надо использовать общие решения. Такие, которые будут использоваться и дальше. Если, к примеру, я поступлю к вам на работу — изучу кучу ваших велосипедов, а потом как они мне пригодятся? Может ваш программист-идеолог уволиться, придет другой и скажет "другой велосипед!".

E>Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...

А ты прям предлогаешь либо вообще без буста, либо ВЕСЬ буст со всеми причиндалами — выжать из него все что только можно. Хотя второй вариант принесет вам дополнительные выгоды. Сказать какие?

Прославитесь!

... << RSDN@Home 1.2.0 alpha rev. 710>>

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

E>>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста
J>есть такая штука — code review (она ведь у вас есть, не так ли?)

А всё равно трудно. Например приходится поддерживать формальную какую-то структуру на тему о том, что можно, что нельзя, обучать экспертов, и т. д.

E>>В этом смысле своя библиотека радикально лучше управляема и поддерживаема.
J>во-первых, буст

J>А вот на это у нас как раз строгий запрет. Если меняется версия какой-либо библиотеки, которая используется в нескольких компонентах — все компоненты переезжают на нее одновременно.
Так это и обозначает, что надо всюду таскать с собой самый актуальный буст

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

J>Значит, тебе везло с начальством

Да мне и с собой везёт в целом

J>Рефакторить существующий код тоже сплошь и рядом запрещено административно.

J>Ибо "оно сейчас в таком виде работает и приносит деньги."
И это правильно!!!
Тут, как и везде в инженерной деятельности, нужен разумный компромис

E>>Идея в том, что если в конторе нормально поставлено дело и она старая, то тами без буста и без STL всё более или менее нормально. А что ненормально -- выпрямляют, безотносительно к внедрению STL'я.
J>Чаще менее нормально, чем более. И выпрямлять ни у кого духа не хватает, наоборот, ненормальность объявляется священной коровой

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

J>Буст в этом смысле довольно неплох, кстати — там уже существует куча workarounds для разных странных платформ, и часто бывает так, что (если у тебя экхотическая платформа) один из этих хаков тебе подойдет (хаки эти включаются/выключаются соответствующими дефайнами в config.hpp). Буст все-таки разрабатывается и тестируется довольно интенсивно, особенно библиотеки общего назначения типа умных указателей и т.п. Пользователей буста все же всяко больше, чем любой доморощенной библиотеки, и условиях, в которых попробовали буст погонять, тоже больше, чем для самописной.

Ну я вот буст переносить не пробовал. А с STL имел проблемы регулярно

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

E>>К сожалению STL в эту парадигму совсем не укладывается по многим причинам. Вот мы его и не используем

J>По каким конкретно, если не секрет?
Ну долго это рассказывать. Правда долго и занудно. Кроме того тебе наверное многое покажется странным. Подходы же они только в комплексе работают...

Я приведу один всего пример. В библиотеках, которые мне нравятся, перекрывают ::new/::delete для того, чтобы всякими хитрыми способами управлять стратегиями аллокации. Это позволяет делать аналог GC некий во многих нужных нам "прожорливых по памяти" алгоритмах, скажем. Ну и вообще это много чего позволяет. Кроме того есть ещё такая метода, что при обработке запроса, ты регишь где-то в запросе все критические ресурсы, а все некритические (например память под локальные на запрос объекты) аллокируешь на специальнйо куче запроса. В случае, если всё гавкнулось, то освобождаешь зарегистрированные критические ресурсы, и грохаешь всю кучу запроса. Восстанавливаешься таким образом.
Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...

E>>

E>>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения

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

J>Не, это именно к языку. Пока не определена семантика базовых операций в многопоточном окружении — никакая библиотека тебе не поможет, останется только молиться, что у тебя все сработает правильно. Так что комитет занимается очень правильным делом.
Ну де факто на платформах, где есть многопоточность вообще, реализация языка всё определила уже. Ну есть там несколько тонких мест, вроде синглетона Майерса, ну и что? ИМХО сам по себе синглетон, в том числе и Майерса не нужен

J>А насчет языка для супер-параллельности — посмотри на Clik

Думаю, тебе понравится

Да их много

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

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

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

J>Зависит от кода. Мне вот довольно много приходится работать с библиотеками, которые предоставляют почти что голый сишный интерфейс, и все у меня отлично уживаются вместе с shared_ptr.

Ну много от чего зависит. Хотя я согласен, если сразу запроектировать proxy-объекты для того, что убивается само по себе, вполне можно и с shared_ptr всё сделать. Правда я не очень понимаю зачем тогда shared_ptr нужен, но если он таки удобен, то от чего бы и нет?

> S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
> S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
> Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект.

Можно. У weak_ptr есть конструктор, принимающий shared_ptr, shared_ptr можно получить из указателя.

> Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся

Не нужны слабые указатели — пользуйся intrusive_ptr.

> Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

Думаешь, виртуальные базовые классы бесплатные?

Posted via RSDN NNTP Server 2.1 beta

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

>> S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
>> S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
>> Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект.

S>Можно. У weak_ptr есть конструктор, принимающий shared_ptr, shared_ptr можно получить из указателя.
Конечно можно, но только 1 раз

Если повторить этот процесс то создастся вторая копия счётчика ссылок

>> Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся

S>Не нужны слабые указатели — пользуйся intrusive_ptr.
Просто так один тип, чтоб не думать.

>> Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

S>Думаешь, виртуальные базовые классы бесплатные?
не бесплатные конечно, но иногда нужные. Можно и не виртуально наследовать если у обьекты только одного типа

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

E>Да, надцати мегабайтный дистрибутив за собой таскать, заказчикам передавать. И все ради пары классов, которые есть в составе других библиотек.

Ну тогда воспользуйся bcp. Ты им вообще пользовался-то? Я нет, так что ничего сказать не могу.

E>Не, я в 96-97-м наглотался с нестандартной STL в составе тогдашних C++ компиляторов. Проще подождать. Вот станет tr1 частью стандарта, будет в составе компиляторов, можно будет от заказчиков требовать "От С++ компилятора требуется поддержка стандарта C++09, в частности, наличие библиотек tr1", тогда другое дело.

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

Ну и проще все-таки подправить уже написанную реализацию на boost::shared_ptr на использование std::shared_ptr, чем использовать сейчас что-то совершенно левое с иной идеологией, а потом переходить на std::shared_ptr.

E>Хотя наличие аналога RubyGems для C++ было бы лучше.

Feel free to submit, как говорится

E>Так что твои опасения не оправданны. Естественно, что при переходе на новую версию подпроекта происходит тестирование всего проекта. Но сам переход оказывается проще, когда автоматический тул скажет, что подпроект версии такой-то зависит от другого подпроекта версии такой-то.

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

E>Ну тут уж проще, имхо, место работы сменить. Если люди не понимают, за счет чего C++ отличается от C и какую пользу можно извлекать от RAII, шаблонов, STL-я и пр. -- то даже высокая оплата не в состоянии компенсировать безвозвратно утерянного времени, имхо.

Вот я и сменил

E>Так и я не призывал к бойкоту boost-а. Имхо, какая-то нетерпимость проявляется к тем, кто boost не используется. Вот это и не нравится.

Зависит от причин, по которым он (вернее, конкретные библиотеки из него) не используются. Если причина идиотско-административная — нетерпимость естественна.

J>>Но если ты начинаешь писать новый код, и вместо того, чтобы обойтись одной строчкой, тебе приходится неделю корпеть над _макросами_ и прогулками по куче (я не шучу, это случай из реальной жизни) — я не вижу ну ни одного вменяемого аргумента против этой строчки, за исключением "мы набираем дешевых идиотов, так что не умничай и гоняй макросы, как все"

E>Максим, а мы сейчас вообще о чем говорим? Макросы откуда-то взялись, проходы по куче...

О реальной жизни мы говорим, все о ней, родимой.

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

E>А в C++ -- как захочется, так и сделаешь.
Это если нет запрета сверху делать так, как хочешь.

E>Для меня, например, ACE -- это практически идеальное соотношение полезности библиотеки к сложности ее исполнения.
Слишком много в ней ограничений. Надо все время наследоваться от ее классов, и т.д.
Практически невозможно ее прикрутить к уже существуюшей программе в качестве альтернативного движка.

E>Crypto++ -- это уже перебор. А boost (в таких проявлениях, как spirit) -- это вообще overkill.

Кому как

Мы вот используем спирит, чтобы парсить конфиги. Грамматика задается практически одной строчках, и на халяву получаешь контроль ошибок и гарантированно правильный парсинг. Соответственно мы не паримся о том, что нас текущий формат не удовлетворяет — идем и меняем, потому что парсилку проапдейтить — дело двух минут. А в предыдущем проекте (откуда я ушел) из доступных парсеров был только односимвольный токенайзер. И естественно, все конфиги были заточены под него, независимо от того, какой синтаксис был бы для данного конфига наиболее естественным.

E>Посему как-то modern C++ design как-то не по мне, сложновато, некрасиво местами.

Дело вкуса

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

J>>Надо исследовать. Естественно, представяя себе хотя бы примерно, через какие платформы придется пройти.

E>Бывают случаи, когда даже не представляешь. У меня было, как минимум, два случая, когда приходилось портировать код на платформы, о которых до этого я даже не слышал (в первый раз это была OS-9000, во второй -- HP NonStop).

Опять же, модульность помогает (если нет требования перенести весь код).

E>Так что то, что ты написал -- все правильно. Но жизнь преподносит интересные сюрпризы.
E>А на чистом C писать -- это уже слишком, лучше в технические писатели переквалифицироваться.

Это еще почему? Стройный простой язык, при известной дисциплине программирования, естественно.

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

J>>Вообще странно, что заказчик диктует среду разработки. Вроде как, ему не шашечки должны быть нужны, а ехать. Ну да всякое в жизни бывает.

E>Да все просто -- мы ему библиотеки делаем, а они используют VC.6.0. Поэтому библиотеки должны работать под VC.6.0.
Ну, тут выбора действительно нет. Хотя опять же, некоторые части буста работают на шестерке абсолютно без проблем. Почему не использовать их —

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

Боюсь, не начнешь

Скажешь — существующий код работает, менять нельзя

E>Просто хочу объяснить, что возможна точка зрения, согласно которой boost -- это всего одна из C++ных библиотек.
Это неправильная точка зрения. Буст — это _набор_ библиотек.
И какие-то из них действительно лучше существующих аналогов.

E>И может быть масса условий, при которых, например, boost::regex ничем не лучше pcre, boost::spirit -- antlr или bison/flex.
Может, конечно, кто ж спорит. Но если они равны для данной задачи — имеет смысл использовать буст, хотя бы потому, что, например, boost::regex уже в драфте стандарта.

E>Более того, есть целые фреймворки (ACE, Poco, wxWidgets, Qt, FOX), которые включают в себя очень и очень много всего. В том числе и того, что пытаются заново перетащить в boost. Еще можно понять, зачем boost-е своя реализация нитей и примитивов синхронизации. Но вот зачем в boost-е пытаются сделать asio не обращая внимания на ACE? Единственное объяснение: у ACE есть фатальный недостаток -- его писали не мы.

У АСЕ много фатальных недостатков, и главный — то, что это фреймворк. Т.е. если тебе нужно нечто, что уже не предусмотрено — тебе придется продублировать кучу кода.
И с чего ты взял, что не обращая внимания на АСЕ?
И с чего ты взял, что вообще есть такой критерий: "его писали не мы"? Да почти каждая новая включенная библиотека написана новым автором.
У тебя есть своя библиотека и она лучше всех остальных на эту тему? Feel free to submit! Только будь готов, что ее разберут по косточкам и ткнут носом во все темные или плохо реализованные места.

E>Да, так вот о boost-е. Мне кажется, что boost уже давно не столько библиотека (это ACE или Poco библиотеки), это социальный феномен. Это как "наш ответ Чемберлену" (в виде JVM, JDK и .NET). Мол все лучшее и прогрессивное в C++ концентрируется в boost-е.
E>Как центр консолидации усилий C++ников boost гораздо важнее, чем реализованные в нем вещи (имхо). И пусть так и будет. Пусть процветает, пухнет и монстроузнеет. Долгие лета, как говорится.
E>Только грусно становится, когда вдруг наталкиваешься на отношение: "Кто не с boost-ом, тот против нас".

E>Не правильно это.

Буст — это коллекция библиотек, которые будут понемногу включаться в Стандарт С++. Вот это — правильное определение.
Очевидно, что все хотят, чтобы в Стандарт вошло все самое лучшее и прогрессивное, или кто-то из присутствующих этого не хочет?

А с твоим имхом я ну никак не согласен, боюсь, оно основано на отсутствии у тебя опыта разработки с бустом.
Мне лично очень важны именно вещи, которые реализованы в нем, потому что от них напрямую зависит моя эффективность на работе.

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

Или взять, к примеру, multi_index. Библиотека не разрабатывалась для буста, она была совершенно самостоятельной и жила на CodeProject. И когда стало ясно, что лучше на эту тему библиотеки нет — ее включили в буст. (кстати, у тебя есть свой велосипед на эту тему? у меня вот нет и как-то не видно достойных альтернатив)
И ничего, не помешало то, что "ее писали не мы".

E>

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

И чего? Я в пустоту все это писал, что ли?

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

V>Только в частном случае. В общем случае же выигрывает. СИтуация прямо один в один с тем временем когда был переход с С на С++, тоже самое почти

.

Ну обычно есть частный случай "практика разработок в компании XXXsoft"

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

V>Может ваш программист-идеолог уволиться, придет другой и скажет "другой велосипед!".
Да нет никакого программиста-идеолога. Есть много продуманных решений и большой опыт преемственности и разработок...

E>>Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...

V>А ты прям предлогаешь либо вообще без буста, либо ВЕСЬ буст со всеми причиндалами — выжать из него все что только можно. Хотя второй вариант принесет вам дополнительные выгоды. Сказать какие?

Прославитесь!

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

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

L>Возьми Symbian-овские котейнеры и потрать минуту.

Прости, не помню что не так с Symbian-кими строками. На худой конец есть просто pure C, если всё так ужасно...
Но я знаю много нормальных вполне строк. Например MFC'шные, или ATL'ные...

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

J>Я бы сказал даже короче: продуманная схема владения объектами рулит

J>А уж на чем ты ее реализовал — пофиг, хоть на голых указателях.
Ну да. Продуманная схема -- ключевой ингридиент

E>>Лично мне, кстати, больше всего нравится такая конструкция:

E>>Вот такая вот замена GC. Дёшево, быстро и сердито. Есть проблемы. Главная -- требуется поддержка такой парадигмы библиотекой, чего от STL добиться нелегко

J>А в чем проблема? В том, что все объекты аллокатора должны быть одинаковыми?
Ну много проблем разных. Главная в том, что STL не имеет никаких средств для манипуляции аллокаторами памяти. Надо тогда везде векторы специально специфицировать, это где-то забудут...

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

Примерно то же самое, но другими средствами. Я примерно про это и говорю, что фишка не в STL или не STL, а в том, чтобы прогпть уметь

L>>Возьми Symbian-овские котейнеры и потрать минуту.
E>Прости, не помню что не так с Symbian-кими строками.

Там строки разбиты на две сущности — буфер и именно строка. + константные и неконстантные строки выражаются разными классами. + буфера для строк на стеке и в куче выражаются разными классами. В итоге имеем зоопарк из дюжины классов, в каждом — от десятка до сотни методов. При этом конкатенация двух строк — задача, повергающая новичка в ступор на пол-часа — час.

С контейнерами у них примерно такой же фейеричный дизайн.

Я это к тому, что зачастую велосипеды бывают такими, что вот так вот с наскоку с ними не разберёшься.

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

L>Там строки разбиты на две сущности — буфер и именно строка. + константные и неконстантные строки выражаются разными классами. + буфера для строк на стеке и в куче выражаются разными классами. В итоге имеем зоопарк из дюжины классов, в каждом — от десятка до сотни методов. При этом конкатенация двух строк — задача, повергающая новичка в ступор на пол-часа — час.

Скорее всего это зачем-то надо. Типа памятью управляют экономно. А хедер есть где посмотреть?

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

E>Скорее всего это зачем-то надо. Типа памятью управляют экономно. А хедер есть где посмотреть?

Вот статья. Если сильно нужен хедер, скажи — попробую выдрать из SDK
http://newlc.com/Using-Symbian-OS-String.html

E>Анологично. Похоже ты какую-то концепцию этой библиотеки не узнал вовремя...
Да с конецепциями-то всё понятно. Сложность вносит то что дизайн заточен как-то... ну как сказать... странно

К примеру — есть строка в куче, HBufC* str. Так вот, чтобы получить из неё константный указатель (const TDesC&) — надо её разыменовать, типа *str, а вот чтобы получить неконстантный (TDes&) надо вызвать метод Des, вот так вот: str->Des(). Ну и названия классов — краткие, но чтобы привыкнуть их читать приходится потратить определённое время...

Да, сорцы закрыты — в тонких моментах приходится разбираться "методом тыка".

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

L>TDesC&) — надо её разыменовать, типа *str, а вот чтобы получить неконстантный (TDes&) надо вызвать метод Des, вот так вот: str->Des().

Ну в этом нет ничего необычного или неожиданного. Таки модифицировать строку или просто использовать в функциональном стиле -- очень разная работа с данными. Это только в STL делают вид, что накладных расходов в этом вопросе не существует

Ну а названия классов всё равно у всех свои. Один хрен привыкать

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

L>Вот статья. Если сильно нужен хедер, скажи — попробую выдрать из SDK
L>http://newlc.com/Using-Symbian-OS-String.html

Спасибо.
Я посмотрел эту статью. Я так понял, что это надстройка над средствами ОС для работы со строками...
Ну привинтили эффективные строчки на автоматических буферах и на буферах аллокированых как-то специально в ОС. Я так понял, что конструкция _LIT( KText, "XXX" ) как-то размещает статический объект непосредственно в ПЗУ устройства?
Собственно люди хотели все статические строки иметь один раз и сразу в ПЗУ. ИМХО вполне понятное желание для этой ОС...

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

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

J>И чего? Я в пустоту все это писал, что ли?

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

А принцип "его писали не мы" -- это вот отсюда: http://www.lohnet.org/~hornlo/mutterings/wdjef/

...But another group within Microsoft discovered a fatal flaw in DDE: they didn’t write it!...

ну и далее по тексту. (русский перевод можно найти здесь: http://dibr.nnov.ru/print_issue020901.html).

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

E>А принцип "его писали не мы" -- это вот отсюда: http://www.lohnet.org/~hornlo/mutterings/wdjef/

я читал эту статью. Она, безусловно, смешная, но к бусту имеет мало отношения.
Еще раз повторю — если у тебя на примете есть библиотека, достойная быть принятой в Стандарт — закинь ее в Буст, в чем проблема?
Практически каждый раз, когда я вижу предложение принять библиотеку в буст — она исходет не от человека, который уже что-то в буст закинул.
Ну нету там такого принципа, понимаешь, нету.

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

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

.>>>>Дык храни просто указатели, weak_ptr просто позволяет обнаруживать умирание объекта. Просто указатели в принципе не могут.
E>>>Ну так от них неудобно потом к shared_ptr возвращаться

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

Ладно, проехали. Похоже, изначальная тема потерялась в процессе

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

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

typedef спасет отца русской демократии

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

S>Хотя последнее время приходится много на этом c++/cli программировать. Хорошо, что хоть не на C#

C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
Использовать его для основной разработки глупость.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

E>А если бы был у тебя GC, а объекты бы всё равно разрушались?
Такого в нормальных средах с ГЦ не бывает.

E>Например по причине отгрузки DLL со всеми её статическими данными...
ГЫ! Код и связанные с ним статические данные без разрешения ГЦ никуда не уберешь...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

E>>>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста
J>>есть такая штука — code review (она ведь у вас есть, не так ли?)

E>А всё равно трудно. Например приходится поддерживать формальную какую-то структуру на тему о том, что можно, что нельзя, обучать экспертов, и т. д.

Естественно, а без этого никуда и безо всякого буста. Кто-то же должен обоснованно принимать решения, где какая библиотека пригодна.
Ясное дело, что на откуп студентам такие решения отдавать не будешь.

E>>>В этом смысле своя библиотека радикально лучше управляема и поддерживаема.
J>>во-первых, буст
E>

Ну не дописал

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

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

J>>А вот на это у нас как раз строгий запрет. Если меняется версия какой-либо библиотеки, которая используется в нескольких компонентах — все компоненты переезжают на нее одновременно.
E>Так это и обозначает, что надо всюду таскать с собой самый актуальный буст

ну да, без него не скомпилируется

уж такой С++, если заюзал библиотеку — придется ее таскать

J>>Рефакторить существующий код тоже сплошь и рядом запрещено административно.

J>>Ибо "оно сейчас в таком виде работает и приносит деньги."
E>И это правильно!!!
E>Тут, как и везде в инженерной деятельности, нужен разумный компромис

Либо правильно, либо разумный компромисс

E>>>Идея в том, что если в конторе нормально поставлено дело и она старая, то тами без буста и без STL всё более или менее нормально. А что ненормально -- выпрямляют, безотносительно к внедрению STL'я.
J>>Чаще менее нормально, чем более. И выпрямлять ни у кого духа не хватает, наоборот, ненормальность объявляется священной коровой

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

E>Скажем если контора смогла выпустить пять версий продукта, то она более или менее владеет своим кодом. А всякие идеологические соображения -- это только идеологические соображения.
Очень оптимистичные вещи ты говоришь

А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
E>На самом деле код -- это всегда инструменты + соглашения + люди, которые этим всем пользуются. Без коллектива код мёртв. А что подходит тому или иному коллективу -- вопрос очень непростой.
Тут соглашусь.

J>>Буст в этом смысле довольно неплох, кстати — там уже существует куча workarounds для разных странных платформ, и часто бывает так, что (если у тебя экхотическая платформа) один из этих хаков тебе подойдет (хаки эти включаются/выключаются соответствующими дефайнами в config.hpp). Буст все-таки разрабатывается и тестируется довольно интенсивно, особенно библиотеки общего назначения типа умных указателей и т.п. Пользователей буста все же всяко больше, чем любой доморощенной библиотеки, и условиях, в которых попробовали буст погонять, тоже больше, чем для самописной.

E>Ну я вот буст переносить не пробовал.
А ты попробуй

Вдруг понравится

E>А с STL имел проблемы регулярно

С STL нельзя иметь проблемы, это странички из Стандарта.

С какой именно реализацией у тебя были проблемы? STLPort пробовал? Еще какие-нть пробовал? Почему остановились именно на той, с которой проблемы?

J>>имхо, написать код, который будет нормально работать и с исключениями, и без, по-человечески невозможно.
E>Ты не понял. Нужно написать такой код, который легко модифицировать так, чтобы не было исключений...
E>Но это правда непросто. Это требует довольно комплексного подхода...
Если не исключения — значит, коды возврата, правильно? Других выходов я не вижу. Ну разве что сразу abort звать

Код на исключениях и на кодах возврата отличается радикально.

E>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...
какого еще глобального goto? у тебя весь код в одной функции, что ли?

E>>>

E>>>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения

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

J>>Не, это именно к языку. Пока не определена семантика базовых операций в многопоточном окружении — никакая библиотека тебе не поможет, останется только молиться, что у тебя все сработает правильно. Так что комитет занимается очень правильным делом.
E>Ну де факто на платформах, где есть многопоточность вообще, реализация языка всё определила уже. Ну есть там несколько тонких мест, вроде синглетона Майерса, ну и что? ИМХО сам по себе синглетон, в том числе и Майерса не нужен

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

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

J>>А насчет языка для супер-параллельности — посмотри на Clik

Думаю, тебе понравится

E>Да их много

Просто это расширенный С. Или я опечатался, наверное, Cilk. Как-то так, в общем. Экспериментальная академическая разработка, использует кражу задач (work stealing).

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

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

AA>>К сожалению, да. И в этом плане, внешний счетчик выглядит безопаснее внутреннего, так как кто попало не может захватить указатель, нарастив ссылку. Ибо как с подсчетом ссылок основная забава при работе в довольно большой команде — это отлов циклических "захватов". Обнаруживается, как правило, в самый неподходящий момент и иногда ведет к серьезным изменениям в дизайне...

E>А как shared_ptr помогает от циклического захвата ссылок? "Кто-нибудь" -- это очень мощный персонаж обычно

Например, если кому-нибудь для инициализации передается некоторый интерфейс а-ля I*Site, который не предназначен для запоминания инициализирующимся, то передача голого указателя, на который нельзя просто так нарастить ссылку, может внести ясность. Впрочем, пользы от этого мало, ибо "мощный персонаж" может сконструировать другой shared_ptr и все становится совсем весело. Но сразу.

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

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

S>>Хотя последнее время приходится много на этом c++/cli программировать. Хорошо, что хоть не на C#

.
WH>

C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
WH>Использовать его для основной разработки глупость.

Объясни, почему. Есть проекты, где основной язык разработки — C++/CLI. Смотри Phonenix, например.

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

E>1) Довольно трудно ограничить использование разработчиками только того "что надо" из буста

grep --recursive --include=*.cpp --include=*.h -h "#include.*boost" * | sort | uniq
#include <boost/algorithm/string/case_conv.hpp>
#include <boost/bind.hpp>
#include <boost/crc.hpp>
#include <boost/cstdint.hpp>
#include <boost/filesystem/convenience.hpp>
#include <boost/filesystem/operations.hpp>
#include <boost/filesystem/path.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/noncopyable.hpp>
#include <boost/scoped_array.hpp>
#include <boost/scoped_ptr.hpp>
#include <boost/smart_ptr.hpp>
#include <boost/thread/condition.hpp>
#include <boost/thread/mutex.hpp>

Ы?

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

А в чем проблема? Ну разве что вопрошающий не воспринимает то что ему говорят... но это показатель к увольнению...

E>У меня есть заметный опыт в переносе кода на разные платформы. А у нашей конторы такого опыта вообще вагоны. В том числе на экзотические и довольно убогие. Среди убогих были и такие,
E>где не было возможности иметь конструкторы статических объектов и такие,
Статические объекты однозначно зло.
Но это уже отдельный флейм.
E>гед не было исключений, и такие,
А вот это засада еще та... Ибо для того чтобы жить без них нужно писать код совершенно иначе чем с ними.
И это совершенно иначе мне очень не нравится.
E>где шаблоны были не супер.
Насколько не супер? Скажем относительно VC++6.
E>ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.
А что там особо крутого? Ну не считая boost::mpl

E>Второй источник гемора -- это конечно исключения. Но при некотором подходе к использованию исключений можно получить все адвантез, и при этом не сильно попасть, в случае, если таки надо от исключений избавится.
Боюсь избавится от исключений куда сложнее чем от шаблонов...

E>Ну, например, ты делаешь плагин или библиотеку какую и уже автоматически зависишь по рантайму, скажем...
Я вот знаю одну библиотеку написанную на С++ с шаблонами и исключениями при том имеющею Сшный интерфейс...
Прекрасно живет в so'шках и dll'ках...

E>Вот многопоточность -- это да. Только мне кажется, что C++ всё ранво для многопоточности будет не супер. Тут нас ещё ждут какие-то революции и свершения

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

E>>А принцип "его писали не мы" -- это вот отсюда: http://www.lohnet.org/~hornlo/mutterings/wdjef/

J>я читал эту статью. Она, безусловно, смешная, но к бусту имеет мало отношения.

Это как посмотреть.

J>Еще раз повторю — если у тебя на примете есть библиотека, достойная быть принятой в Стандарт — закинь ее в Буст, в чем проблема?

Я тут вот о чем подумал по дороге домой: ну вот станет boost::regex частью стандарта. Ну и все, feature freeze на ближайшие N лет. А разные Greta и PCRE продолжат развиваться и улучшаться.

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

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

WH>>

C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
WH>>Использовать его для основной разработки глупость.
A>Объясни, почему.
Лучше ты объясни какие преимущества дает С++/CLI из-за которых стоит отказаться от ReSharper'а?
Вот для немерле можно легко выкатить сиписок, а вот для C++/CLI

A>Есть проекты, где основной язык разработки — C++/CLI. Смотри Phonenix, например.
И чем они обосновывают этот выбор?

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

E>>А если бы был у тебя GC, а объекты бы всё равно разрушались?
WH>Такого в нормальных средах с ГЦ не бывает.
Ну библиотека-то сторонняя...

E>>Например по причине отгрузки DLL со всеми её статическими данными...
WH>ГЫ! Код и связанные с ним статические данные без разрешения ГЦ никуда не уберешь...
Как так не уберёшь? FreeLibrary позовёшь и очень даже уберёшь...

Конечно если ты сторонней библиотеке можешь навязать использование твоего GC то да. А если не можешь?

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

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

E>>Так это и обозначает, что надо всюду таскать с собой самый актуальный буст

J>ну да, без него не скомпилируется

J>уж такой С++, если заюзал библиотеку — придется ее таскать

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

E>>Тут, как и везде в инженерной деятельности, нужен разумный компромис

J>Либо правильно, либо разумный компромисс

Нет. В инженерной деятельности всегда и только компромисс. "Правильно" просто не бывает

Собственно в этом у нас и есть с тобой расхождение. Я понимаю, что ничегоне бывает забесплатно и всё всегда компромисс, а тебе кажется, что бывают абсолютные истины. Скажем такая: "буст лучше всех альтернатив"

E>>Ну это обычно портит экономическую эффективность. Ну либо на самом деле всё хорошо.
J>Экономическую эффективность программера, знаешь ли, довольно трудно подсчитать.
Ну одного конкретного программера да, может быть, а вот процесса разработки -- запросто. И если у людей без буста получилось экономически эффективно разработать чего-то, то таки не нужен им буст, однако

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

J>А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
Ты не знаешь продуктов, которые пережили более 5 версий?

MS Word
Adobe Photoshop
Mac OS
OmniPage
The Bat
gcc правда пока только 4 версии пережил, но есть таки надежда
1С
WinDVD Pro
Nero
Lingvo
Даже "Герои меча и магии" кажется уже 5 версий набрали (если с KingsBounty считать

)

Может ты просто в нормальных конторах не работал?

E>>Ну я вот буст переносить не пробовал.
J>А ты попробуй

Вдруг понравится

Ну если ты оплатишь...

J>С STL нельзя иметь проблемы, это странички из Стандарта.

Ну уж я не знаю что там можно, а что нельзя, но проблемы бывают

J>С какой именно реализацией у тебя были проблемы? STLPort пробовал? Еще какие-нть пробовал? Почему остановились именно на той, с которой проблемы?
Потому что STL обычно поменять нельзя

STLPort тоже фигурировал...

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

E>>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...
J>какого еще глобального goto? у тебя весь код в одной функции, что ли?
Обычно есть возможность прихранить состояние стека, и потом вернуться туда же, но на другую метку. Если его нет сразу (хотя обычно есть), нет проблем реализовать на асме...

E>>>>

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

J>Нужна поддержка со стороны языка, короче, без нее никуда, никакая библиотека не спасет, только молиться останется либо на каждый чих забирать мьютекс, что убьет производительность на корню.

Ну пока что на многопоточных платформах как-то обходятся

Я не спорю, что можно бы и добавить что-то в стандарт про многопоточность, но насущной необходимости не вижу

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

WH>Ы?
Ещё бывают зависимости между хедерами. Да и в хедерах много чего бывает...

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

WH>А в чем проблема? Ну разве что вопрошающий не воспринимает то что ему говорят... но это показатель к увольнению...

Обычно спрашивает начальник, и при этом они с подчинённым энтузиастом буста/STL/Дельфи или ещё чего не понимают друг друга. Началинк оперирует языком экономической эффективности разработки и поддержки, а подчинённый оперирует идеологическими соображениями. Ну типа того, что он лично думает, что при использовании буста он запрограммирует это в пять раз быстрее. Обычно ошибается, кстати.

WH>Статические объекты однозначно зло.
WH>Но это уже отдельный флейм.
Очень конструктивно. Я знаю вагон успешных программ, где есть статические объекты. Мало того, я знаю, что комитет по C++ всё ещё не объявил слово static устаревшим...
Так что это действительно флейм.

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

WH>И это совершенно иначе мне очень не нравится.
Ну а вот и не совсем так дела обстоят

E>>где шаблоны были не супер.
WH>Насколько не супер? Скажем относительно VC++6.
Сильно хуже.
E>>ИМХО "крутые" шаблоны тяжелее всего переносить в таком раскладе. Потому, что они весь код пронизывают и часто трудно понять что там должно произойти, если их оттуда отковырять.
WH>А что там особо крутого? Ну не считая boost::mpl
Да? Ну, например, параметры шаблона не передаются рекусивно.
Скажем так написать нельзя:

template<class T> myData { std::vector<T> data; };

Скажут, что T не определён

WH>Боюсь избавится от исключений куда сложнее чем от шаблонов...
От шаблонов в стиле STL избавится невозможно!!!

WH>Я вот знаю одну библиотеку написанную на С++ с шаблонами и исключениями при том имеющею Сшный интерфейс...
WH>Прекрасно живет в so'шках и dll'ках...
Да? А если ты хочешь чтобы она разделяла рантайм с основным приложением. Скажем из соображений общей кучи? Это что касается DLL
А что касается SO, то ты просто не пробовал взять эту SO и хост, собранный с другим STL. Попробуй -- узнаешь много нового

WH>Качественно это можно сделать только виртуальной машиной которая по совместительству еще и ОС.
Это ещё почему? Зачем для распараллеливаемого функционального языка ОС и VM?
WH>Но это совершенно отдельная история.
ИМХО это просто заблужления, а не история

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

AA>...ибо "мощный персонаж" может сконструировать другой shared_ptr и все становится совсем весело. Но сразу.

Всё так, только выделенное не обязательно. ИМХО ты персонажа всё-таки недооцениваешь

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

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

J>typedef спасет отца русской демократии

Прости, какой typedef?

А если в программе есть объекты разных типов? В том числе и массивы таких объектов?

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

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

Не спасет.

Во-первых, statefull-аллокаторы в STL нормально работать не будут.
Во-вторых, можно нарваться на засады с методом swap(), если аллокаторы будут иметь несовпадающий тип.
В-третьих, в STL аллокаторы не могут возвращать умные указатели (в Стандарте гвоздями прибиты простые указатели).

Я в итоге свою либу написал

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

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

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

E>Ну это значит "и поддерживать". Я уже не говорю о том, что если ты разрабатываешь библиотеку под линукс, то тебе надо ещё и с хостом одной версией буста пользоваться

не понял, сорри

E>>>Тут, как и везде в инженерной деятельности, нужен разумный компромис

J>>Либо правильно, либо разумный компромисс

E>Нет. В инженерной деятельности всегда и только компромисс. "Правильно" просто не бывает

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

E>>>Ну это обычно портит экономическую эффективность. Ну либо на самом деле всё хорошо.
J>>Экономическую эффективность программера, знаешь ли, довольно трудно подсчитать.
E>Ну одного конкретного программера да, может быть, а вот процесса разработки -- запросто. И если у людей без буста получилось экономически эффективно разработать чего-то, то таки не нужен им буст, однако

Да им вообще ничего не нужно. Напишут они все на голом С, на указателях на void, и если релиз прошел — все, экономически эффективно. А то, что потом поддержка превращается в кошмар — это уже неэффективность поддерживающей команды, а у изначальной все хорошо, релиз же прошел.

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

J>>А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
E>Ты не знаешь продуктов, которые пережили более 5 версий?

E>Может ты просто в нормальных конторах не работал?

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

E>Про то, что ты не видишь других альтернатив я поскипал, извнини, но я их просто использовал на практике

Нет уж, ты расскажи!

E>>>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...
J>>какого еще глобального goto? у тебя весь код в одной функции, что ли?
E>Обычно есть возможность прихранить состояние стека, и потом вернуться туда же, но на другую метку. Если его нет сразу (хотя обычно есть), нет проблем реализовать на асме...
О-о-о...

E>>>>>

E>Я тебе так скажу. Я думаю, что пстандартизация в этих вопросах не прибавит переносимости

Прибавит. Потому что в языке появятся механизмы защиты от излишней низкоуровневой активности.

E>Ну пока что на многопоточных платформах как-то обходятся

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

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

J>>Еще раз повторю — если у тебя на примете есть библиотека, достойная быть принятой в Стандарт — закинь ее в Буст, в чем проблема?

E>Я тут вот о чем подумал по дороге домой: ну вот станет boost::regex частью стандарта. Ну и все, feature freeze на ближайшие N лет. А разные Greta и PCRE продолжат развиваться и улучшаться.

Ну так и boost::regex продолжит развиваться и улучшаться, никуда не денется.

Ну а у std::regex все зафиксируется, на то он и стандарт. Издержки стандартизации, никуда ты от этого не денешься.
С тем же успехом можно было бы принять в стандарт Greta или PCRE, и тогда все эти твои слова были бы напрямую применимы и к ним.
Из чего следует, что ты вообще против понятия "стандартная библиотека"

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

Ну и реализации тоже открыты для развития, вон посмотри хотя бы, какой прогресс в плане реализации делает STLPort с тыщу лет назад фиксированным интерфейсом STL.

E>А на счет закидывать -- у меня на свои OpenSource проекты здоровья уже не хватает. А здесь столько гораздо более умных C++ников и бустоводов сидит и хоть бы кто, например, сделал для буста аналог RubyGems.
Ну так а bcp чем не устраивает? Или это совсем не то?
Кстати, вполне возможно, что кто-то и делает.

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

V>>...Если, к примеру, я поступлю к вам на работу — изучу кучу ваших велосипедов, а потом как они мне пригодятся?
E>Ну тебе всё равно много прийдётся изучит специфического для конторы и задачи. Как это тебе пригодиться? Всё-таки STL не так уж много сервисов предлагает. Ну несколько контейнеров. Ну ненужные обычно алгоритмы. Ну запомнишь ты какие у нас контейнеры и как там sort или merge звать. Ну что тут такого сложного?

Не в именах сложность, имена бог с ними. В любом случае контейнеры будут typedef-ица, ListSomeObj там ContainerSomeObj.. другое дело, что будете пользоваться разработанными концепциями. STL предлогает не только контейнеры, но хорошую поддержку этих контейнеров как в алгоритмах, так в адаптации собственных. А ты говориш sort, merge... Мне просто адцки любопытно было бы посмотреть весь ваш фреймворк, который заменяет собой хотябы тот же STL и часть буста (а не сугубо специфические библиотеки) в сравнении ними же. Вообщем.. ниже.

E>Да и вообще, если ты пришёл в контору учиться вещам, которые тебе потом пригодятся, а не решать поставленные перед тобой задачи, то, ИМХО, платить должен ты

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

V>>Может ваш программист-идеолог уволиться, придет другой и скажет "другой велосипед!".
E>Да нет никакого программиста-идеолога. Есть много продуманных решений и большой опыт преемственности и разработок...
Всегда есть

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

E>>>Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...
V>>А ты прям предлогаешь либо вообще без буста, либо ВЕСЬ буст со всеми причиндалами — выжать из него все что только можно. Хотя второй вариант принесет вам дополнительные выгоды. Сказать какие?

Прославитесь!
E>Ну брать библиотеки "по частям", особенно если они нифига не сегментированы на них, или писать свои -- работа, ИМХО, примерно олинаковая. Только во втором случае ты менешь зависишь от неконтролируемых факторов...

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

Вы случайно не велосипеды выпускаете?

... << RSDN@Home 1.2.0 alpha rev. 710>>

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

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

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

C>Не спасет.

C>Во-первых, statefull-аллокаторы в STL нормально работать не будут.
Почему же не будут? Просто состояние должно быть разделено между всеми аллокаторами этого типа.

C>Во-вторых, можно нарваться на засады с методом swap(), если аллокаторы будут иметь несовпадающий тип.
Это да
C>В-третьих, в STL аллокаторы не могут возвращать умные указатели (в Стандарте гвоздями прибиты простые указатели).
И это да

C>Я в итоге свою либу написал

Разумно

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

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

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

J>>typedef спасет отца русской демократии

E>Прости, какой typedef?

typedef std::vector< int, my_allocator<int> > MyIntVector;

E>А если в программе есть объекты разных типов? В том числе и массивы таких объектов?

тогда template typedef, которого в природе пока что нет

а есть пока только такое:

template<class T>
struct MyVector
{
  typedef std::vector< T, MyAllocator<T> > type;
};

Соответственно, везде придется писать MyVector<int>::type, ничего не поделаешь

Кривизна, конечно (кто там говорил, что сахар не нужен?), но зато можно в эту структуру всякие другие вещи засунуть, к ним ко всем будет обращение через MyVector<int>. Например, MyVector<int>::iterator.

jazzer wrote:
> C>Во-первых, statefull-аллокаторы в STL нормально работать не будут.
> Почему же не будут? Просто состояние должно быть разделено между всеми
> аллокаторами этого типа.
Это и есть statless — у каждого конкретного аллокатора нет своего состояния.

> C>Я в итоге свою либу написал
> Разумно
Кстати, еще в аллокаторах не хватает метода realloc

Posted via RSDN NNTP Server 2.1 beta

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

>> C>Я в итоге свою либу написал
>> Разумно
C>Кстати, еще в аллокаторах не хватает метода realloc

У МС есть еще возможность узнать будет ли при realloc перемещение и на сколько можжно расширить без перемещения
поэтому велосипеды рулят

template<class T>
  class Vector
{  public:
   int size;     T* p;
   protected: int cap; public:
   Vector(){size=cap=0;p=0;}
   T& operator[](int i)
   {  if(unsigned(size)<=unsigned(i))
      {  __asm int 03;
      }
      return p[i]; 
   }
   Vector& set_cap(int cp) 
   {  if(cp )
        p=(T*)realloc(p,cp*sizeof(T));
      else
        free(p),p=0;
      cap=cp;
      return *this; 
   }
   Vector& grow_cap(int cp) 
   { if(cap<cp)
       set_cap(cp);
      return *this; 
   }
   Vector& set_sz(int sz) 
   { if(cap<sz)
       grow_cap(sz);
     if(size<sz)
        memset(p+size,0,sizeof(T)*(sz-size));
     size=sz; 
     return *this; 
   }
   T& operator++()
   { set_sz(size+1);      
     return p[size-1]; 
   }
   void operator--()
   { set_sz(size-1);      
     return p[size-1]; 
   }
   ~Vector()
   {  if(p)
       free(p); 
      p=0;
   }
   T& last()
   {  if(size<=0)
      {  __asm int 03;
      }
      return p[size-1]; 
   }
   void remov(int a,int n=1)
   {  int ns=size-n;
      for(;a+n<size;a++)
        p[a]=p[a+n];
      size=ns;
   }
};

и пусть ктото мне обьяснит можно ли такой код переписать на СТЛ и будет ли он при этом работать для 64 бит?

Vector<int> a,b;

int size_dif=xz?-1:+1;
if(a.size-b.size>size_dif)
 ++a=99;

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

WH>>Я вот знаю одну библиотеку написанную на С++ с шаблонами и исключениями при том имеющею Сшный интерфейс...
WH>>Прекрасно живет в so'шках и dll'ках...
E>Да? А если ты хочешь чтобы она разделяла рантайм с основным приложением. Скажем из соображений общей кучи? Это что касается DLL

Тот же boost::shared_ptr хранит указатель на ту стену, о которую должен убиться. Да и ::new/::delete можно переопределять.

E>А что касается SO, то ты просто не пробовал взять эту SO и хост, собранный с другим STL. Попробуй -- узнаешь много нового :)

А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

Programador wrote:
> C>Кстати, еще в аллокаторах не хватает метода realloc
> У МС есть еще возможность узнать будет ли при realloc перемещение и на
> сколько можжно расширить без перемещения
> поэтому велосипеды рулят
Собственно так и сделал — в своих контейнерах я указываю возможность
использования try_realloc'а в политиках.

Кстати, вместо realloc'а нужно использовать _expand — так как в общем
случае нельзя перемещать объекты копированием.

> и пусть ктото мне обьяснит можно ли такой код переписать на СТЛ и будет
> ли он при этом работать для 64 бит?
Код точно некорректный в общем случае, memset нельзя использовать для
очистки объектов.

Posted via RSDN NNTP Server 2.1 beta

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

>> и пусть ктото мне обьяснит можно ли такой код переписать на СТЛ и будет
>> ли он при этом работать для 64 бит?
Я про

Vector<int> a,b;

int size_dif=xz?-1:+1;
if(a.size-b.size>size_dif)
 ++a=99

У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?

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

P>Я про

P>Vector<int> a,b;
P>int size_dif=xz?-1:+1;
P>if(a.size-b.size>size_dif)
P> ++a=99
P>

P>У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?
Нормально — никак. А что ты, собственно, ожидал?

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

P>У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?

size_t s1, s2;
size_t d1 = 0, d2 = 0;

(xtozna ? d1 : d2) = 1;

if(s1 + d1 > s2 + d2)
{
    . . .
}

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

RO>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

Хм. Необязательно уж голый C то. Экспорт чисто виртуальных интерфейсов (завернутых в безопасный smart ptr) очень даже безопасен. Самое главное держать под контролем владение ресурсами и НЕ БРОСАТЬ исключений через границы модуля.

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

AA>Хм. Необязательно уж голый C то. Экспорт чисто виртуальных интерфейсов (завернутых в безопасный smart ptr) очень даже безопасен. Самое главное держать под контролем владение ресурсами и НЕ БРОСАТЬ исключений через границы модуля.

Что-то то мне это до боли напоминает

А, понял — COM

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

P>>У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?

RO>

RO>size_t s1, s2;
RO>size_t d1 = 0, d2 = 0;

RO>(xtozna ? d1 : d2) = 1;

RO>if(s1 + d1 > s2 + d2)
RO>{
RO>    . . .
RO>}
RO>

что тут сказать...
Аксиоматические основы математики Вы знаете. Введем отрицательные числа как фактормножество на отношении ... и т.д. выходит беззнаковых достаточно

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

RO>>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

AA>>Хм. Необязательно уж голый C то. Экспорт чисто виртуальных интерфейсов (завернутых в безопасный smart ptr) очень даже безопасен. Самое главное держать под контролем владение ресурсами и НЕ БРОСАТЬ исключений через границы модуля.

L>Что-то то мне это до боли напоминает

А, понял — COM

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

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

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

>>> S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
>>> S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
>>> Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект.

S>>Можно. У weak_ptr есть конструктор, принимающий shared_ptr, shared_ptr можно получить из указателя.
P>Конечно можно, но только 1 раз

Если повторить этот процесс то создастся вторая копия счётчика ссылок

"Вы просто не умеете их готовить"

#include <string>
#include <boost/shared_ptr.hpp>
#include <boost/enable_shared_from_this.hpp>
#include <iostream>

using namespace std; using namespace boost;

struct A : enable_shared_from_this<A>
{
    int q;
    A() : q(2) {}
    void foo()
    {
        q = q * q;
        cout << "A::foo " << q << endl;
    }
    ~A()
    {
        cout << "A::~A " << q << endl;
    }
};

int main(int argc, char* argv[])
{
    A *p = new A;
    shared_ptr<A> s1(p);
    weak_ptr<A> w1;
    {
        shared_ptr<A> s2(p->shared_from_this());
        weak_ptr<A> w2(s2);
        w1 = w2;
    }
    {
        shared_ptr<A> s3(w1);
        s3->foo();
    }
    s1->foo();

    return 0;
}

>>> Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся

S>>Не нужны слабые указатели — пользуйся intrusive_ptr.
P>Просто так один тип, чтоб не думать.

Умно

. Если не думать, то о необходимости слабых ссылок удастся узнать только когда программа начнет течь — и потом придется долго разбираться, что куда зациклилось.

>>> Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

S>>Думаешь, виртуальные базовые классы бесплатные?
P>не бесплатные конечно, но иногда нужные. Можно и не виртуально наследовать если у обьекты только одного типа

А по-русски то же самое слабо написать?

L>>Что-то то мне это до боли напоминает

А, понял — COM

AA>Разумеется. vtbl — самый надежный гарант бинарной совместимости. Только функции в интерфейсах на всякий случай не стоит перегружать — ибо MSVC перегруженные функции кладет в обратном порядке в vtbl, а другие компиляторы — в прямом.

Ну, COM это не только vtbl — это ещё с 3 десятка правил организаций внешнего интерфейса... Кстати, имхо, не самых неудачных — поэтому если платформы ограничены Win32/WinCE — то выбор COM для разбиения программы на модули оправдывает себя в 99% случаев. А вот если код делается переносимым — вот тут уж начинаются пляски с бубном. Кстати, никто не пробовал с минимальными изменениями портировать код COM/ATL компонент под Linux/Unix и иже с ними?

E>Я посмотрел эту статью. Я так понял, что это надстройка над средствами ОС для работы со строками...
Не совсем так. Это и есть, собственно средства OS для работы со строками. Строки одинаковы и в OS, и в пользовательских программах.

E>Ну привинтили эффективные строчки на автоматических буферах и на буферах аллокированых как-то специально в ОС. Я так понял, что конструкция _LIT( KText, "XXX" ) как-то размещает статический объект непосредственно в ПЗУ устройства?
Не обязательно в ПЗУ

Это просто статическая аллокация строки. Разместить статические данные программы в ПЗУ — это уже насколько я понимаю отдельная песня, и делается (опять же — насколько я понимаю) каким-то постпроцессингом после сборки бинарников ядра ОС и системных программ. Для пользовательских программ строки всё равно в ПЗУ не лягут.

E>Собственно люди хотели все статические строки иметь один раз и сразу в ПЗУ. ИМХО вполне понятное желание для этой ОС...
Да чёрт с ними со статическими строчками

. Не в них главная проблема — хотя обьявлять отдельно каждый кусок строки тоже довольно неудобно. Главное же неудобство (по моему мнению) лежит в следующей области: 90% работы со строками расположено в тех местах программы, которые некритичны ни по скорости, ни по памяти. А тут получается что даже если мне нужно при старте программы (1 раз на весь запуск) сложить 2 строки вместе — мне нужно ломать голову над тем как это сделать. Я был бы не против такой системы если бы она прилагалась опционально к нормальным строчкам. То есть, грубо говоря (если взять за основу STL) — чтобы каждый std::string мог вернуть буфер в котором он лежит + были операции над статическими строками, типа того что c-smile описал тут: http://www.rsdn.ru/forum/message/2287365.1.aspx

А так — получается что либо мне нужно писать кучу кода каждый раз когда нужно слить 2 строки вместе — либо писАть свой велосипед.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

S>"Вы просто не умеете их готовить"

Спасибо за разъяснения я поначалу не знал про http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html и в RSDN обсуждалось enable_shared_from_this http://www.rsdn.ru/Forum/?mid=2300457

Попробую обобщить – имеются 2 типа указателей. Первый тип это совместное владение, второй снабжение указателя информацией об разрушении. Может быть так что объект содержится внутри другого объекта или контейнера, который сам заботится об удалении и тогда сильные не нужны. Для обоих типов есть 2 подхода – либо объект знает про указатели либо нет. Знание объекта об указателях более надежно, с другой стороны мы можем не иметь возможности менять тип объекта, если коды не наши. Да и классы могут быть какието общеупотребительные, в которых лишнее не желательно Например такие простые как CPoint или даже целое л-валуе.

boost::shared_ptr однозначно требует алокации счетчика. enable_shared_from_this просто регистрирует его. В частности

Requires: enable_shared_from_this<T> must be an accessible base class of T. *this must be a subobject of an instance t of type T . There must exist at least one shared_ptr instance p that owns t.

Думаю сделать shared_ptr с возможностями добавлять enable_intrusive_from_this и enable_weak_from_this былобы правильней. Узнать об разрушении объекта ведь можно ведь не только из деструктора владеющего указателя, но из деструктора самого объекта.

Есть еще такие варианты не включать enable_intrusive_from_this в пользовательский класс , а сделать обертку которая имеет оператор T& и распределять память прямо при создании smart_ptr , но это если тип копируем.

Чет много вариантов набралось, даже если link не считать…….

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

P>Попробую обобщить – имеются 2 типа указателей. Первый тип это совместное владение, второй снабжение указателя информацией об разрушении. Может быть так что объект содержится внутри другого объекта или контейнера, который сам заботится об удалении и тогда сильные не нужны. Для обоих типов есть 2 подхода – либо объект знает про указатели либо нет. Знание объекта об указателях более надежно, с другой стороны мы можем не иметь возможности менять тип объекта, если коды не наши. Да и классы могут быть какието общеупотребительные, в которых лишнее не желательно Например такие простые как CPoint или даже целое л-валуе.

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

P>boost::shared_ptr однозначно требует алокации счетчика. enable_shared_from_this просто регистрирует его. В частности

Requires: enable_shared_from_this<T> must be an accessible base class of T. *this must be a subobject of an instance t of type T . There must exist at least one shared_ptr instance p that owns t.

Думаю сделать shared_ptr с возможностями добавлять enable_intrusive_from_this и enable_weak_from_this былобы правильней. Узнать об разрушении объекта ведь можно ведь не только из деструктора владеющего указателя, но из деструктора самого объекта.

Это как? Ведь для того, чтобы weak_ptr был в принципе возможен, отдельно от объекта в памяти должен висеть какой-то объект, который будет регистрировать смерть объектов — то, что Erop в соседней ветке называл прокси или например shared_count от shared_ptr. Так что никакой возможности сэкономить new/delete или хотя бы несколько байт я тут не вижу.

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

S>С чужими классами никаких проблем нет — они не могут держать в себе ссылки на наши объекты. Если у них есть встроенный счетчик ссылок — применяем intrusive_ptr, если нет — shared_ptr. Оверхед, связанный с shared_ptr, во втором случае неизбежен, так как память под счетчик выделять-то где-то надо.

Оверхед всегда избежен

От чужих можно отнаследовать и внедрить счётчик. Либо выделять памяти sizeof(T) + sizeof(int), и класть перед объект счётчик (что в общем-то примерно то же самое только более хакерски

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

J>>А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
E>Ты не знаешь продуктов, которые пережили более 5 версий?

E>MS Word
E>Adobe Photoshop
E>Mac OS
E>OmniPage
E>The Bat
E>gcc правда пока только 4 версии пережил, но есть таки надежда
E>1С
E>WinDVD Pro
E>Nero
E>Lingvo
E>Даже "Герои меча и магии" кажется уже 5 версий набрали (если с KingsBounty считать

)

Я тоже знаю продукт, переживший 5 версий — 3dsMax

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

... << RSDN@Home 1.2.0 alpha rev. 726>>

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

E>Да? Ну, например, параметры шаблона не передаются рекусивно.
E>Скажем так написать нельзя:

template<class T> myData { std::vector<T> data; };

E>Скажут, что T не определён

Вот тебе в качестве контрпримера цитата из стандарта (23.2.3.1)

namespace std {
 template <class T, class Container = deque<T> >
 class queue {
  ...
  Container c;
  ...
 };
}

Найди десять отличий

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

P>boost::shared_ptr однозначно требует алокации счетчика. enable_shared_from_this просто регистрирует его. В частности

Requires: enable_shared_from_this<T> must be an accessible base class of T. *this must be a subobject of an instance t of type T . There must exist at least one shared_ptr instance p that owns t.

Думаю сделать shared_ptr с возможностями добавлять enable_intrusive_from_this и enable_weak_from_this былобы правильней. Узнать об разрушении объекта ведь можно ведь не только из деструктора владеющего указателя, но из деструктора самого объекта.

enable_shared_from_this — это просто базовый класс, хранящий внутри weak_ptr и инициализирующий его this-ом в своем конструкторе. Так что enable_weak_from_this уже есть

.

И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?

.
WH>

C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
Именно для этого он и используется — для того, чтобы вызывать сложные геометрические процедуры (С++) из приложения на C#.

> S>С чужими классами никаких проблем нет — они не могут держать в себе ссылки на наши объекты. Если у них есть встроенный счетчик ссылок — применяем intrusive_ptr, если нет — shared_ptr. Оверхед, связанный с shared_ptr, во втором случае неизбежен, так как память под счетчик выделять-то где-то надо.
>
> Оверхед всегда избежен

> От чужих можно отнаследовать и внедрить счётчик. Либо выделять памяти sizeof(T) + sizeof(int), и класть перед объект счётчик (что в общем-то примерно то же самое только более хакерски

).

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

Posted via RSDN NNTP Server 2.1 beta

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

WH>

C++/CLI хорошо подходит только для нетривиального интеропа с кодом на С/С++.
WH>Использовать его для основной разработки глупость.

Можно тут поподробнее

> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?

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

Posted via RSDN NNTP Server 2.1 beta

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

>> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?

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

Вариант первый.
Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

Вариант второй.
Разместить счётчик перед объектом в памяти.

>>> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?
>
> S>Предложите ваш механиз реализации weak_ptr для классов с внутренним счетчиком (но только чтоб без отдельно висящих в памяти флажков, проксей и т.п.). Если у вас это получится, все, кого волнует производительность, на него быстро-быстро переползут (и я в первых рядах).
>
> Вариант первый.
> Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

Не подходит. Придется выделять память для элементов списка.

> Вариант второй.
> Разместить счётчик перед объектом в памяти.

А какая разница — перед или где-то еще? Убивать то его все равно надо отдельно от убиения объекта. Хотя, если поизвращаться с placement new и ручным вызовом деструктора, то может чего-нибудь и получиться. Правда, будет неоптимально по памяти при наличии слабых ссылок. Можно попробовать...

Posted via RSDN NNTP Server 2.1 beta

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

>> Вариант первый.
>> Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

S>Не подходит. Придется выделять память для элементов списка.
Не обязательно. Можно соорудить что-то вроде linked_ptr.

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

>>>> И вообще не вижу никакого волшебства в enable_shared_from_this. Ведь чтобы его использовать, надо наследоваться. Почему счетчик внутренним не сделать в этом случае?
>>
>> S>Предложите ваш механиз реализации weak_ptr для классов с внутренним счетчиком (но только чтоб без отдельно висящих в памяти флажков, проксей и т.п.). Если у вас это получится, все, кого волнует производительность, на него быстро-быстро переползут (и я в первых рядах).
>>
>> Вариант первый.
>> Объединить все shared/weak ptr'ы в список, тогда можно будет нотифицировать weak ptr'ы об удалении/создании объекта.

S>Не подходит. Придется выделять память для элементов списка.

Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.

>> Вариант второй.
>> Разместить счётчик перед объектом в памяти.

S>А какая разница — перед или где-то еще? Убивать то его все равно надо отдельно от убиения объекта. Хотя, если поизвращаться с placement new и ручным вызовом деструктора, то может чего-нибудь и получиться. Правда, будет неоптимально по памяти при наличии слабых ссылок. Можно попробовать...

Тут идея, что weak ptr'ы будут жить ограниченное время после самого объекта, либо их ограниченное кол-во.

> S>Не подходит. Придется выделять память для элементов списка.
>
> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.

Кроме производительности. А формально — да, подходит.

> S>А какая разница — перед или где-то еще? Убивать то его все равно надо отдельно от убиения объекта. Хотя, если поизвращаться с placement new и ручным вызовом деструктора, то может чего-нибудь и получиться. Правда, будет неоптимально по памяти при наличии слабых ссылок. Можно попробовать...
>
> Тут идея, что weak ptr'ы будут жить ограниченное время после самого объекта, либо их ограниченное кол-во.

Ну да, для некоторых применений подойдет.

Posted via RSDN NNTP Server 2.1 beta

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

V>Не в именах сложность, имена бог с ними. В любом случае контейнеры будут typedef-ица, ListSomeObj там ContainerSomeObj.. другое дело, что будете пользоваться разработанными концепциями. STL предлогает не только контейнеры, но хорошую поддержку этих контейнеров как в алгоритмах, так в адаптации собственных. А ты говориш sort, merge... Мне просто адцки любопытно было бы посмотреть весь ваш фреймворк, который заменяет собой хотябы тот же STL и часть буста (а не сугубо специфические библиотеки) в сравнении ними же. Вообщем.. ниже.

У нас есть массивы, списки, деревья, мнодества и отображения. Их можно сортировать и осуществять над ними двухпутевое сляиение, кроме того в них можно искать бинарно или линейно. Существенным отличием массивов от STLных является то, что они могут хранить некопируемые, ноперемещаемые объекты.
Кроме того есть несколько типов массивов, которых нет в STL. Например, есть массив, который хранит данные {1, 2, 2, 2, 3, 3, 3, 1, 1 } так: { 1(1 раз), 2(3 раза), 3(3 раза), 1(2 раза) }, позволяя итерировать объекты как по одному, так и по группам.

Есть умные указатели (интрузивный со счётчиком и некопируемый эксклюзивный). Есть поддержка полиморфной сериализации и RTTI создания объектов. Очень сильно отличается работа с памятью. В управлении памятью используются совсем другие принципы, чем в STL, например.

V>А нафига? По твоим постам я понял, у тебя свободного времени просто тонна и ты не знаешь как по извратнее бы его потратить.
Не знаю я, что такое "поизвратнее". Одна из текущих задач, стоящих перед моей группой звучит так: "Разработать лучший в мире ХХХ, с беспрецедентно высоким качеством YYY". На это можно потратить всё свободное и несвободное время. И STL и boost тут не помогут, увы

V>Я во всем желаю видеть выгоду. У меня из личностных ценностей не только деньги.
ИМХО это внутреннипротевоечивый посыл

Но общий смысл моего возражения очень прост. Если изучение STL ценность для тебя, то ты просто не пойдёшь в нашу контору. Спроси на собеседовании используют ли в конторео STL или нет

Ну а если тебе реально интересно посмотреть на наш фреймворк, то надо просто пройти собеседование и попасть в отдел исследований и разработок

V>Всегда есть

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

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

V>А что ты считаешь контроллируемым фактором? Как раз таки стандартные средства более контролируемый фактор. Их используют все. Поэтому они меньше подвержены флуктуациям.

Контролируемым фактором я считаю планирование производимых работ и хорошее ими управление. А ты значит надеешься на флюктуации? Ну-ну

V>Вы случайно не велосипеды выпускаете?

Мы случайно учимся быть взаимовежливыми.
А у вас оборт по торговле ПО хотя бы $10 000 000 сулчайно превосходит?

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

>> S>Не подходит. Придется выделять память для элементов списка.
>>
>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.

S>Кроме производительности. А формально — да, подходит.

А какие проблемы с производительностью?

>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>
> S>Кроме производительности. А формально — да, подходит.
>
> А какие проблемы с производительностью?

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

Posted via RSDN NNTP Server 2.1 beta

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

J>Что там поддерживать?
J>Вот лежит себе буст, никого не парит.
J>Есть четкие указания, что из него можно использовать А, Б и В, остальное либо нельзя либо после предварительных консультаций.
J>В чем проблема-то?

Проблем всего три
1) Кто-то должен поддерживать актуальность требований на использование А, Б и В, и следить за их соблюдением
2) Буст сам по себе время от времени меняется. Надо как-то понимать нужно ли и можно ли включать эти изменения в твой билд. При этом решение лучше бы принимать на уровне всей конторы, как минимум, а то момтом случится конфликт версий
3) Иногда в фреймворке что-то хочется развить или баг пофиксить. В случае, если это буст, то от тебя приоритет этой работы не зависит, да и даже когда команда буста это сделает, результатами её работы ещё надо суметь воспользоваться, не сломав переходом на новую версию буста всё остальное

E>>Ну это значит "и поддерживать". Я уже не говорю о том, что если ты разрабатываешь библиотеку под линукс, то тебе надо ещё и с хостом одной версией буста пользоваться

J>не понял, сорри

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

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

J>Да им вообще ничего не нужно. Напишут они все на голом С, на указателях на void, и если релиз прошел — все, экономически эффективно. А то, что потом поддержка превращается в кошмар — это уже неэффективность поддерживающей команды, а у изначальной все хорошо, релиз же прошел.
Ну да, не только процесса разработки а всегопроцесса использования и разработки кода. Обычно конторы быват либо такие, которые пишут одноразовые решения, и там действительно пофиг на стоимость поддержки. Главное быстро и дёшево разработать (иначе просто не будет спроса на такую услугу, так как проще "девочку посадить")
А бывает так, что пишут долговременные решения. С версиями, с поддержкой, со всеми пирогами. И там вполне могут быть разные бизнес-модели. Типа ты можешь решить, что поддержка за время разработки след. версии должна быть не дороже 30% разработки. Ну и измеряй себе экономическую. эффективность процесса в целом, соответсвие его бизнес-моделям и т. д.

J>"в реальности бывает" не означает "везде", а означает "бывает". Я описанную ситуацию наблюдал многократно, и не только в фирмах, где я работал.
Да, так тоде бывает. АФАИК, обычно так бывает вне связи с использованием STL. Мало того, если корреляция есть, то я бы предположил, что она обратная. То есть проекты написанные с буст и STL скорее могут оказаться "бесхозными"

J>Нет уж, ты расскажи!
Ну я уже рассказывал схему такого сервиса. Когда ты регишь всё критичное объекте запроса, а промежуточные аллокации все делаешь на убиваемомо аллокаторе. И в случае ошибки освобождаешь всё критичное, а всё некритичное просто грохаешь всем аллокатором. Ну и вместо исключений используешь глобальный goto или вообще перезапуск приложения (на платформах без исключений это может бытьочень дешёвой процедурой)

E>>Обычно есть возможность прихранить состояние стека, и потом вернуться туда же, но на другую метку. Если его нет сразу (хотя обычно есть), нет проблем реализовать на асме...
J>О-о-о...

Дёшево и сердито. Но такое средство обычно есть там, где нет исключений, кстати

E>>>>>>

E>>Ну пока что на многопоточных платформах как-то обходятся

J>Ну да, помолясь, без каких-либо гарантий, что на следующей версии компилятора, ядра ОС и т.п. все продолжит работать

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

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

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

M>Я тоже знаю продукт, переживший 5 версий — 3dsMax

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

Ну это же достижения чисто административные, а вовсе и не технологические. Скорее всего использование/не использование STL на этобы никак не повлияло

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

E>>Да? Ну, например, параметры шаблона не передаются рекусивно.
J>Вот тебе в качестве контрпримера цитата из стандарта (23.2.3.1)
Ну да "стнадарт от такого-то года поддержен не полностью"... И живи как хочешь.

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

>>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>>
>> S>Кроме производительности. А формально — да, подходит.
>>
>> А какие проблемы с производительностью?

S>Дак вполне очевидные — при удалении умных указателей придется шариться по спискам объектов, на которые ссылаешься, вычищать оттуда себя. Потом бежать по спискам подписчиков, уведомлять их о своей кончине.

По спискам шариться не надо — next и prev у элемента имеются.
По спискам подписчиков тут бегать не надо вообще.
Если ты сделаешь замеры, то увидишь, что такой указатель будет работать быстрее обычного.

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

RO>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

Это помогает под виндой.
Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста. И ничуть не запарится. Так что какой там интерфейс -- не суть. Тем более, что любой интерфейс можно завернуть в автогенерённый переходник. Проблема в доступности symbols друг друга.

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

J>Кривизна, конечно (кто там говорил, что сахар не нужен?), но зато можно в эту структуру всякие другие вещи засунуть, к ним ко всем будет обращение через MyVector<int>. Например, MyVector<int>::iterator.

Ну вот мы STL и не используем...

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

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

E>>>Да? Ну, например, параметры шаблона не передаются рекусивно.
J>>Вот тебе в качестве контрпримера цитата из стандарта (23.2.3.1)
E>Ну да "стнадарт от такого-то года поддержен не полностью"... И живи как хочешь.

А, это было про мерзкую платформу без поддержки даже базовых вещей... Тады ой

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

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

J>>Кривизна, конечно (кто там говорил, что сахар не нужен?), но зато можно в эту структуру всякие другие вещи засунуть, к ним ко всем будет обращение через MyVector<int>. Например, MyVector<int>::iterator.

E>Ну вот мы STL и не используем...

А причем тут STL? Это — кривизна С++ в плане отсутствия template typedef, эта беда с абсолютно любыми шаблонами.
Разве что у вас библиотека нешаблонная совсем (на макросах?), тогда да.

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

J>А причем тут STL? Это — кривизна С++ в плане отсутствия template typedef, эта беда с абсолютно любыми шаблонами.
J>Разве что у вас библиотека нешаблонная совсем (на макросах?), тогда да.

Ну контейнеры у нас шаблонные, но для обсуждаемой функциональности template typedef не требуется

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

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

J>>А причем тут STL? Это — кривизна С++ в плане отсутствия template typedef, эта беда с абсолютно любыми шаблонами.
J>>Разве что у вас библиотека нешаблонная совсем (на макросах?), тогда да.

E>Ну контейнеры у нас шаблонные, но для обсуждаемой функциональности template typedef не требуется

ну или требуемая функциональность вцементирована, тогда тоже да

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

Я пересмотрел свою позицию, действительно, ваши задачи могут быть более требовательны к средствам чем те, которые предоставляет STL+Boost. Все таки правило частное решение лучше общего никто не отменял. Ваше частное решение явно заточено под ваши задачи и связанную с ними проблематику, конечно при условии что ваш фреймворк предоставляет как минимум не худший сервис, чем тот же STL. Я думаю что программисты у вас деляться на те, кто разрабатывает и поддерживает фреймворк, и те кто его используют (прикладные): просто было бы нехорошо чтобы те же приладники время от времени полгядывали в сторону "запрещенного" STL+Boost пуская слюни

конечно из тех, кто раньше его учили и использовали.

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

И все же избранный вами подход доказывает только одно правило: без STL можно хорошо жить. Но никак не опровергает обратного!

Я бы по такому пути не пошел. И никому бы не советовал. А вы не доказали обратного — не жили на STL+Boost как минимум. Так что ваши советы слишком однобоко обоснованы, слишком похоже на какое-то исключения из правил в рамках обстоятельств финансирования, политики и проч..

А так я полностью согласен с вашим правилом

я тоже когда-то жил неплоха без STL и проч. писал велосипеды.. Кто через это не проходил?

V>>А нафига? По твоим постам я понял, у тебя свободного времени просто тонна и ты не знаешь как по извратнее бы его потратить.
E>Не знаю я, что такое "поизвратнее". Одна из текущих задач, стоящих перед моей группой звучит так: "Разработать лучший в мире ХХХ, с беспрецедентно высоким качеством YYY". На это можно потратить всё свободное и несвободное время. И STL и boost тут не помогут, увы

Почему не помогут? Неплохие концепцие, которые показали себя и зарекомендовали. ПОчему их категорически нельзя использовать?

V>>Я во всем желаю видеть выгоду. У меня из личностных ценностей не только деньги.
E>ИМХО это внутреннипротевоечивый посыл

Ну если деньги будут платить очень неплохие деньги, то пойду

Фиг с ним с STL

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

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

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

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

E>Контролируемым фактором я считаю планирование производимых работ и хорошее ими управление. А ты значит надеешься на флюктуации? Ну-ну

V>>Вы случайно не велосипеды выпускаете?

E>Мы случайно учимся быть взаимовежливыми.
Прошу прощения

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

E>А у вас оборт по торговле ПО хотя бы $10 000 000 сулчайно превосходит?

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

... << RSDN@Home 1.2.0 alpha rev. 710>>

>>>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>>>
>>> S>Кроме производительности. А формально — да, подходит.
>>>
>>> А какие проблемы с производительностью?
>
> S>Дак вполне очевидные — при удалении умных указателей придется шариться по спискам объектов, на которые ссылаешься, вычищать оттуда себя. Потом бежать по спискам подписчиков, уведомлять их о своей кончине.
>
> По спискам шариться не надо — next и prev у элемента имеются.
> По спискам подписчиков тут бегать не надо вообще.
> Если ты сделаешь замеры, то увидишь, что такой указатель будет работать быстрее обычного.

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

Posted via RSDN NNTP Server 2.1 beta

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

V>Я думаю что программисты у вас деляться на те, кто разрабатывает и поддерживает фреймворк, и те кто его используют (прикладные): просто было бы нехорошо чтобы те же приладники время от времени полгядывали в сторону "запрещенного" STL+Boost пуская слюни

конечно из тех, кто раньше его учили и использовали.

Конечно есть программисты, которые поддерживают фреймворк. Но это не значит, что остальные не знают про STL и boost

V>Еще интересно знать, отказались ли вы от совершенно стандартных средств, таких как strXXX, memXXX, malloc и проч. Т.е. при вашем подходе было бы уместно ожидать, что стандартных библиотек вообще не используется.
Ну мы постепенно отказываемся от всяких стандартных библиотек...

V>И все же избранный вами подход доказывает только одно правило: без STL можно хорошо жить. Но никак не опровергает обратного!
Конечно. Только то, что STL нифига не ключевая технология успеха

Кроме того в STL есть свои проблемы и свои косяки. Можно обсудить разные конкретные обстоятельства, но где-то тут уже был такой флейм. Лично мне в STL контейнерах не больше всего ненравятся три обстоятельства
1) Элементы должны иметь семантику значения
2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.

V>Я бы по такому пути не пошел. И никому бы не советовал. А вы не доказали обратного — не жили на STL+Boost как минимум. Так что ваши советы слишком однобоко обоснованы, слишком похоже на какое-то исключения из правил в рамках обстоятельств финансирования, политики и проч..

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

КРоме того мы отказались не только от STL, но и от MFC, от PowerPlant, и много от чего ещё

Кроме того у нас есть большой опыт роаботы с партнёрами и аутсорсерами. И там тоже всё однозначно. STL как-то неудачно спроектирвоан в смысле управления командой разработчиков, ИМХО

V>Почему не помогут? Неплохие концепции, которые показали себя и зарекомендовали. Почему их категорически нельзя использовать?
Да не "нальзя", а "надо объяснить зачем". При таком подходе внезапно выясняется, что реальных аргументов при выборе "фирменный фреймворк" vs "STL" нет, за редким довольно исключением

V>Ну если деньги будут платить очень неплохие деньги, то пойду

Фиг с ним с STL

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

Ну "очень хорошие деньги" будут работать против экономической эффективности отказа от STL. Но реально среди программистов нет спроса на "использование STL в конторе".

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

ИМХО в дешевизне поддержки и развития больше всех заинтересованы производители коробочного ПО, продаваемого большими тиражами

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

E>>Ну контейнеры у нас шаблонные, но для обсуждаемой функциональности template typedef не требуется

J>ну или требуемая функциональность вцементирована, тогда тоже да

Ну слово "вцементированна" -- это всего лишь эмоуиональная оценка. Мне больше нравится слово "поддержана"

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

WH>>Такого в нормальных средах с ГЦ не бывает.
E>Ну библиотека-то сторонняя...
И?

WH>>ГЫ! Код и связанные с ним статические данные без разрешения ГЦ никуда не уберешь...
E>Как так не уберёшь? FreeLibrary позовёшь и очень даже уберёшь...

E>Конечно если ты сторонней библиотеке можешь навязать использование твоего GC то да. А если не можешь?

Ты показал полное не знание того как работают всякие жабы и дот неты.

Там один ГЦ и один рантайм на всех навязывается просто автоматически. И ничего с этим сделать нельзя.
Благодоря этому не возникает никаких проблем с тем где объект создан.
Нет проблем с полетами исключений между модулями.
...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>>Ы?
E>Ещё бывают зависимости между хедерами. Да и в хедерах много чего бывает...
А в чем проблема то?
Точно также можно отгрепать сторонние либы.

WH>>А в чем проблема? Ну разве что вопрошающий не воспринимает то что ему говорят... но это показатель к увольнению...
E>Обычно спрашивает начальник, и при этом они с подчинённым энтузиастом буста/STL/Дельфи или ещё чего не понимают друг друга. Началинк оперирует языком экономической эффективности разработки и поддержки, а подчинённый оперирует идеологическими соображениями. Ну типа того, что он лично думает, что при использовании буста он запрограммирует это в пять раз быстрее.
Это легко проверяется.

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

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

А если он это обоснует?

WH>>И это совершенно иначе мне очень не нравится.
E>Ну а вот и не совсем так дела обстоят

Вот только я ни разу не видил код который живет и с исключениями и без.

WH>>Боюсь избавится от исключений куда сложнее чем от шаблонов...
E>От шаблонов в стиле STL избавится невозможно!!!
ИМХО гораздо легче чем от исключений.

WH>>Прекрасно живет в so'шках и dll'ках...
E>Да? А если ты хочешь чтобы она разделяла рантайм с основным приложением. Скажем из соображений общей кучи? Это что касается DLL
В данном случае это нафиг не нужно.
Но если очень хочется эту либу можно собрать как угодно. Хоть статически прилиньковать.

E>А что касается SO, то ты просто не пробовал взять эту SO и хост, собранный с другим STL. Попробуй -- узнаешь много нового

Это сильно зависит от того как so'шку собирать.
Я однажды собрал so'шку которая работала под кучей линухов без перекомпиляции... а там не только разные STL'и...

E>Это ещё почему? Зачем для распараллеливаемого функционального языка ОС и VM?
Нужен сильно другой планировщик и менеджер памяти.
Причем все это должно быть сильно интегрировано иначе прощай производительность и надежность.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>Там один ГЦ и один рантайм на всех навязывается просто автоматически. И ничего с этим сделать нельзя.
WH>Благодоря этому не возникает никаких проблем с тем где объект создан.
WH>Нет проблем с полетами исключений между модулями.
WH>...

А если библиотека не дотнетовская?

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

E>>Ещё бывают зависимости между хедерами. Да и в хедерах много чего бывает...
WH>А в чем проблема то?
WH>Точно также можно отгрепать сторонние либы.
Ну пролема в том, что всё это надо делать, тестировать то, что это всё ещё работает, в том числе и с новыми версиями либ и т. д.
ИМХО свои контейнеры дешевле в поддержке...

E>>...Началинк оперирует языком экономической эффективности разработки и поддержки, а подчинённый оперирует идеологическими соображениями. Ну типа того, что он лично думает, что при использовании буста он запрограммирует это в пять раз быстрее.
WH>Это легко проверяется.
Ну вот я и делюсь опытом таких проверок.

У на сон однозначный...

E>>Обычно ошибается, кстати.
WH>Но-но. Подобные приемчики оставь для нюбов. На меня они не действуют.
А кто такие "нюбы" и какие приёмчики?
Я просто делюсь своим опытом...

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

WH>А если он это обоснует?
Ну такое радикальное утверждение он вряд ли обоснует. Но вообще я обычно выслушиваю доводы инженеров. Я вообще предпочитаю уюеждать подчинённых, а не заставлять их...

WH>Вот только я ни разу не видил код который живет и с исключениями и без.
Нет, задача намного проще. Написать такой код с исключениями, который за приемлемые деньги можно перенести примелемо неплохо на платформу без них.
Но это всё непринципиально, вообще-то. Исключения тут не главное. Главное -- свойства кода.

WH>ИМХО гораздо легче чем от исключений.
Э-э-э? Как? Переписать весь код?
Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?

WH>Но если очень хочется эту либу можно собрать как угодно. Хоть статически прилиньковать.
Ну если ты можешь предоставить клиенту возможность самому переносить твоё изделиен на его платыорму/рантайм/средство разработки, то всё ещё проще будет у тебя...

WH>Я однажды собрал so'шку которая работала под кучей линухов без перекомпиляции... а там не только разные STL'и...
Это тонкий вопрос поро разные STLи... Вообще-то с gcc обычно стандартный комплект идёт...
Сколько версий gcc шло с этой "кучей Linux'ов"?
Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...

E>>Это ещё почему? Зачем для распараллеливаемого функционального языка ОС и VM?
WH>Нужен сильно другой планировщик и менеджер памяти.
WH>Причем все это должно быть сильно интегрировано иначе прощай производительность и надежность.

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

E>>Это ещё почему? Зачем для распараллеливаемого функционального языка ОС и VM?
WH>Нужен сильно другой планировщик и менеджер памяти.
WH>Причем все это должно быть сильно интегрировано иначе прощай производительность и надежность.

Это ещё от чего?
Есть какие-то принципиальные ограничения или ты не знаешь как это сделать?

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

>>>>>> Память под элементы находится в самих shared/weak ptr. В деструкторе они себя удаляют из этого списка. Никаких проблем не вижу.
>>>>
>>>> S>Кроме производительности. А формально — да, подходит.
>>>>
>>>> А какие проблемы с производительностью?
>>
>> S>Дак вполне очевидные — при удалении умных указателей придется шариться по спискам объектов, на которые ссылаешься, вычищать оттуда себя. Потом бежать по спискам подписчиков, уведомлять их о своей кончине.
>>
>> По спискам шариться не надо — next и prev у элемента имеются.
>> По спискам подписчиков тут бегать не надо вообще.
>> Если ты сделаешь замеры, то увидишь, что такой указатель будет работать быстрее обычного.

S>Тогда я видимо не вполне понимаю о чем речь. Как я понимаю, при удалении объект должен обойти весь список умных указателей своего типа и обнулить/как то еще пометить как невалидные все указатели, ссылающиеся на его объект. Или речь идет о чем-то другом?

При удалении *объекта*, но не при удалении *указателя*, как ты написал.
И при удалении объекта надо обходить не весь список умных указателей своего типа, а весь список умных указателей, которые ссылались на этот объект.

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

E>А если библиотека не дотнетовская?
Тогда интероп. Но это отдельные пляски с бубном.
Главное то что если библиотека .НЕТовская то никаких проблем нет.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

E>Ну пролема в том, что всё это надо делать, тестировать то, что это всё ещё работает, в том числе и с новыми версиями либ и т. д.
E>ИМХО свои контейнеры дешевле в поддержке...
Автоматические тесты не пишем принципиально?

E>Ну вот я и делюсь опытом таких проверок.

У на сон однозначный...
У меня тоже... и похоже прямо противоположный твоему...

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

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

E>Э-э-э? Как? Переписать весь код?
E>Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?
И что? Если это не понимает компилятор С++ то это уже скорее компилятор С. И тогда тебе нужно писать на С.

E>Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...
Угу... мне это конечно же приснилось...

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

E>Это помогает под виндой.
E>Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста. И ничуть не запарится. Так что какой там интерфейс -- не суть. Тем более, что любой интерфейс можно завернуть в автогенерённый переходник. Проблема в доступности symbols друг друга.

so/dll не должны зависеть от языка. Представляю, как ты вызовешь из Perl функцию с замангленным именем, которая бросает исключения.

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

WH>Главное то что если библиотека .НЕТовская то никаких проблем нет.
Ха, ну и библиотека на C++ могла бы предоставить возможность удобно совместно владеть своими объектами

Конечно если что-то уже реализовано, то проблем не будет

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

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

E>>Ну вот я и делюсь опытом таких проверок.

У нас он однозначный...
WH>У меня тоже... и похоже прямо противоположный твоему...
ВОзможно секрет в альтернативе STL. Если не STL, то что? Голые сишные вектора или какая-то вменяемая библиотека контейнеров?

WH>У меня получается. Но тут нужно говорить предметно, а не вобщем.
WH>И результат избавления от всяких там статиков и синглетонов всегда оказывался положительным.
Хорошо. Вот, например, что ты думаешь о статическом на поток (или просто статическом, в случае однопоточного окружения) логе?
Или, например, о статических таблицах данных. Скажем таблице, в которой написано какие ключи есть в каких иероглифах...

E>>Но это всё непринципиально, вообще-то. Исключения тут не главное. Главное -- свойства кода.
WH>Какие такие свойства?
Некритическая зависимость от исключений и шаблонов и т. д.
Вот смотри. Если у тебя прога написана так,ч что в случае какой-то лёгкой платформы без исключений, ты можешь из любого места сохраниться, выдать предупреждение и перезапустить прогу, а на нормальной платформе возбудить исключение и обработать его на уровне запроса, то у тебя практически весь код будет разделяться этими версиями и обе будут хорошо работать.
А если у тебя весь код пропитан throw и catch, то даже без легковесной платформы понятно, что он очень зависим от исключений...

E>>Э-э-э? Как? Переписать весь код?
E>>Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?
WH>И что? Если это не понимает компилятор С++ то это уже скорее компилятор С. И тогда тебе нужно писать на С.

E>>Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...
WH>Угу... мне это конечно же приснилось...

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

E>>Вот написал ты всё в стиле

template<typename TIterator> void my_foo( TIterator start, TIterator end )

и что делаем дальше?
WH>И что? Если это не понимает компилятор С++ то это уже скорее компилятор С. И тогда тебе нужно писать на С.

Ну считай, что это не C++, хотя там есть строгая типизация, перегрузка, какие-то шаблоны (пусть с багами и "особенностями"), операторы, и, возаможно, даже исключения.
Делать-то что?
С другой стороны я утверждаю, что даже если нет нужды переносить прогу на платформу с плохими шаблонами, то код, котрый "зависит от шаблонов некритически" обычно лучше, понятнее, проще, легче в поддержке и развитии...

E>>Да и потом это всё не важно. Просто почитай доки про загрузчик или напиши сэмпл...
WH>Угу... мне это конечно же приснилось...

Ну ты собственно чтооспариваешь?
Что в OS Linux загрузчик процесса видит все символы в SO'шке и в процессе и может их линковать друг к другу как попало? Ну проверь этот факт. Это так, увы авторам линуха

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

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

RO>so/dll не должны зависеть от языка. Представляю, как ты вызовешь из Perl функцию с замангленным именем, которая бросает исключения.

Конечно если ты зовёшь so из PERL, то с-интерфейс удобнее, чем c++
И дело даже не в мангленгом, а в том, что тебе прийдётся ловить исключения или создавать/разрушать объекты. Но эта проблема легко лечится, как раз. Вторая проблема намного рудне искоренима.

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

E>Ха, ну и библиотека на C++ могла бы предоставить возможность удобно совместно владеть своими объектами

E>Конечно если что-то уже реализовано, то проблем не будет

Оно реализовано на качественно ином уровне чем можно сделать на С++.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

Прелесть boost'а и stl в том что они уже протестированны.

E>Хорошо. Вот, например, что ты думаешь о статическом на поток (или просто статическом, в случае однопоточного окружения) логе?
Однозначно в морг.

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

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

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

E>А если у тебя весь код пропитан throw и catch, то даже без легковесной платформы понятно, что он очень зависим от исключений...
А в чем проблема если это код никогда не будет запускатся на этих твоих "легковесных платформах".

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

E>>Ха, ну и библиотека на C++ могла бы предоставить возможность удобно совместно владеть своими объектами

WH>

E>>Конечно если что-то уже реализовано, то проблем не будет

WH>Оно реализовано на качественно ином уровне чем можно сделать на С++.

Насколько я помню, люди приводили конекретную проблемную ситуацию. С вполне конкретными библиотеками. Конечно если бы всё было совсем другим, то и жить можно бы было по-другому

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

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

WH>Прелесть boost'а и stl в том что они уже протестированны.
А процедура контроля границ использования boost и корректности его текущей развёртки?

E>>Хорошо. Вот, например, что ты думаешь о статическом на поток (или просто статическом, в случае однопоточного окружения) логе?
WH>Однозначно в морг.

Очень аргументированно.
Ответ -- не убелил

E>>Или, например, о статических таблицах данных. Скажем таблице, в которой написано какие ключи есть в каких иероглифах...
WH>Против констант заданных на этапе компиляции я ничего не имею.
А если на этапе компиляции эти данные вычислить затруднительно?

E>>Некритическая зависимость от исключений и шаблонов и т. д.
WH>Все както слишком расплывчато.
Ну я уж как мог объяснял что такое "критическая зависимость" и что такое "некритическая". Ты уж прости, но понятнее я пояснить не смогу.
В конце концов "специалиста учить -- только портить". Если тебе понятие "критическая зависимость кода от шаблонов" не доступно, ну значит не доступно. Я не знаю как ещё объяснить. Попробуй задать вопросы, что ли

WH>Рестартовать процесс на каждый чих?!
На некоторых платформах это довольно дёшево. Но поинт состоит ка краз в том, что на каждый чих не надо использовать исключения...

E>>А если у тебя весь код пропитан throw и catch, то даже без легковесной платформы понятно, что он очень зависим от исключений...
WH>А в чем проблема если это код никогда не будет запускатся на этих твоих "легковесных платформах".
Э-э-э? А зачем его тогда туда переносить? (Я уж не говорю о том, что делать, если компиллер не знает таких слов...)

> При удалении *объекта*, но не при удалении *указателя*, как ты написал.

Ну при удалении умного указателя тоже ведь понадобится сказать объекту, что на него этот конкретный умного указатель больше не указывает? Иначе потом при удалении объекта будет обращение по неправильному указателю.

> И при удалении объекта надо обходить не весь список умных указателей своего типа, а весь список умных указателей, которые ссылались на этот объект.

Да, действительно. Но тогда у нас и присваивание указателей затратным станет —

smart_ptr<A> a(new A);
smart_ptr<A> b = a;
smart_ptr<A> c(new A);
a = c;

В последнем присваивании придется тоже обходить список первого объекта.

Posted via RSDN NNTP Server 2.1 beta

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

>> При удалении *объекта*, но не при удалении *указателя*, как ты написал.

S>Ну при удалении умного указателя тоже ведь понадобится сказать объекту, что на него этот конкретный умного указатель больше не указывает? Иначе потом при удалении объекта будет обращение по неправильному указателю.

Объект ничего не хранит. Ему ничего говорить не надо.
При удалении умного указателя надо его удалить из списка сказателей, указывающих на этот же объект. Это O(1).

>> И при удалении объекта надо обходить не весь список умных указателей своего типа, а весь список умных указателей, которые ссылались на этот объект.

S>Да, действительно. Но тогда у нас и присваивание указателей затратным станет —
S>

S>smart_ptr<A> a(new A);
S>smart_ptr<A> b = a;
S>smart_ptr<A> c(new A);
S>a = c;
S>

S>В последнем присваивании придется тоже обходить список первого объекта.

Ничего обходить не надо.
Тут объект а удаляет себя из списка указателей, указывающих на первый объект, и добавляет себя в список указателей, указывающих на второй объект. Это очень быстро и O(1).

Дабы снять непонимание. Никто не хранит как таковой список всех указателей, указывающих на конкретный объект. Все указатели сами организованы в распределённый список. Каждый имеет next и prev на соседние указатели, указывающие на тот же объект. При удалении указателя, он просто удаляет себя из этого списка.

E>Конечно. Только то, что STL нифига не ключевая технология успеха

E>Кроме того в STL есть свои проблемы и свои косяки. Можно обсудить разные конкретные обстоятельства, но где-то тут уже был такой флейм. Лично мне в STL контейнерах не больше всего ненравятся три обстоятельства
E>1) Элементы должны иметь семантику значения
E>2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
E>3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.

А можешь пояснить пункты 2 и 3 чуть подробнее? Пункт 2 — это про отсутствие realloc, насколько я понял? А пункт 3 — не понял совсем, как-то не натыкался на такую проблему.

E>КРоме того мы отказались не только от STL, но и от MFC, от PowerPlant, и много от чего ещё

Дык извините — это специфика

Огромный проект (вариант — серия проектов), большие ресурсы и серьёзные требования к производительности/памяти — вот и весь рецепт. Тут я даже не представляю стандартную библиотеку, которая впилась бы и от которой не было бы попыток отказаться

. STL (boost) — это попытка баллансирования, попытка решить 90% задач по крайней мере не хуже, чем решают их 90% альтернативных библиотек. Если вы в эти 90% не попадаете — ну что ж, STL/boost действительно не для вас.

Тут недавно статейка проскакивала про ESTL — "свой" STL от Electronic Arts, заточеный и расширеный под написание игрушек для разных платформ. У тебя, похоже, тот же случай — только STL не лёг в основу фирменной библиотеки. Единственно, делать вывод о ненужности STL потому что он не нужен конкретно твоей организации — я всё же не стал бы

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

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

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

E>Это помогает под виндой.
E>Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста. И ничуть не запарится. Так что какой там интерфейс -- не суть. Тем более, что любой интерфейс можно завернуть в автогенерённый переходник. Проблема в доступности symbols друг друга.

Мы такие проблемы решали прятанием символов с помощью version script. Например, приходится делать что-то типа такого:

{
local:
    extern "C++"
    {
        std::*;
    boost::*;
    };
};

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

E>>Конечно. Только то, что STL нифига не ключевая технология успеха

E>>2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
L>Пункт 2 — это про отсутствие realloc, насколько я понял?
Не только. Например на STL неудобно размещать короткие вектора прямо на стеке, скажем...

E>>3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.
L>А пункт 3 — не понял совсем, как-то не натыкался на такую проблему.
Ну как же. Вот надо тебе написать какой-нибудь алгоритм в STL-стиле. Пишеш не функцию, а шаблон. Обычно параметризованный итератором. Всё конечно хорошо, но реальная жизнь показывает, что эту функцию/функтор никто как шаблон никогда не проектирует. Соответсвенно рожабт всяких уродов.

L>Если вы в эти 90% не попадаете — ну что ж, STL/boost действительно не для вас.
Ну я про то же. Что для совсем маленькой разработки STL пиремлем, если нет другой, более подходящей либы. Тем более, что он переносим, хотя бы в смысле стандарта STL
А вот если проект большой или много, дешевле иметь специализированную конструёвину

L>Единственно, делать вывод о ненужности STL потому что он не нужен конкретно твоей организации — я всё же не стал бы

Да нет. Я о ненужности STL вывод делаю. А совсем другой.
1) И без STL жизнь может быть хорошей. Внедрять STL из идеологических соображений, ИМХО, неправильно. Нужнопонимать акую выгоду это принесёт. Тем более, что в случае хорошей жизни может принести и убыток.
2) Выбирная STL надо понимать что за проблемы и особенности производства разработки он за собой "притянет".

Короче всё как всегда. Выбирая инструмент, нужно понимать почему тебе нужен именно такой инструмент, а не какой-то другой

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

AA>Мы такие проблемы решали прятанием символов с помощью version script. Например, приходится делать что-то типа такого:

Это помогает только если у тебя не коллекция SO-шек, с С++ интерфейсом между собой и каким-то интерфейсом наружу.

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

E>1) Кто-то должен поддерживать актуальность требований на использование А, Б и В, и следить за их соблюдением
это необходимо в случае любой библиотеки, в том числе самописной.

E>2) Буст сам по себе время от времени меняется. Надо как-то понимать нужно ли и можно ли включать эти изменения в твой билд. При этом решение лучше бы принимать на уровне всей конторы, как минимум, а то момтом случится конфликт версий
Буст меняется раз в два года (1.33.1 был в 2005 году). Раз в два года можно и обновиться всей конторой, это ж не каждую неделю..
Ну и "как-то понимать", естественно, необходимо. Тестировать тщательно и все такое прочее. Вот скажем, вышел 1.34.1 — ты думаешь, мы уже радостно на него перешли? Нет еще, хоть и собираемся, когда будет достаточно времени, чтобы протестировать его (это месяца через два, наверное, не раньше). Взяли из него только некритичные вещи с сильными изменениями, типа буст.тест — они все равно используются только в тестовых прогах. А у вас в конторе не так? Новая версия самописной или третьей библиотеки (не буста, свят,свят,свят!) просто инсталлируется и используется как есть?

E>3) Иногда в фреймворке что-то хочется развить или баг пофиксить. В случае, если это буст, то от тебя приоритет этой работы не зависит, да и даже когда команда буста это сделает, результатами её работы ещё надо суметь воспользоваться, не сломав переходом на новую версию буста всё остальное

Во-первых, никто не мешает накатывать патчи, если они необходимы. Вроде народ исправно накатывал патчи на ту же MFC и не жаловался.
Во-вторых, все доступно в исходниках — меняй, если что-то не нравится.
Причем это не GPL, так что ты не обязан сабмитить свои изменения куда-либо.
Например, мы спокойно поменяли пару вещей в буст.тест, потому что нас оно не вполне устраивало, и не испытываем по этому поводу никаких угрызений совести.

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

E>Конечно если ты поставляешь изделие в исходниках, то клиент сам может скомпилировать с нужной версией буста (если сможет конечно, и отладить тоже), но если ты исходники не предоставляешь, то должне использовать такой же буст, какой у клиента...
если заказчик пользуется бустом, то он обычно и говорит, какой именно версией он пользуется, и надо разрабатывать на этой версии.
если не пользуется — значит, надо ему отдавать библиотеки той версии, которую ты используешь.
Не вижу проблемы.

J>>Да им вообще ничего не нужно. Напишут они все на голом С, на указателях на void, и если релиз прошел — все, экономически эффективно. А то, что потом поддержка превращается в кошмар — это уже неэффективность поддерживающей команды, а у изначальной все хорошо, релиз же прошел.
E>Ну да, не только процесса разработки а всегопроцесса использования и разработки кода. Обычно конторы быват либо такие, которые пишут одноразовые решения, и там действительно пофиг на стоимость поддержки. Главное быстро и дёшево разработать (иначе просто не будет спроса на такую услугу, так как проще "девочку посадить")
E>А бывает так, что пишут долговременные решения. С версиями, с поддержкой, со всеми пирогами. И там вполне могут быть разные бизнес-модели. Типа ты можешь решить, что поддержка за время разработки след. версии должна быть не дороже 30% разработки. Ну и измеряй себе экономическую. эффективность процесса в целом, соответсвие его бизнес-моделям и т. д.
Естественно. Набрать обезьянок и заставить их работать круглосуточно "за строчку в резюме".
Мне дед рассказывал историю про одного председателя колхоза, который показал рекордный урожай и получил Сталинскую премию.
А потом выяснилось, что он просто засеял заодно и поля, которые должны были быть под паром, а центнеры с гектара рассчитал только с разрешенных площадей.
Я к тому, что снаружи (по официальным отчетам) все может выглядеть хорошо, типа дешевые программеры, работают 8 часов в день, а на самом деле они и на выходных сидят.
И получается софт, который чудо как хорош по всем показателям, кроме затраханности персонала, о которой никто, кроме самого этого персонала, не знает. Конкретному примеру в следующем году 15 лет стукнет. С версиями, с поддержкой, со всеми пирогами.

J>>"в реальности бывает" не означает "везде", а означает "бывает". Я описанную ситуацию наблюдал многократно, и не только в фирмах, где я работал.
E>Да, так тоде бывает. АФАИК, обычно так бывает вне связи с использованием STL. Мало того, если корреляция есть, то я бы предположил, что она обратная. То есть проекты написанные с буст и STL скорее могут оказаться "бесхозными"

У меня другой опыт

E>Ну я уже рассказывал схему такого сервиса. Когда ты регишь всё критичное объекте запроса, а промежуточные аллокации все делаешь на убиваемомо аллокаторе. И в случае ошибки освобождаешь всё критичное, а всё некритичное просто грохаешь всем аллокатором. Ну и вместо исключений используешь глобальный goto или вообще перезапуск приложения (на платформах без исключений это может бытьочень дешёвой процедурой)
На юниксах это делается гораздо проще: открывается сегмент общей памяти и запускается процесс, который возьмет из него данные, сделает всю работу в своей личной куче, и результат сложит обратно в общую память, после чего помрет и свою кучу с собой прихватит.
И никакой возни с аллокаторами.

E>>>>>>>

E>>>Ну пока что на многопоточных платформах как-то обходятся

J>>Ну да, помолясь, без каких-либо гарантий, что на следующей версии компилятора, ядра ОС и т.п. все продолжит работать

E>Ну я вот знаю разных многопоточных разработчиков. Я так тебе скажу, что основные проблемы у них не от того, что их как-то там ОС кидает, а от того, что они всё делают как-то неправильно. Скажем не верят, что процессор может переупорядочивать инструкции. Или не понимают как доказать невозможность дедлока в своей программе...
Ну так о чем и речь. Когда язык начнет гарантировать, что данный код, помеченный данным атрибутом, защищен от любых оптимизаций (в том числе и встроенных в процессор) — тогда ы можешь гарантировать, что твой код абсолютно корректен. И для этого нужна именно поддержка со стороны языка.
Ну должны быть в язке атомарные типы, ничего ты без них переносимо не сделаешь, котому что в винде это будет какой-нть InterlocetIncrement, а в gcc — atomic_t.

E>Так что стнадартизация, как способ заставить всех наконец прочитать пару книжек -- это, ИМХО, оверкил
Почему? Скажем, если бы стандартизировали, что выражения, в которых встречаются volatile-переменные, должны исполняться в точности как написано — было бы гораздо проще.
Просто посмотри сюда: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2336.html
Будешь точно знать ,что именно обсуждается.
Конкретно: разделы "Active topics in Concurrency sub-group" и "Active topics in both Concurrency and Library sub-groups" (ну и "Background papers for reference" до кучи).
Можешь и сразу сюда заглянуть, чтобы понять, что имено должно быть в языке, если не хочется на каждый чих ставить мьютекс:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2300.html

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

ну так есть фьючерсы, есть work stealing, много идей вообще бродит на эту тему.

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

E>А процедура контроля границ использования boost и
А нафига?
Ну если очень хочется можно сказать что можно из буста использовать только такието библиотеки.

E>корректности его текущей развёртки?

Буст развертывается скриптами на раз.

E>Очень аргументированно.
E>Ответ -- не убелил

См в архитектуре флеймы про синглетоны.

WH>>Против констант заданных на этапе компиляции я ничего не имею.
E>А если на этапе компиляции эти данные вычислить затруднительно?
Например?

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

E>Э-э-э? А зачем его тогда туда переносить?
И я о томже.

E>(Я уж не говорю о том, что делать, если компиллер не знает таких слов...)
У меня VC++8.0 и g++3.3 они понимают весьма много слов.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

AA>>Мы такие проблемы решали прятанием символов с помощью version script. Например, приходится делать что-то типа такого:

E>Это помогает только если у тебя не коллекция SO-шек, с С++ интерфейсом между собой и каким-то интерфейсом наружу.

Не понял. Это помогает от экспорта того, что не надо экспортировать — в данном случае от экспорта STL символов из заголовочных файлов, используемых в реализации библиотеки. В gcc 4.x это можно решить по-другому, но не суть. Ты же описываешь что-то другое, судя по всему?

Или имеется в виду, что есть две группы библиотек, tightly coupled С++ интерфейсом, которые пользуют в интерфейсах boost (но только внутри между собой) и так случилось, что они используют boost разных версий? В этом случае, да, приплыли. Boost не приспособлен для этого. И не только Boost. Впрочем, можно отверсионировать namespace — так мы тоже делаем

E>>>Конечно. Только то, что STL нифига не ключевая технология успеха

E>>>2) Сильно навязывается некоторый подход к использованию памяти. Пир этом сам этот подход немного неудобен
L>>Пункт 2 — это про отсутствие realloc, насколько я понял?
E>Не только. Например на STL неудобно размещать короткие вектора прямо на стеке, скажем...
Согласен. Но это скорее "недоделки" чем принципально неразрешимые проблемы.

E>>>3) Провоцирует неоправданное использование шаблонов в коде. Воообще правоцирует существование шаблонов, которые никто иникогда не проэктировал.
L>>А пункт 3 — не понял совсем, как-то не натыкался на такую проблему.
E>Ну как же. Вот надо тебе написать какой-нибудь алгоритм в STL-стиле. Пишеш не функцию, а шаблон. Обычно параметризованный итератором. Всё конечно хорошо, но реальная жизнь показывает, что эту функцию/функтор никто как шаблон никогда не проектирует. Соответсвенно рожабт всяких уродов.

Э... А что — часто приходится клепать аналоги std::sort или там std::partial_sort? Ну и в любом случае — функтор который в алгоритм передаётся абсолютно никак не обязан быть шаблоном. Или я недопонял чего-то?

L>>Если вы в эти 90% не попадаете — ну что ж, STL/boost действительно не для вас.
E>Ну я про то же. Что для совсем маленькой разработки STL пиремлем, если нет другой, более подходящей либы. Тем более, что он переносим, хотя бы в смысле стандарта STL
E>А вот если проект большой или много, дешевле иметь специализированную конструёвину

Тут всё упирается в количественное измерение "большой" или "много". Сдаётся мне, что 90% проектов (или скажем так — проекты, в которых работают 90% программистов) в понятия "большой" или "много" не попадают

. Особенно у нас, где процветает аутсорсинг который как правило либо небольшие проекты, либо поддержка legacy систем.

L>>Единственно, делать вывод о ненужности STL потому что он не нужен конкретно твоей организации — я всё же не стал бы

E>Да нет. Я о ненужности STL вывод делаю. А совсем другой.
E>1) И без STL жизнь может быть хорошей. Внедрять STL из идеологических соображений, ИМХО, неправильно. Нужнопонимать акую выгоду это принесёт. Тем более, что в случае хорошей жизни может принести и убыток.
Э... Тут позволю себе не согласиться

STL внедрять не надо

Он в подавляющем большинстве случаев — уже есть

И это — огромное преимущество перед библиотеками класса "сам пан склэпав" которые ещё предварительно надо склепать

E>2) Выбирная STL надо понимать что за проблемы и особенности производства разработки он за собой "притянет".
Согласен, но хочу подчеркнуть одну особенность — в случае STL эти проблемы и особенности можно в течение 10 минут найти гуглом. В случае third-party или самописной библиотеки — эти проблемы это поле с высокой травой и разбросанными граблями

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

Согласен целиком и полностью

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

R>Ничего обходить не надо.
R>Тут объект а удаляет себя из списка указателей, указывающих на первый объект, и добавляет себя в список указателей, указывающих на второй объект. Это очень быстро и O(1).

R>Дабы снять непонимание. Никто не хранит как таковой список всех указателей, указывающих на конкретный объект. Все указатели сами организованы в распределённый список. Каждый имеет next и prev на соседние указатели, указывающие на тот же объект. При удалении указателя, он просто удаляет себя из этого списка.

Все, на сегодня тупить закончил. Совершенно упустил из вида, что для удаления указателя нам его искать не надо. И может быть даже удастся обойтись без мьютекса, одними CAS'ами.

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

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

L>Э... А что — часто приходится клепать аналоги std::sort или там std::partial_sort? Ну и в любом случае — функтор который в алгоритм передаётся абсолютно никак не обязан быть шаблоном. Или я недопонял чего-то?

Ну я тоже считаю, что STL-way, то есть такой способ программирования, когда можно в програме взять и заменить std::vector на std::list "если надо" -- не нужная на практике степень унификации. Но встречавшиеся мне любители связки STL + boost это дело постоянно рожают.
В конце концов STL -- это же не только набор шаблонов, но и набор соглашений о том, как нужно программировать контейнеры и алгоритмы, чтобы они были все совместимы между собой.

L>Тут всё упирается в количественное измерение "большой" или "много". Сдаётся мне, что 90% проектов (или скажем так — проекты, в которых работают 90% программистов) в понятия "большой" или "много" не попадают

. Особенно у нас, где процветает аутсорсинг который как правило либо небольшие проекты, либо поддержка legacy систем.

Ну при аутсорсинге обычно всё определено требованиями заказчика

Так что нет нужды обсуждать "использовать STL или не стоит"

E>>1) И без STL жизнь может быть хорошей. Внедрять STL из идеологических соображений, ИМХО, неправильно. Нужнопонимать акую выгоду это принесёт. Тем более, что в случае хорошей жизни может принести и убыток.
L>Э... Тут позволю себе не согласиться

STL внедрять не надо

Он в подавляющем большинстве случаев — уже есть

Ну для маленькой конторы клепать не стоит. Может быть стоит развивать какую-то версию STL, только все реализации очень сложные

Но я бы на всяк. случай ещё посмотрел в сторону конкурентов. MFC там, PowerPlant и т. п.

E>>2) Выбирная STL надо понимать что за проблемы и особенности производства разработки он за собой "притянет".
L>Согласен, но хочу подчеркнуть одну особенность — в случае STL эти проблемы и особенности можно в течение 10 минут найти гуглом. В случае third-party или самописной библиотеки — эти проблемы это поле с высокой травой и разбросанными граблями

Это всё от квалификации разработчиков очень зависит.

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

S>И может быть даже удастся обойтись без мьютекса, одними CAS'ами.

Двухсвязанный список на CAS'ах построить достаточно не тривиально.
Алгоритмы в принципе есть. Вопрос — зачем.

На мьютексах будет быстрее. Единственный смысл делать — если нужна именно lock-free гарантия, для асинхронных обработчиков прерываний например.

Если уж отходить от мьютексов, то есть гораздо более интересные решения и гораздо более производительные и масштабируемые. Я имею в виде решения для управления временем жизни объектов.

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

E>>1) Кто-то должен поддерживать актуальность требований на использование А, Б и В, и следить за их соблюдением
J>это необходимо в случае любой библиотеки, в том числе самописной.
Ну самописная библиотека может быть не такой всеобъемлющей, как буст

J>А у вас в конторе не так? Новая версия самописной или третьей библиотеки (не буста, свят,свят,свят!) просто инсталлируется и используется как есть?

Ну при смене версий конторских либ, те, кто меняют версию, меняют и всех клиентов (это какие-то внутриконторские пользователи библиотеки) соответсвующим образом. Потмо клиенты переходят на изменённую версию.

Когда меняется внешняя библиотека (но такие не бывают всеобъемлющими), то те, кто поддерживают использование этой библиотеки переносият её клиентив на новую версию.

J>Во-вторых, все доступно в исходниках — меняй, если что-то не нравится.
J>Причем это не GPL, так что ты не обязан сабмитить свои изменения куда-либо.
J>Например, мы спокойно поменяли пару вещей в буст.тест, потому что нас оно не вполне устраивало, и не испытываем по этому поводу никаких угрызений совести.

Ну так у нас тоже делали. Но потом эти изменения накапливаются и становится очень дорого поднимать верси исходнйо библиотеки

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

А если у тебя нет заказчика? Если коробочный продукт с большим числом пользователей?

J>И получается софт, который чудо как хорош по всем показателям, кроме затраханности персонала, о которой никто, кроме самого этого персонала, не знает. Конкретному примеру в следующем году 15 лет стукнет. С версиями, с поддержкой, со всеми пирогами.

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

J>На юниксах это делается гораздо проще: открывается сегмент общей памяти и запускается процесс, который возьмет из него данные, сделает всю работу в своей личной куче, и результат сложит обратно в общую память, после чего помрет и свою кучу с собой прихватит.
J>И никакой возни с аллокаторами.
Ну это немного радикальная архитектура -- fork на каждый процесс. В конце коноцв это и на Windows можно, а вот на всяких "нетяжёлых" платформах затруднительно. Да и делать это ради ошибок, которых может и не будет, ИМХО, и не стоит.
Кроме того "критические ресурсы" это же не обязательно память. Это может быть временый файл, сетевое соединение, ещё что-нибудь во внешнем мире

E>>>>>>>>

J>Ну так о чем и речь. Когда язык начнет гарантировать, что данный код, помеченный данным атрибутом, защищен от любых оптимизаций (в том числе и встроенных в процессор) — тогда ы можешь гарантировать, что твой код абсолютно корректен. И для этого нужна именно поддержка со стороны языка.
Скорее всего ты сможешь гарантировта только исключительную тормознутость твоего кода

J>Ну должны быть в язке атомарные типы, ничего ты без них переносимо не сделаешь, котому что в винде это будет какой-нть InterlocetIncrement, а в gcc — atomic_t.

Ну это мелкая проблема. Хотя конкртено аналог InterlocetIncrement втандартизировать наверное можно.

J>ну так есть фьючерсы, есть work stealing, много идей вообще бродит на эту тему.
Ну так слишком их много. Стандартизировать наверное рано.

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

AA>Впрочем, можно отверсионировать namespace — так мы тоже делаем

И мы, когда припирает

L>>Э... А что — часто приходится клепать аналоги std::sort или там std::partial_sort? Ну и в любом случае — функтор который в алгоритм передаётся абсолютно никак не обязан быть шаблоном. Или я недопонял чего-то?

E>Ну я тоже считаю, что STL-way, то есть такой способ программирования, когда можно в програме взять и заменить std::vector на std::list "если надо" -- не нужная на практике степень унификации. Но встречавшиеся мне любители связки STL + boost это дело постоянно рожают.
E>В конце концов STL -- это же не только набор шаблонов, но и набор соглашений о том, как нужно программировать контейнеры и алгоритмы, чтобы они были все совместимы между собой.
Во! Вот это типичная ошибка — считать что контейнеры STL должны быть заменяемы друг на друга лёгким движением руки

ЕМНИП, Герб Саттер, которого я очень уважаю за то что он самый большой практик из всех гуру С++, предлагал забыть об этом принципе сразу и навсегда. ПисАть код который был бы контейнеро-независимым — слишком сложно и в итоге невыгодно экономически в большинстве случаев.

E>Но я бы на всяк. случай ещё посмотрел в сторону конкурентов. MFC там, PowerPlant и т. п.
MFC — отказать сразу

ИМХО, абсолютно безыдейные там стандартные контейнеры. STL куда как прогрессивнее.
А PowerPlant — это http://sourceforge.net/projects/open-powerplant ? Первый раз слышу. Стоящая вещь? Есть смысл смотреть?

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

E>>Очень аргументированно.
E>>Ответ -- не убедил

WH>См в архитектуре флеймы про синглетоны.
Ну и там не убедил

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

WH>Исключения нужно кидать всегда когда случается ошибка.
WH>Они для того и создавались.
Я согласен. Но у нас, во всяком случае, ошибка на каждый чих не случается

А вообще-то всё упирается в то, что делать, когда случилась ошибка?

E>>Э-э-э? А зачем его тогда туда переносить?
WH>И я о томже.
Ну, то есть, переписываем с нуля?

E>>(Я уж не говорю о том, что делать, если компиллер не знает таких слов...)
WH>У меня VC++8.0 и g++3.3 они понимают весьма много слов.
Ну тебе повезло.

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

E>Ну я тоже считаю, что STL-way, то есть такой способ программирования, когда можно в програме взять и заменить std::vector на std::list "если надо" -- не нужная на практике степень унификации. Но встречавшиеся мне любители связки STL + boost это дело постоянно рожают.

Да скорее это возможность один раз написать алгоритм, который работает для всех контейнеров. Т. е., не «алгоритм должен работать при замене vector на deque», а «алгоритм должен работать и для vector, и для deque». Это хороший способ избежать дублирования кода. Например, ты упоминал контейнер, хранящий пары (количество, объект). «STL way» было бы использовать SomeContainer<std::pair<std::size_t, X> > и два вида итераторов, причем оба реализуются десятком-другим строк (один из них ждет тебя уже три года). Заметь, что этот подход позволяет выбирать разные контейнеры для разных задач, и для него автоматически становятся доступны все STL-way-алгоритмы.

Мне что больше всего нравится в STL — задание последовательностей в виде [begin, end) со специальным past-the-end-итератором. Конечно, это придумал не Степанов, такой подход и у Кнута кое-где встречается, но всё равно очень красиво.

По поводу замены контейнеров «на переправе» — да, я с тобой согласен, что это признак кривого дизайна. Потому что выбор подходящих структур данных так же важен, как и выбор алгоритмов.

E>В конце концов STL -- это же не только набор шаблонов, но и набор соглашений о том, как нужно программировать контейнеры и алгоритмы, чтобы они были все совместимы между собой.

А в большинстве других библиотек/языков невозможно/затруднительно отделить контейнеры от алгоритмов. И зря.

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

L>Во! Вот это типичная ошибка — считать что контейнеры STL должны быть заменяемы друг на друга лёгким движением руки

ЕМНИП, Герб Саттер, которого я очень уважаю за то что он самый большой практик из всех гуру С++, предлагал забыть об этом принципе сразу и навсегда. ПисАть код который был бы контейнеро-независимым — слишком сложно и в итоге невыгодно экономически в большинстве случаев.
Вот и я к тому же. Что люди, которые где-то как-то изучили STL, особенно если по пути ещё и зафанатели, всё время в этот грех сваливаются

Чем-то он не очень опытных программистов цепляет

L>А PowerPlant — это http://sourceforge.net/projects/open-powerplant ? Первый раз слышу. Стоящая вещь? Есть смысл смотреть?
Ну мне лично не особо понравился. ИМХО STL не такой странный. Правда open-версии я не смотрел. Но пока она была проприетарной была в смысле коньейнеров не супер. Хотя как конструктор интерфейсов содержала довольно прикольные мульки

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

RO>Заметь, что этот подход позволяет выбирать разные контейнеры для разных задач, и для него автоматически становятся доступны все STL-way-алгоритмы.

Да я понимаю плюсы STL-way. Но в целом я его всё-таки нахожу слишком сложным дляреальных задач. Так скажем.

RO>А в большинстве других библиотек/языков невозможно/затруднительно отделить контейнеры от алгоритмов. И зря.

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

)
Вот это одна из трёх моих основных претензий к STL

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

S>>И может быть даже удастся обойтись без мьютекса, одними CAS'ами.
R>Двухсвязанный список на CAS'ах построить достаточно не тривиально.

А может, хватит и односвязного кольцевого списка?

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

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

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

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

S>>>И может быть даже удастся обойтись без мьютекса, одними CAS'ами.
R>>Двухсвязанный список на CAS'ах построить достаточно не тривиально.

RO>А может, хватит и односвязного кольцевого списка?

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

Что не есть хорошо, т.к. сложность увеличивается до O(N), плюс снижается локальность обращения к памяти (т.е. придётся "потрогать" много разрозненных кусочков памяти).
Плюс встаёт вопрос, а как синхронизировать доступ к списку во время этого обхода. Толи лочить весь список на глобальном, для этой группы указателей, мьютексе (не понятно, кстати, где его хранить), толи лочить на вообще глобальном мьютексе (это вообще убийство), толи на каждый указатель делать свой мьютекс и захватывать O(N) мьютексов (что тоже звучит не особо привлекательно), толи применять lock-free reader pattern типа RCU (за исключением сложности и необходимости переделки инфраструктуры, вариант хороший).

Имхо, тут двухсвязный список — то, что доктор прописал.
...правда как его синхронизировать тоже не очевидно.
Совсем глобальный мьютекс — плохо.
Мьютекс на группу указателей — не понятно где его хранить — мы же хотим быть не интрузивными и не выделять никаких дополнительных блоков памяти.
Надо мьютекс на указатель что ли делать... я правда пока не понимаю, как это можно сделать...
У кого-нибудь есть какие-нибудь предложения...

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

Erop пишет:
>
> Но моё ИМХО, кстати такое, что даже это не критично. Это всё неприятно
> конечно, но обычно такой параметр, как "качество и поддерживаемость
> кода" зависит не от того "С с классами" или "STL с бустом", а от
> каких-то других характеристик кода.
Ну это достаточно просто. Два наиболее важных фактора: связность кода
(модулей системы любого уровня) и его документируемость, кстати обе
характеристики тоже не количественные.

Posted via RSDN NNTP Server 2.0

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

E>Ну самописная библиотека может быть не такой всеобъемлющей, как буст

"всеобъемлющий" — слишком расплывчатое слово.
Буст — это набор библиотек.
Никто не мешает взять оттуда необходимый (и подходящий вам) невсеобъемлющий набор библиотек (скажем, только string_algo и multi_index).

J>>А у вас в конторе не так? Новая версия самописной или третьей библиотеки (не буста, свят,свят,свят!) просто инсталлируется и используется как есть?

E>Ну при смене версий конторских либ, те, кто меняют версию, меняют и всех клиентов (это какие-то внутриконторские пользователи библиотеки) соответсвующим образом. Потмо клиенты переходят на изменённую версию.
E>Когда меняется внешняя библиотека (но такие не бывают всеобъемлющими), то те, кто поддерживают использование этой библиотеки переносият её клиентив на новую версию.

Про всеобъемлющесть я уже писал. Про остальное — не вижу в бусте никакой специфики, делающей ее в этом плане непохожими на другие библиотеки.

E>Ну так у нас тоже делали. Но потом эти изменения накапливаются и становится очень дорого поднимать верси исходнйо библиотеки

Смотря какие изменения. Если изменения сильно специфические для ваших проектов — это одно, а если вы там баг нашли (или они сами баг нашли и пофиксили его в своем SVN) — так этот багфикс и так будет присутствовать в следующей версии.

E>А если у тебя нет заказчика? Если коробочный продукт с большим числом пользователей?

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

E>

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

J>>На юниксах это делается гораздо проще: открывается сегмент общей памяти и запускается процесс, который возьмет из него данные, сделает всю работу в своей личной куче, и результат сложит обратно в общую память, после чего помрет и свою кучу с собой прихватит.
J>>И никакой возни с аллокаторами.
E>Ну это немного радикальная архитектура -- fork на каждый процесс. В конце коноцв это и на Windows можно, а вот на всяких "нетяжёлых" платформах затруднительно. Да и делать это ради ошибок, которых может и не будет, ИМХО, и не стоит.
E>Кроме того "критические ресурсы" это же не обязательно память. Это может быть временый файл, сетевое соединение, ещё что-нибудь во внешнем мире

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

J>>Ну так о чем и речь. Когда язык начнет гарантировать, что данный код, помеченный данным атрибутом, защищен от любых оптимизаций (в том числе и встроенных в процессор) — тогда ы можешь гарантировать, что твой код абсолютно корректен. И для этого нужна именно поддержка со стороны языка.
E>Скорее всего ты сможешь гарантировта только исключительную тормознутость твоего кода

Сейчас, когда этого можно добиться только с мьютексами — да.

J>>Ну должны быть в язке атомарные типы, ничего ты без них переносимо не сделаешь, котому что в винде это будет какой-нть InterlocetIncrement, а в gcc — atomic_t.

E>Ну это мелкая проблема. Хотя конкртено аналог InterlocetIncrement втандартизировать наверное можно.
Где же это мелкая проблема, если это базовый блок для построения семафоров

J>>ну так есть фьючерсы, есть work stealing, много идей вообще бродит на эту тему.
E>Ну так слишком их много. Стандартизировать наверное рано.
рано, говоришь? это с 70 годов как минимум обсуждается

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

J>Никто не мешает взять оттуда необходимый (и подходящий вам) невсеобъемлющий набор библиотек (скажем, только string_algo и multi_index).
Короче. Объясняю последний раз. НЕУДОБНО. Почему? ИМХО, потому, что никто не позаботился о том, чтобы было удобно...

E>>Когда меняется внешняя библиотека (но такие не бывают всеобъемлющими), то те, кто поддерживают использование этой библиотеки переносият её клиентив на новую версию.
J>Про всеобъемлющесть я уже писал. Про остальное — не вижу в бусте никакой специфики, делающей ее в этом плане непохожими на другие библиотеки.
Ну перенести какого-то одного клиента и все проекты конторы -- это довольно значительная разница

E>>Ну так у нас тоже делали. Но потом эти изменения накапливаются и становится очень дорого поднимать верси исходнйо библиотеки

Опять повторю: ПРОБОВАЛИ (правда конкртено это не с бустом) -- НЕ ПОНРАВИЛОСЬ. Да, ткие мы вот криворукие. Видимо именно поэтому он нам и не подходит

J>Тогда им вообще слово "буст" неинтересно и ни о чем не скажет, пиши на чем хочешь.
Ну мы так и делаем.

И в таких условиях буст таки сливает

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

Это безусловно особенности управления разработкой ПО, как индустриальным производством. ИМХО это ключевой момент нашего бизнеса, а вовсе и не STL/boost.
Правда мне так кажется, хотя я и не готов обосновать это мнение, что в архитектуре STL есть какой-то минорный косяк, который мешает кдобному управлению разработкой по STL-way...
Возможно это потому, что мы не умеем кправлять этим бардаком достаточно эффективно.

E>>Кроме того "критические ресурсы" это же не обязательно память. Это может быть временый файл, сетевое соединение, ещё что-нибудь во внешнем мире

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

J>

E>>Скорее всего ты сможешь гарантировта только исключительную тормознутость твоего кода

J>Сейчас, когда этого можно добиться только с мьютексами — да.
А что, от принятия стандарта C++ изменится аппаратура? Или, может быть, ОС?

J>Где же это мелкая проблема, если это базовый блок для построения семафоров
Ну она везде решена. Дело только за тем, что непереносимо. Но можно завести переносимый уровень абстракции. Их, в принципе, уже есть довольно много всяких. Но можно и стандартизировать. Эта тема, ИМХО, уже достаточно устоялась.

J>рано, говоришь? это с 70 годов как минимум обсуждается
Ну так к единообразному решению пока вроде же не пришли?

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

RO>>А в большинстве других библиотек/языков невозможно/затруднительно отделить контейнеры от алгоритмов. И зря.

E>Ну вот грубо говоря, эта самая возможность "отделить контейнеры от алгоритмов" и провоцирует в конце коноцов кукчу шаблонного кода, который никто никогда не проектировал, как шаблоны. А так как шаблоны в C++ кривенькие, и без проектирования их лучше не писать, то и код выходит кривенький (ну может у супер-пупер перцев не кривенький, выходит, но супер-пупер перцев мало :( )
E>Вот это одна из трёх моих основных претензий к STL :)

Ну вот тебе реальная задача: объединить содержимое двух упорядоченных последовательностей.

  template<typename _InputIterator1, typename _InputIterator2,
           typename _OutputIterator>
    _OutputIterator
    set_union(_InputIterator1 __first1, _InputIterator1 __last1,
              _InputIterator2 __first2, _InputIterator2 __last2,
              _OutputIterator __result)
    {
      // concept requirements
      __glibcxx_function_requires(_InputIteratorConcept<_InputIterator1>)
      __glibcxx_function_requires(_InputIteratorConcept<_InputIterator2>)
      __glibcxx_function_requires(_OutputIteratorConcept<_OutputIterator,
            typename iterator_traits<_InputIterator1>::value_type>)
      __glibcxx_function_requires(_SameTypeConcept<
            typename iterator_traits<_InputIterator1>::value_type,
            typename iterator_traits<_InputIterator2>::value_type>)
      __glibcxx_function_requires(_LessThanComparableConcept<
            typename iterator_traits<_InputIterator1>::value_type>)
      __glibcxx_requires_sorted(__first1, __last1);
      __glibcxx_requires_sorted(__first2, __last2);

      while (__first1 != __last1 && __first2 != __last2)
        {
          if (*__first1 < *__first2)
            {
              *__result = *__first1;
              ++__first1;
            }
          else if (*__first2 < *__first1)
            {
              *__result = *__first2;
              ++__first2;
            }
          else
            {
              *__result = *__first1;
              ++__first1;
              ++__first2;
            }
          ++__result;
        }
      return std::copy(__first2, __last2, std::copy(__first1, __last1,
                                                    __result));
    }

Один раз написано, один раз отлажено, один раз тщательно протестировано — и работает.

EropsMysteriousCompany::ProprietaryContainers::DynamicArray<WeHateTemplates> x, y, z;
// std::set_union(x.begin(), x.end(), y.begin(), y.end(), std::back_inserter(z));
как?

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

S>>>>И может быть даже удастся обойтись без мьютекса, одними CAS'ами.
R>>>Двухсвязанный список на CAS'ах построить достаточно не тривиально.
RO>>А может, хватит и односвязного кольцевого списка?
R>Тогда при удалении каждого указателя придётся проходить весь список, что бы найти себя сзади :)

«Ну чесне слово — як діти». this->ptr = this->next->ptr; oldNext = this->next; this->next = this->next->next; delete oldNext. Заборы расставить по вкусу.

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

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

S>>>>>И может быть даже удастся обойтись без мьютекса, одними CAS'ами.
R>>>>Двухсвязанный список на CAS'ах построить достаточно не тривиально.
RO>>>А может, хватит и односвязного кольцевого списка?
R>>Тогда при удалении каждого указателя придётся проходить весь список, что бы найти себя сзади

RO>«Ну чесне слово — як діти». this->ptr = this->next->ptr; oldNext = this->next; this->next = this->next->next; delete oldNext. Заборы расставить по вкусу.

Это ты удалил не this из списка, а следующий элемент. Ты попробуй this удалить.

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

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

J>>Никто не мешает взять оттуда необходимый (и подходящий вам) невсеобъемлющий набор библиотек (скажем, только string_algo и multi_index).
E>Короче. Объясняю последний раз. НЕУДОБНО. Почему? ИМХО, потому, что никто не позаботился о том, чтобы было удобно...

А мне вот удобно

Что я делаю не так

E>Ну перенести какого-то одного клиента и все проекты конторы -- это довольно значительная разница

Еще раз — буст ничем не отличается в этом плане от любой другой библиотеки.

E>>>Ну так у нас тоже делали. Но потом эти изменения накапливаются и становится очень дорого поднимать верси исходнйо библиотеки

E>Опять повторю: ПРОБОВАЛИ (правда конкртено это не с бустом) -- НЕ ПОНРАВИЛОСЬ. Да, ткие мы вот криворукие. Видимо именно поэтому он нам и не подходит

J>>Тогда им вообще слово "буст" неинтересно и ни о чем не скажет, пиши на чем хочешь.
E>Ну мы так и делаем.

И в таких условиях буст таки сливает

Не представляю, как он может в таких условиях сливать... Хотя у вас же там суперэкзотичечские платформы с суперкривыми компиляторами... Но я бы тогда, вообще-то, и не рассчитывал бы, что эти компиляторы поддерживают стандарт во всем, что не касается шаблонов. Скорее всего, у них там тоже косяков предостаточно — наверняка они время от времени не зовут вообще или зовут лишний раз деструкторы и т.д.
Я бы в таких условиях писал на чистом С.

E>Это безусловно особенности управления разработкой ПО, как индустриальным производством. ИМХО это ключевой момент нашего бизнеса, а вовсе и не STL/boost.
Согласен.

E>Правда мне так кажется, хотя я и не готов обосновать это мнение, что в архитектуре STL есть какой-то минорный косяк, который мешает кдобному управлению разработкой по STL-way...
Предлагаешь вернуться к тому нашему долгому обсуждению STL-way? Я, вроде, показал на конкретном примере, что STL-way (или, если не нравится это слово, вообще подход алгоритмы <=> итераторы <=> контейнеры, его не обязательно реализовывать именно на STL, просто в STL она во главе угла) отлично работает и очень удобен. Если, конечно, компилятор вменяемый (хотя бы на уровне вц6).

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

E>>>Кроме того "критические ресурсы" это же не обязательно память. Это может быть временый файл, сетевое соединение, ещё что-нибудь во внешнем мире

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

J>>

E>>>Скорее всего ты сможешь гарантировта только исключительную тормознутость твоего кода

J>>Сейчас, когда этого можно добиться только с мьютексами — да.
E>А что, от принятия стандарта C++ изменится аппаратура? Или, может быть, ОС?
нет, появятся гарантии, что если ты написал какое-то выражение, то оно выполнится именно так, как ты написал, и ты сможешь это гарантировать безо всяких шаманских плясок, коими радует нас remark (я имею в виду его пост про double lock).

J>>Где же это мелкая проблема, если это базовый блок для построения семафоров
E>Ну она везде решена. Дело только за тем, что непереносимо. Но можно завести переносимый уровень абстракции. Их, в принципе, уже есть довольно много всяких. Но можно и стандартизировать. Эта тема, ИМХО, уже достаточно устоялась.

Ну вот и стандартизируют. Что и требовалось. С чем ты споришь-то?

J>>рано, говоришь? это с 70 годов как минимум обсуждается
E>Ну так к единообразному решению пока вроде же не пришли?
Так потому что на каждую задачу требуется свое решение.
Хотя, конечно, есть некоторые тормозные, но безотказные вещи (мьютексы), которые, как самое простое для понимания, вцементированы в некоторые языки в виде слов типа synchronized. Чем не единообразное решение

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

RO>Ну вот тебе реальная задача: объединить содержимое двух упорядоченных последовательностей.

0) Ты привёл код, который делает не то, что ты просил. Он ещё и повторы выбрасывает, вернее не совсем так. Если одинаковое значение есть и в первой и во второй последовательности, то в результирующую последовательность кладёт только одно значение. А вот если в исходных последовательностях есть повторы, то поведение неопределено. Наверное предполагается, что в исходных последовательностях повторов нет, но это от чего-то не проверяется

1) Это стандартный алгоритм, его таки проектировали, я надеюсь

2) Мне кажется, что он нужен довольно редко

3) Даже если двухпутевое слиение написать "из головы", оно у нормального программиста обычно работает сразу. ИМХО лучше уметь программировать любой алгоритм, чем уметь пользоваться merge. Тем более, что набор алгоритмов в STL ИМХО никакой состематичностью не обладает. Хотя это не совсем двухпутевое слияние, конечно, так как повторы не копируются.

4) (И это главное, на самом деле) Это очень абстрактная задача. Реальная задача звучит как-то так: "Рассчитать аэродинамику такого-то самолёта"

RO>

RO>EropsMysteriousCompany::ProprietaryContainers::DynamicArray<WeHateTemplates> x, y, z;
RO>// std::set_union(x.begin(), x.end(), y.begin(), y.end(), std::back_inserter(z));
RO>как?
RO>

Ну совсем так я не знаю, а если просто выбрасывать повторы, то так:

x.CopyTo( z );
z.SortedMerge( y );
RemoveDuplicatesInSortedArray( z );

Или даже так:

assert( !HasDuplicatesInSortedArray( x ) && !HasDuplicatesInSortedArray( y ) );
x.CopyTo( z );
z.SortedMerge( y );
RemoveDuplicatesInSortedArray( z );

Правда мне обычно RemoveDuplicatesInSortedArray не требуется. Вернее так, если требуется, то используется другая структура данных (собственно множество)

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

RO>«STL way» было бы использовать SomeContainer<std::pair<std::size_t, X> > и два вида итераторов, причем оба реализуются десятком-другим строк (один из них ждет тебя уже три года).
Очевидно, что так можно сделать и без STL и даже без STL-way, но ИМХО понятие "масив" который как-то хитро хранит потроха и имеет возможности необычной итерации намного удобнее для использования чем эта вот конструкция. Конечно в конце концов её можно завернуть в шаблон класса и выставить наружу два итератора. Такой и сякой. И мы получим итераторы к тем же данным. То есть, ИМХО, эквивалентное решение. Если тебе удобно мыслить на языке итераторов, то оно тебе будет органично, а если на языке массивов, то нет. На этом различия заканчиваются...

RO>Заметь, что этот подход позволяет выбирать разные контейнеры для разных задач, и для него автоматически становятся доступны все STL-way-алгоритмы.
Заметь, что в качестве примера "реальной задачи" ты привёл очень абстрактную математическую конструкцию. Да ещё и неудачно, ИМХО, реализованную (я бы хотел проверки отсутствия повторов в исходных последовательностях в _DEBUG версии программы)
И это код написанный спецами!!!

RO>Мне что больше всего нравится в STL — задание последовательностей в виде [begin, end) со специальным past-the-end-итератором. Конечно, это придумал не Степанов, такой подход и у Кнута кое-где встречается, но всё равно очень красиво.

Да, завести маркер конца во многих алгоритмах очень удобно!!!
Мне такая шняга тоже нравится!!!
Поинт в том, что эти все алгоритмы нужны таки редко, а маркер конца тягать за собой надо всё время.
То же двухпутевое слиение, можно записать и без конца. Вот смотри (пишу специально с "итераторами", чтобы быть понятным, зато "из головы"):

template<class TArray&>
class CSortedArraysMerger {
public:
    static void Process( const TArray& src1, const TArray& src2, TArray& dst )
    {
        CArrayIterator i1( src1 );
        CArrayIterator i2( src2 );
        TArray buffer;
        for( ; ; ) {
            if( i2.IsEnd() ) {
                i1.CopyRestTo( buffer );
                break;
            } else {
                i1.CopyLessOreEquTo( i2, buffer );
            }
            if( i1.IsEnd() ) {
                i2.CopyRestTo( buffer );
                break;
            } else {
                i2.CopyLessOreEquTo( i1, buffer );
            }
        }
        assert( i1.IsEnd() && i2.IsEnd() && src1.Size() + src2.Size() == buffer.Size() );
        buffer.MoveTo( dst ); // Можно и std::swap( dst, buffer ); 
    }

private:
    struct CArrayIterator {
        const TArray& Data;
        int Index;
        
        CArrayIterator( const TArray& src ) : Data( src ), Index( 0 ) {}
        bool IsEnd() const { return Index >= Data.Size(); }
        void CopyRestTo( TArray& dst )
        {
            while( !IsEnd() )
                dst.Add( Data[Index++] );
        }
        void CopyLessOreEquTo( CArrayIterator& other, TArray& dst ) 
        {
            assert( !other.IsEnd() );
            while( !IsEnd() && Data[Index] <= other.Data[other.Index] )
                dst.Add( Data[Index++] );
        }
    };
};

template<typename T>
void MergeSorted( const CErrorsMysticArray<T>& src1, 
    const CErrorsMysticArray<T>& src2, CErrorsMysticArray<T>& dst )
{
    CSortedArraysMerger< CErrorsMysticArray<T> >::Process( src1, src2, dst );
}

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

L>А так — получается что либо мне нужно писать кучу кода каждый раз когда нужно слить 2 строки вместе — либо писАть свой велосипед.

Ну strcat-то у тебя не отобрали

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

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

L>>А так — получается что либо мне нужно писать кучу кода каждый раз когда нужно слить 2 строки вместе — либо писАть свой велосипед.

E>Ну strcat-то у тебя не отобрали

Ну-ну, попробуй strcat заюзать на Маке, я на тебя посмотрю

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

J>А мне вот удобно

Что я делаю не так

Не знаю. Наверное мы не так что-то делаем. Ну может команда буста постепенно достигнет такого прогресса, что и мы поймём

J>Еще раз — буст ничем не отличается в этом плане от любой другой библиотеки.
ОТлиячается объемом зависимого кода. Одно дело, когда от стороненй библиотеи завист несколько классов-переходников, и совсем дургое, если зависит весь код всех проектов.

J>Я бы в таких условиях писал на чистом С.
Ты не понял. Остнованя разработка ведётся под Windows, и потом переносится под Linux и Mac OS.
Но, часто какие-то куски системы приходится переносить и на всякие экзотические платформы. Обычно мобильные или встраеваемые в какое-то устройство.
Но ИМХО такое качество кода, как "некритическая зависимоть от" исключений, сложных шаблонов, шаблонов, статических объектов и т. д. улучшает код, даже если переносит код на модильнве платформы не понадобится.
Улучшает в смысле стоимости разработки и поддержки. По нашему опыту.

J>Предлагаешь вернуться к тому нашему долгому обсуждению STL-way?
Нет, просто сам хочу понять что же не так в STL. Видимо система ценностей.

А абстрагировать алгоритмы -- так кто же против? Только абстрагировать надо очень мало алгоритмов. Ну типа на большой проект может процент наберётся кода, который абстрагированными алгоритмами стоит сделать. И просто в рамках шаблонов C++ можно абстрагировать. STL для этого ненужен. Для этого нужен высококвалифицированный специалист...

E>>Ну я же писал -- регишь критические ресурсы в запросе. При откате запроса их по списочку освобождаешь...
J>Тогда непонятно, причем тут твои рассуждения про аллокатор, когда тебе нужен типизированный (скорее всего) контейнер.
Не понял. Какой такой контейнер и зачем?
А ллокатор нужен для того, чтобы о памяти не парится, в случае если освобождение дорогое или если нет исключений.

J>>>

E>>А что, от принятия стандарта C++ изменится аппаратура? Или, может быть, ОС?
J>нет, появятся гарантии, что если ты написал какое-то выражение, то оно выполнится именно так, как ты написал, и ты сможешь это гарантировать безо всяких шаманских плясок, коими радует нас remark (я имею в виду его пост про double lock).

Да откуда они появятся? Если сейчас нельзя сделать быстро, то и после стандартизации не будет льзя

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

J>Ну вот и стандартизируют. Что и требовалось. С чем ты споришь-то?

Не, тут я согласен и даже за

J>Так потому что на каждую задачу требуется свое решение.
J>Хотя, конечно, есть некоторые тормозные, но безотказные вещи (мьютексы), которые, как самое простое для понимания, вцементированы в некоторые языки в виде слов типа synchronized. Чем не единообразное решение

Ну вот в том-то и дело, что не стандарта нет, а универсального решения

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

RO>«Ну чесне слово — як діти». this->ptr = this->next->ptr; oldNext = this->next; this->next = this->next->next; delete oldNext. Заборы расставить по вкусу.

Угу.
1) Удалил не того
2) delete oldNext-то за что?

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

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

Вот, золотые слова!
Я, собственно, о том же самом толкую всю дорогу.
Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.

RO>>Заметь, что этот подход позволяет выбирать разные контейнеры для разных задач, и для него автоматически становятся доступны все STL-way-алгоритмы.
E>Заметь, что в качестве примера "реальной задачи" ты привёл очень абстрактную математическую конструкцию. Да ещё и неудачно, ИМХО, реализованную (я бы хотел проверки отсутствия повторов в исходных последовательностях в _DEBUG версии программы)

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

E>маркер конца тягать за собой надо всё время.
Либо воспользоваться boost::range.
Причем есть соответствующее предложение по стандартизации оного:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2245.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html

L>>А так — получается что либо мне нужно писать кучу кода каждый раз когда нужно слить 2 строки вместе — либо писАть свой велосипед.

E>Ну strcat-то у тебя не отобрали

strcat — это не обьединение строк. Мне ещё нужно посчитать длинну результирующей строки, выделить память, скопировать исходную строку в эту память, потом собственно strcat (в Symbian принято HBufC->Des().Append()), потом ещё не забыть поочищать буфера если нужно. Неслабо для операции которая встречается сплошь и рядом?

На самом деле вот примерный код:

HBufC* ConcatenateStringsLC(const TDesC& s1, const TDesC& s2) 
    {
    HBufC* ret = HBufC::NewLC(s1.Length() + s2.Length());
    ret->Des().Append(s1);
    ret->Des().Append(s2);
    return ret;
    }

// Пример использования функции:
_LIT(KStr1, "str1");
_LIT(KStr2, "str2");

HBufC* res = ConcatenateStringsLC(KStr1, KStr2);

// Делаем что-то со строкой.

CleanupStack::PopAndDestroy(); // Не забыть!!! Иначе - крэш. А если владение строкой мы куда-то отдали - то нужно вызывать не CleanupStack::PopAndDestroy а просто CleanupStack::Pop

Ну как — удобно выглядит?

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

J>Вот, золотые слова!
J>Я, собственно, о том же самом толкую всю дорогу.
J>Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
J>Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.
Ну вот я же всю дорогу толкую что бесплатных фич не бывает. ИМХО эта возможность ненужная, но дорогая.

J>Спорно. Это может привести к тому, что у тебя программа под дебагом будет работать месяц.
J>Скажем, если ты хочешь навесить обязательную проверку отсортированности контейнера для какого-нть binary_search, который у тебя зовется миллион раз за время работы программы.
Обрати внимание, что сортированность тут таки проверяется...
Мало того, сам этот алгоритм O( src1.Size() + src2.Size() ), и проверки сортированности и отсутсвия повторов той же сложности. Мало того проверка отсутвия повторов и проверка сортированности отличается только опреатором сравнения...

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

J>Ну-ну, попробуй strcat заюзать на Маке, я на тебя посмотрю

А в чём проблема? В паскалевских строчках? Ну так никто тебя не заставляет для "единственной в программе операции над строками" использовать паскалевские строчки

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

L>strcat — это не обьединение строк. Мне ещё нужно посчитать длинну результирующей строки, выделить память, скопировать исходную строку в эту память, потом собственно strcat (в Symbian принято HBufC->Des().Append()), потом ещё не забыть поочищать буфера если нужно. Неслабо для операции которая встречается сплошь и рядом?

Ну ты уж определись. Толи у тебя "одно объединение строк при старте программы", толи "частая операция"

L>Ну как — удобно выглядит?

Ну вполне себе pure C style библиотека. Скорее всего такую модель работы с данными родили ещё до С++.
В принципе ничто не мешате обернуть эти строчки "умными строчками", которые правильно занимаются владением, Detach там метод, Release в деструкторе и т. п., над которыми можно навернуть операторы и т. д.

Скорее всего такая библиотека вообще уже есть

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

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

J>>Вот, золотые слова!
J>>Я, собственно, о том же самом толкую всю дорогу.
J>>Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
J>>Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.
E>Ну вот я же всю дорогу толкую что бесплатных фич не бывает. ИМХО эта возможность ненужная, но дорогая.
имхо, если нечто висит в интерфейсе, но не используется, то это и есть бесплатно.
Более того, даже если фича и не бесплатная, согласись, это совсем не означает, что она дорогая.
Если у тебя итераторы могет сравниваться — дело пяти минут предоставить соответствующий интерфейс.
Даже если и не умеют, вообще говоря — тоже дело пяти минут, посмотри, как сделан, скажем, istream_iterator

E>Обрати внимание, что сортированность тут таки проверяется...
Я Пастернака не читал

Но если это и так делается — это да, можно и вставить ассерт.

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

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

J>>Ну-ну, попробуй strcat заюзать на Маке, я на тебя посмотрю

E>А в чём проблема? В паскалевских строчках? Ну так никто тебя не заставляет для "единственной в программе операции над строками" использовать паскалевские строчки

В них, в родимых

Я, наверное, пропустил про "единственную операцию". Да не суть.
Суть в том, что паскалевские строчки элементарно оборачиваются в basic_string, поскольку она не хранит внутри себя сишную строку, а хранит именно размер.
Стало быть, ты можешь взять прогу, которую ты написал для нормальной оси, в которой сишные строки везде (а написал ты ее на STL), и изменил только то место, где ты эти строчки рожаешь (а это место тебе и так придется менять, поскольку там идет общение с непереносимым местным API).

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

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

У меня к тебе просьба, когда ты таки поймёшь, что бесплатных фич не бывает, то напиши мне про это?

E>>Обрати внимание, что сортированность тут таки проверяется...
J>Я Пастернака не читал

Ну я вот просмотрел приведённый тобой код...
J>Но если это и так делается — это да, можно и вставить ассерт.
Там не assert, а какая-то другая конструёвина...

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

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

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

E>Ну я вот просмотрел приведённый тобой код...
Не мной

Или ты какой-то другой код имеешь в виду?

E>Ну ты уж определись. Толи у тебя "одно объединение строк при старте программы", толи "частая операция"
Никакого противоречия тут нет. Обьединение строк часто встречается в тексте программы. Но реально весь код обьединения всех строк работает 1% времени работы программы.

L>>Ну как — удобно выглядит?
E>Ну вполне себе pure C style библиотека. Скорее всего такую модель работы с данными родили ещё до С++.
Ничего подобного. Symbian изначально был писАн на С++. pure C там никогда не использовался.

E>В принципе ничто не мешате обернуть эти строчки "умными строчками", которые правильно занимаются владением, Detach там метод, Release в деструкторе и т. п., над которыми можно навернуть операторы и т. д.
Ну, у меня в коде это выглядит примерно так:

_LIT(KStr1, "str1");
_LIT(KStr2, "str2");
auto_ptr<HBufC> str;
AppendStr(str, KStr1);
AppendStr(str, KStr2);

// Тут используем str

Но сдаётся мне, что если даже для таких простых вещей мне нужно писАть велосипеды — то архитектор этой системы абсолютно зря получает свою архитекторскую зарплату.

E>Скорее всего такая библиотека вообще уже есть

Нету

По крайней мере я не находил ничего такого. У Симбиана вообще всё плохо с нормальными библиотеками — очень мало кто хочет с ним связываться.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

E>>Ну я вот просмотрел приведённый тобой код...
J>Не мной

Упс!
Да, это был Roman Odaisky

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

L>

L>auto_ptr<HBufC> str;
L>

auto_ptr тут нехорошо, так как надо ещё Pop где-то делать!!!

L>...архитектор этой системы абсолютно зря получает свою архитекторскую зарплату.
L>Нету

По крайней мере я не находил ничего такого. У Симбиана вообще всё плохо с нормальными библиотеками — очень мало кто хочет с ним связываться.

Странно. Вообще-то вроде бы популярная платформа...

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

E>0) .... А вот если в исходных последовательностях есть повторы, то поведение неопределено. Наверное предполагается, что в исходных последовательностях повторов нет, но это от чего-то не проверяется

Почему не определено?

Конечно, из 25.3.5.2 это напрямую не следует, но к примеру в MSDN.

When there are equivalent elements in both source ranges, the elements in the first range precede the elements from the second source range in the destination range. If the source ranges contain duplicates of an element, then the destination range will contain the maximum number of those elements that occur in both source ranges.

Судя по-всему эта функция работает так же.

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

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

E>>0) .... А вот если в исходных последовательностях есть повторы, то поведение неопределено. Наверное предполагается, что в исходных последовательностях повторов нет, но это от чего-то не проверяется

S>Почему не определено?

S>Конечно, из 25.3.5.2 это напрямую не следует, но к примеру в MSDN.
Зато явно следует из 25.3.5

[lib.alg.set.operations] 25.3.5 Set operations on sorted structures
This section defines all the basic set operations on sorted structures. They also work with multisets
(23.3.4) containing multiple copies of equivalent elements. The semantics of the set operations are general-
ized to multisets in a standard way by defining union() to contain the maximum number of occur-
rences of every element,intersection()to contain the minimum, and so on.

L>>

L>>auto_ptr<HBufC> str;
L>>

E>auto_ptr тут нехорошо, так как надо ещё Pop где-то делать!!!
auto_ptr тут самописный. Он сам Pop и делает.

E>Странно. Вообще-то вроде бы популярная платформа...
Это она среди пользователей популярная.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

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

J>>Вот, золотые слова!
J>>Я, собственно, о том же самом толкую всю дорогу.
J>>Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
J>>Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.
E>Ну вот я же всю дорогу толкую что бесплатных фич не бывает. ИМХО эта возможность ненужная, но дорогая.

J>>Спорно. Это может привести к тому, что у тебя программа под дебагом будет работать месяц.
J>>Скажем, если ты хочешь навесить обязательную проверку отсортированности контейнера для какого-нть binary_search, который у тебя зовется миллион раз за время работы программы.
E>Обрати внимание, что сортированность тут таки проверяется...
E>Мало того, сам этот алгоритм O( src1.Size() + src2.Size() ), и проверки сортированности и отсутсвия повторов той же сложности. Мало того проверка отсутвия повторов и проверка сортированности отличается только опреатором сравнения...

Алгоритм set_union не требует отсутствия повторов. (т.е. работает на multi_set)

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

L>>Во! Вот это типичная ошибка — считать что контейнеры STL должны быть заменяемы друг на друга лёгким движением руки

ЕМНИП, Герб Саттер, которого я очень уважаю за то что он самый большой практик из всех гуру С++, предлагал забыть об этом принципе сразу и навсегда. ПисАть код который был бы контейнеро-независимым — слишком сложно и в итоге невыгодно экономически в большинстве случаев.
E>Вот и я к тому же. Что люди, которые где-то как-то изучили STL, особенно если по пути ещё и зафанатели, всё время в этот грех сваливаются

E>Чем-то он не очень опытных программистов цепляет

Вот, кажется, вот где собака порылась

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

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

Мне кажется, что новые идеи обычно вызывают подозрения у "старперов", по этой причине всё внимание уделяется в основном недостаткам (по крайне мере как они там видят). Сам STL конечно полностью не идеален.

Короче это моё ИМХО. Я не фанат STL, и особых восторгов по поводу него не испытываю, просто принимаю как данность, пытаюсь разобраться, научиться, это всё же не просто библиотека там каких то контейнеров. Рождение буста обязано ему, и я уверен что рождение "новых" программистов тоже не за горами

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

... << RSDN@Home 1.2.0 alpha rev. 710>>

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

J>>Еще раз — буст ничем не отличается в этом плане от любой другой библиотеки.
E>ОТлиячается объемом зависимого кода. Одно дело, когда от стороненй библиотеи завист несколько классов-переходников, и совсем дургое, если зависит весь код всех проектов.
Я думаю, от библиотеки контейнеров зависят не несколько классов-переходников, независимо от того, кем она написана.
А вот всякие мелкие библиотеки из буста типа, скажем, токенайзера или того же регэкса — скорее всего, будут в нескольких классах-переходниках и влияния на всю систему не окажут (если, когнечно, ваш проект не завязан по уши на регэкспы).

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

J>>Предлагаешь вернуться к тому нашему долгому обсуждению STL-way?
E>Нет, просто сам хочу понять что же не так в STL. Видимо система ценностей.

E>А абстрагировать алгоритмы -- так кто же против? Только абстрагировать надо очень мало алгоритмов. Ну типа на большой проект может процент наберётся кода, который абстрагированными алгоритмами стоит сделать. И просто в рамках шаблонов C++ можно абстрагировать. STL для этого ненужен. Для этого нужен высококвалифицированный специалист...

E>А ллокатор нужен для того, чтобы о памяти не парится, в случае если освобождение дорогое или если нет исключений.
Получается, если ты хочешь "грохать все" через аллокатор — это оправдано только в случае объектов без осмысленных деструкторов. Иначе нужно у каждого персонально позвать деструктор, а такой вызов должен быть типизированным так или иначе, т.е. вместо аллокатора ты получаешь просто типизированный контейнер.

J>>>>

E>>>А что, от принятия стандарта C++ изменится аппаратура? Или, может быть, ОС?
J>>нет, появятся гарантии, что если ты написал какое-то выражение, то оно выполнится именно так, как ты написал, и ты сможешь это гарантировать безо всяких шаманских плясок, коими радует нас remark (я имею в виду его пост про double lock).

E>Да откуда они появятся?
Из стандарта, откуда же еще.
E>Если сейчас нельзя сделать быстро, то и после стандартизации не будет льзя

E>Мало того, стандартизация обычно мешает использовать преимущества конкретной платформы.
Ничего она не мешает, и не мешала никогда.
Хочешь писать преносимый код — пиши на стандартных фичах. Не хочешь — пиши на местных.
Стандарт же не запрещает какой-нть __int64 на основании того, что есть стандартный int.

J>>Так потому что на каждую задачу требуется свое решение.
J>>Хотя, конечно, есть некоторые тормозные, но безотказные вещи (мьютексы), которые, как самое простое для понимания, вцементированы в некоторые языки в виде слов типа synchronized. Чем не единообразное решение

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

Все эти решения строятся на элементарных фичах. Например, на барьерах, на атомарных типах, на конкретном наборе атомарных операций.
Сейчас ты вынужден каждый раз юзать фичи конкретной системы, что делает твой код непереносимым. А так ты будешь писать просто на плюсах std::atomic<int> i; и делать на нем семафоры или что там тебе понадобилось для твоей конкретной задачи, и это будет абсолютно переносимо (естественно, с точностью до поддержки компилятора).

Потому что сейчас ты даже не можешь гарантированно безопасно прочитать значение переменной (типа if (x==5)), если ты не защитил ее мьютексом.

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

L>Во! Вот это типичная ошибка — считать что контейнеры STL должны быть заменяемы друг на друга лёгким движением руки

ЕМНИП, Герб Саттер, которого я очень уважаю за то что он самый большой практик из всех гуру С++, предлагал забыть об этом принципе сразу и навсегда.
Не помню такого. По крайней мере, когда мы с ним на эту тему разговаривали — ничего он такого не утверждал.

L>ПисАть код который был бы контейнеро-независимым — слишком сложно и в итоге невыгодно экономически в большинстве случаев.

90% (может, и больше) кода, работающего с контейнерами, формулируется в виде "взять все (или только удовлетворяющее некоторому условию) объекты вот отсюда и сделать с каждым то-то".
Именно поэтому почти во всех языках, кроме плюсов (но скоро и в плюсах будет: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html) есть for_each в той или иной форме. Весь такой код никак не зависит от того, в каком контейнере лежат объекты.

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

V>...и я уверен что рождение "новых" программистов тоже не за горами

Не, ну как только, так сразу. Пока что ярые приверженцы STL, ИМХО, неадекватны типичным задачам

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

S>

S>When there are equivalent elements in both source ranges, the elements in the first range precede the elements from the second source range in the destination range. If the source ranges contain duplicates of an element, then the destination range will contain the maximum number of those elements that occur in both source ranges.

S>Судя по-всему эта функция работает так же.

Ну да, в MSDN определено

Короче точно воспроизвести не умею. Зачем -- тоже не знаю.
На крайняк можно написать анологичный алгоритм руками

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

S>Алгоритм set_union не требует отсутствия повторов. (т.е. работает на multi_set)
Тогда понятно.

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

L>auto_ptr тут самописный. Он сам Pop и делает.
ИМХО нехорошо его так называть было...

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

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

J>Я думаю, от библиотеки контейнеров зависят не несколько классов-переходников, независимо от того, кем она написана.
Да. И такая ьиьлиотека своя.

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

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

J>Получается, если ты хочешь "грохать все" через аллокатор — это оправдано только в случае объектов без осмысленных деструкторов. Иначе нужно у каждого персонально позвать деструктор, а такой вызов должен быть типизированным так или иначе, т.е. вместо аллокатора ты получаешь просто типизированный контейнер.
А зачем звать "осмысленные деструкторы" если объекты ни на что внешнее на самом деле не ссылаются? Ну пусть умрут все разом?

J>>>>>

J>Из стандарта, откуда же еще.
А в железе откуда появятся? И что мешает им появиться до стандарта?

J>Хочешь писать преносимый код — пиши на стандартных фичах. Не хочешь — пиши на местных.
J>Стандарт же не запрещает какой-нть __int64 на основании того, что есть стандартный int.
Ну на кой нужен ещё один "вредный" стандарт?

Хорошо, когда стандарт таки позволяет им пользоваться...

E>Я приведу один всего пример. В библиотеках, которые мне нравятся, перекрывают ::new/::delete для того, чтобы всякими хитрыми способами управлять стратегиями аллокации. Это позволяет делать аналог GC некий во многих нужных нам "прожорливых по памяти" алгоритмах, скажем. Ну и вообще это много чего позволяет. Кроме того есть ещё такая метода, что при обработке запроса, ты регишь где-то в запросе все критические ресурсы, а все некритические (например память под локальные на запрос объекты) аллокируешь на специальнйо куче запроса. В случае, если всё гавкнулось, то освобождаешь зарегистрированные критические ресурсы, и грохаешь всю кучу запроса. Восстанавливаешься таким образом.
E>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...

я подумываю о полезности такой стратегии выделения памяти для многопоточных приложений.
часто бывает что в треде вызываются new/delete чтобы аллокировать что-то в куче, несмотря на то что известно что объекты будут использоваться только этим тредом. в таком случаем можно было бы создать thread-local кучу и в ней выделять память под "однопоточные" объекты. для тех же которые должны шариться между потоками, используем глобальную кучу, с локами

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

V>>...и я уверен что рождение "новых" программистов тоже не за горами :)
E>Не, ну как только, так сразу. Пока что ярые приверженцы STL, ИМХО, неадекватны типичным задачам :)

Линуксоид — это не тот, кто использует Linux, а тот, у кого 1000 постов во flame.comp (©)?

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

RO>>Ну вот тебе реальная задача: объединить содержимое двух упорядоченных последовательностей.
E>0) Ты привёл код, который делает не то, что ты просил.

Ладно, ты прав, это я описал std::merge. set_union объединяет множества, представленные упорядоченными последовательностями.

E>1) Это стандартный алгоритм, его таки проектировали, я надеюсь :)

Здесь не понял.

E>2) Мне кажется, что он нужен довольно редко

В этом поверю тебе, твой опыт наверняка превосходит мой.

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

E>4) (И это главное, на самом деле) Это очень абстрактная задача. Реальная задача звучит как-то так: "Рассчитать аэродинамику такого-то самолёта" :)

Ничего, в 2050 г. это будет в STL, а ваша компания напишет велосипед ;-)

E>

RO>>

RO>>EropsMysteriousCompany::ProprietaryContainers::DynamicArray<WeHateTemplates> x, y, z;
RO>>// std::set_union(x.begin(), x.end(), y.begin(), y.end(), std::back_inserter(z));
RO>>как?
RO>>

E>Ну совсем так я не знаю, а если просто выбрасывать повторы, то так:

Я так и думал. У ваших контейнеров есть метод SortedMerge, наверняка есть Sort, Max, Min и т. д. И сколько контейнеров — столько и реализаций, причем далеко не всегда это продиктовано спецификой контейнера (например, std::list имеет свой метод merge, но свои find/max_element/replace и т. д. ему не нужны).

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

Попробую привести еще один пример. Выбрать из большой последовательности 10 наибольших элементов. Предполагается, что программер, который сам написал велосипедное двухфазное слияние, напишет и bicycle::partial_sort? А сколько раз у вас реализован ваш аналог stable_sort?

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

RO>>«Ну чесне слово — як діти». this->ptr = this->next->ptr; oldNext = this->next; this->next = this->next->next; delete oldNext. Заборы расставить по вкусу.

E>Угу.
E>1) Удалил не того
E>2) delete oldNext-то за что? :wow:

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

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

E>>Не, ну как только, так сразу. Пока что ярые приверженцы STL, ИМХО, неадекватны типичным задачам

RO>Линуксоид — это не тот, кто использует Linux, а тот, у кого 1000 постов во flame.comp (©)?
Я на всякий случай уточню.
Пока что, встречающиеся мне в реале, ярые приверженцы STL, ИМХО, неадекватны, встречающимся мне в реале,типичным задачам

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

E>>1) Это стандартный алгоритм, его таки проектировали, я надеюсь

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

E>>4) (И это главное, на самом деле) Это очень абстрактная задача. Реальная задача звучит как-то так: "Рассчитать аэродинамику такого-то самолёта"

RO>Ничего, в 2050 г. это будет в STL, а ваша компания напишет велосипед

Ну еслинаш не стандартизируют

Правда при этом наверняка испортят

E>>

RO>Я так и думал. У ваших контейнеров есть метод SortedMerge, наверняка есть Sort, Max, Min и т. д. И сколько контейнеров — столько и реализаций, причем далеко не всегда это продиктовано спецификой контейнера (например, std::list имеет свой метод merge, но свои find/max_element/replace и т. д. ему не нужны).

Max/Min нет. Есть QuickSort, SortedMerge, BinarySearch, LinearSearch, IsSorted

RO>Т. е., ваша библиотека поощряет дублирование кода, и не позволяет писать универсальные алгоритмы.

Вообще-то есть или нет дублирование кода между реализациями методов BinarySearch -- это всего лишь подробность реализации библиотеки. Сложные алгоритмы, например QuickSearch у нас реализованы так. Есть шаблон класса-механизма, который осуществляет упорядочивание любого массива. А в конкретных реализациях массивов этот шаблон используется от подходящих параметров. Можно сказать, что он представляет собой что-то похожее на абстрактный алгоритм stl, а его параметры представляют что-то типа итераторов с произвольным доступом. Но это всё не возведено в абсолют

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

RO>Попробую привести еще один пример. Выбрать из большой последовательности 10 наибольших элементов. Предполагается, что программер, который сам написал велосипедное двухфазное слияние, напишет и bicycle::partial_sort?
Ну в целом именно так нужно редко. Чаще всего у нас быват другая конструкция. Типа генерируем варианты пока не наберём 10 достаточно хороших, либо пока варианты не закончатся (что малореально). Но в любом случае, считается что да, напишет. Либо отсортирует всё и возмёт первых 10, если это таки понадобится.
RO>А сколько раз у вас реализован ваш аналог stable_sort?
АФАИК нисколько раз не реализован

Он нам скорее всего пока что не был нужен.

Короче смысл в том, что алгоритмы STL (кроме нескольких реально востребованных, которые реализованы и в нашей библиотеке QuickSort, BinarySearch и т. д.) не то чтобы продоставляют вредные сервисы, а просто маловостребованные. Ну типа пользы мало от них довольно. Ну могут они автоматизировать 0.0001% кода, но это совсем непринципиально.

Зато подход с шаблонами и итераторами и обощёнными алгоритмами неизбежно пропитывает почти весь код, то есть приносит 99% вреда

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

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

A>я подумываю о полезности такой стратегии выделения памяти для многопоточных приложений.
A>часто бывает что в треде вызываются new/delete чтобы аллокировать что-то в куче, несмотря на то что известно что объекты будут использоваться только этим тредом. в таком случаем можно было бы создать thread-local кучу и в ней выделять память под "однопоточные" объекты. для тех же которые должны шариться между потоками, используем глобальную кучу, с локами

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

Опять же, если ты всё это сможешь привинтить, то сможешь потом привинтить какую-нибудь ультра-быструю кучу, которая вообще не куча, а просто скоростная выделялка памяти, без возможности вернуть, и использовать её на какие-нибудь алгоритмы, например.

Правда на этом пути ты встретишь трудности с сопротивлением STL этому вопросу. Но они вполне сеюе преодолимы.

L>>auto_ptr тут самописный. Он сам Pop и делает.
E>ИМХО нехорошо его так называть было...
+1. Согласен, но идея и сам код изначально не мой, стырено у одного из гуру Симбиана, а переименовать как-то всё не доходят руки.

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

Как бы так сказать... Мне кажется что в отличие от прикладных программ, которые пишутся для пользователей, операционная система (вариант — библиотека, фреймворк) пишется в бОльшей степени для программиста. Так вот, если даже самая замечательно написанная операционная система будет иметь такой кошмарный API/убогую документацию/багливые средства разработки — то в итоге она программистов от себя отвернёт. А не будет программистов — не будет прикладных программ. А имея бедный набор прикладных программ сдохнет даже самая наилучшая ос. Ведь Windows как ОС — далеко не блестяще написана, но главное её достоинство — это тонны документации + разнообразные средства разработки, которые тоже неплохо документированы. Linux — там может не всё так хорошо с документацией (MSDN-а нету

), но зато сорцы открыты — если что-то надо, разберёшься сам. А вот Symbian — это капец. Очень часто возникают ситуации когда нужно просто плясать с бубном вокруг чтобы понять как это работает или почему не работает. В итоге, мне кажется, что со временем Symbian будет вытеснен Windows CE и embedded Linux-ом.

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

Всё это ИМХО, не претендующее на истину.

... << RSDN@Home 1.2.0 alpha rev. 717>>

J>Не помню такого. По крайней мере, когда мы с ним на эту тему разговаривали — ничего он такого не утверждал.
Лень искать, честно, — к тому же мог действительно ошибаться насчёт авторства... Хотя, по С++ я кроме Саттера страюсь никого не читать

J>90% (может, и больше) кода, работающего с контейнерами, формулируется в виде "взять все (или только удовлетворяющее некоторому условию) объекты вот отсюда и сделать с каждым то-то".
J>Именно поэтому почти во всех языках, кроме плюсов (но скоро и в плюсах будет: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html) есть for_each в той или иной форме. Весь такой код никак не зависит от того, в каком контейнере лежат объекты.

Мы наверное спорим о слегка разных вещах

Всё дальше — личное ИМХО из личного опыта, с отфонарной терминологией и не претендует на истину.
Итак, есть 2 вида кода — обобщённый и решающий конкретные задачи. К примеру, std::sort, std::for_each и т.п. — код обобщённый. А контейнер который содержит все точки по которым проехала машина за день в ПО которое отслеживает её перемещение — это код конкретный. Бывает, что код конкретный мигрирует в код обобщённый — но случается это не очень часто, когда какое-то действие настолько часто встречается в программе что его выносят в библиотеку. Куда чаще обобщённый код изначально пишут "с нуля". Но и в случае миграции из конкретного кода, и в случае написАния "с нуля" код обобщённый пишется всегда по-другому — с более высокими уровнями абстракции, с более тщательным дизайном, пишется максимально универсальным и т.п.

Теперь вернёмся к нашим баранам, то бишь STL

Если я пишу алгоритм вида std::for_every_odd_element (в моём понимании это код "обобщённый") — то естественно я всеми силами постараюсь абстрагироваться насколько это возможно от контейнера в котором лежат элементы, тут взаимозаменяемость контейнеров важна, нужна и экономически оправдана. Если же я пытаюсь сделать так чтобы у меня контейнер который содержит все точки по которым проехала машина за день мог лёгким движением руки из vector стать list — то это какая-то паранойя. Я всё равно этот контейнер выбираю заранее из расчёта конкретных требований к нему, а если требования поменяются в процессе разработки — то мне всё равно прийдётся переписывать огромные куски сопуствующего кода. Вот здесь попытки сделать котейнеронезависимость, ИМХО, только вредят.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

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

ИМХО разработка софта -- не самая дорогая статья в устройствах с этйо ОС. А работает хорошо. Быстро и удобно...

Ну бедет телефон с такой ос на $0.05 дороже из-за того, что разработка дорогая. Ну и что?

L>Всё это ИМХО, не претендующее на истину.

E>ИМХО разработка софта -- не самая дорогая статья в устройствах с этйо ОС. А работает хорошо. Быстро и удобно...
E>Ну бедет телефон с такой ос на $0.05 дороже из-за того, что разработка дорогая. Ну и что?

Я имею в виду third-party софт. Если его будет мало, а для конкурирующих осей — много, то эта ось обречена.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

L>Я имею в виду third-party софт. Если его будет мало, а для конкурирующих осей — много, то эта ось обречена.
Мутный это вопрос.
1) ИМХО в телефонах third-party сильно не главное
2) Обычно производители софта ориентируются не на стоимость разработки, а на инсталляцилнную базу. В конце концов привинтить более С++ строчки поверх этих не так уж и дорого

L>>Я имею в виду third-party софт. Если его будет мало, а для конкурирующих осей — много, то эта ось обречена.
E>Мутный это вопрос.
E>1) ИМХО в телефонах third-party сильно не главное
Symbian — это смартфоны. Раз уж человек переплачивает полторы-две сотни баксов, он желает видеть что он за них получит. А преимущества смартов перед обычными телефонами — это как раз возможность ставить third-party софт.

E>2) Обычно производители софта ориентируются не на стоимость разработки, а на инсталляцилнную базу. В конце концов привинтить более С++ строчки поверх этих не так уж и дорого

Строчки эт только пример

Там кроме этого хватает граблей

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

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

L>Строчки эт только пример

Там кроме этого хватает граблей

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

Ну так база -- это же обороты

Если таких телефонов много, то для них легко продавать прогу, значит её можно разработать за подороже и всё равно остаться в плюсах

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

L>Итак, есть 2 вида кода — обобщённый и решающий конкретные задачи. К примеру, std::sort, std::for_each и т.п. — код обобщённый. А контейнер который содержит все точки по которым проехала машина за день в ПО которое отслеживает её перемещение — это код конкретный.
L>Вот здесь попытки сделать котейнеронезависимость, ИМХО, только вредят.
ИМХО всё ещё хуже

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

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

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

L>>Итак, есть 2 вида кода — обобщённый и решающий конкретные задачи. К примеру, std::sort, std::for_each и т.п. — код обобщённый. А контейнер который содержит все точки по которым проехала машина за день в ПО которое отслеживает её перемещение — это код конкретный.
L>>Вот здесь попытки сделать котейнеронезависимость, ИМХО, только вредят.
E>ИМХО всё ещё хуже

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

Ну так необходимости рефакторинга никто не отменял. Иначе любой код превратится в тихий ужас

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

J>Ну так необходимости рефакторинга никто не отменял. Иначе любой код превратится в тихий ужас
Ну так разный код деградирует с разной скоростью и в разной степени нуждается в рефакторинге...

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

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

E>Полезная идея ровно противоположенная: "Контейнеры и алгоритмы надо выбирать вдумчиво, ещё на стадии проектирования. А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации" :)

Что изменится в худшую сторону, если, например, функцию inline f(char *, size_t) заменить на template f(BidirectionalIterator, BidirectionalIterator)? А в лучшую — много что.

Другое дело, что можно написать, например, версию алгоритма для Random Access Iterator, но повременить с версией для Bidirectional Iterator. Тем не менее, такая структура допускает беспроблемное расширение, и не нужно сложного проектирования.

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

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

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

E>>Полезная идея ровно противоположенная: "Контейнеры и алгоритмы надо выбирать вдумчиво, ещё на стадии проектирования. А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации"

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

RO>Что изменится в худшую сторону, если, например, функцию inline f(char *, size_t) заменить на template f(BidirectionalIterator, BidirectionalIterator)? А в лучшую — много что.

Ну интересно что изменится в лучшую и почему.Положим функция f( char* size_t ) проверяет по словарю наличие такого английского слова. Итак, что нам даст в этйо функции переход к итераторам? В частности интересно бы узнать, где брать словари универсального формата...

RO>...и не нужно сложного проектирования.
Вот это-то и есть корень зла. Там не нужно проектирования, сям. А в результате неподдерживаемый мегаурод выходит. Пошевилишь такой "обобщённый код" и никогда больше не отладишь

RO>Кроме того, у обобщенного проектирования с итераторами есть еще одно преимущество: даже если ограничиваться одним типом контейнеров, можно легко задавать подпоследовательности, что далеко не всегда свойственно другим подходам.
Это конечно очень, очень, очень нужная фича. Абсолютно вообще всегда.
Если вернуться к примеру с функцией f( char*, size_t ), которая проверяет по словарю английские слова, то конечно
1) Проверить, что чётные буквы строки являются английским словм -- это очень ценная и важная возможность.
2) Если уж припечёт, конкретно в этом случае всё легко решается порождением новой строки, например.

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

E>>>Полезная идея ровно противоположенная: "Контейнеры и алгоритмы надо выбирать вдумчиво, ещё на стадии проектирования. А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации" :)

E>Ну я так тебя понял, что с закавыченным утверждением ты не согласен? :)

С первой частью согласен. Со второй частью не согласен.

E>

RO>>Что изменится в худшую сторону, если, например, функцию inline f(char *, size_t) заменить на template f(BidirectionalIterator, BidirectionalIterator)? А в лучшую — много что.

E>Ну интересно что изменится в лучшую и почему.Положим функция f( char* size_t ) проверяет по словарю наличие такого английского слова. Итак, что нам даст в этйо функции переход к итераторам? В частности интересно бы узнать, где брать словари универсального формата...

А причем здесь универсальный формат? Например, словарь живет в плоском текстовом файле. Или его уже загрузили в упорядоченный массив или дерево. Какая разница, char * или Iterator?

RO>>...и не нужно сложного проектирования.
E>Вот это-то и есть корень зла. Там не нужно проектирования, сям. А в результате неподдерживаемый мегаурод выходит. Пошевилишь такой "обобщённый код" и
никогда больше не отладишь :(

Тогда и hello world проектировать надо? Везде надо меру знать.

RO>>Кроме того, у обобщенного проектирования с итераторами есть еще одно преимущество: даже если ограничиваться одним типом контейнеров, можно легко задавать подпоследовательности, что далеко не всегда свойственно другим подходам.
E>Это конечно очень, очень, очень нужная фича. Абсолютно вообще всегда.
E>Если вернуться к примеру с функцией f( char*, size_t ), которая проверяет по словарю английские слова, то конечно
E>1) Проверить, что чётные буквы строки являются английским словм -- это очень ценная и важная возможность.
E>2) Если уж припечёт, конкретно в этом случае всё легко решается порождением новой строки, например.

А как насчет проверки того, что подстрока между N-ным и N+1-м пробелом входит в словарь? Кстати, f(char*, size_t) с этим тоже справится. А f(SomeContainer const &) — нет.

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

E>>>>"...А обобщённые алгоритмы писать только при реальной нужде них, и приналичии явного и высококачественного проектирования и подробной сопроводительной документации"

RO>...Со второй частью не согласен.

ТО есть тебе кажется, что шаблонные обощённые функции проектировать не надо? И документировать тоже?
Ну собственно я про тоже самое, что "использование STL провоцирует порождение кучи обобщённого кода, который никто никогда не проектировал, как обобщённый".

Беда-то не в том, что итератор так же хорошо, как const char*, а в том, что в обощённом случае семантика у функции может оказаться неожиданной, или может оказаться, что реализовать какой-то варинат непросто, а так, как реализовать просто неправильно.
Функции-то проектируют не для того, чтобы интерфейс им написать какой-то, а для того, чтобы они улучшали код

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

E>>Ну интересно что изменится в лучшую и почему.Положим функция f( char* size_t ) проверяет по словарю наличие такого английского слова. Итак, что нам даст в этйо функции переход к итераторам? В частности интересно бы узнать, где брать словари универсального формата...

RO>А причем здесь универсальный формат? Например, словарь живет в плоском текстовом файле. Или его уже загрузили в упорядоченный массив или дерево.
Ну словарь где-то надо брать, вообще-то... Он же не может материализоваться из шаблонных конструкций

RO>Какая разница, char * или Iterator?
Ну разница простая, char* намного конкретнее. НИкто не подсунет вместо Iterator какую-нибудь неожиданную хреновину. Но в целом я так и не понял чем лучше и почему... Чем хуже я и так знаю

RO>Тогда и hello world проектировать надо? Везде надо меру знать.
Ну от архитектуры зависит. Но обычно hello world программировтаь не надо, так как это как раз алгоритм, предназанчный для выполнения конкретных действий.
А вот если у тебя hello world будет метапрограммой. То есть будет порождать программы для разных обстоятельств (например для 100 разных ОС), то проектироватьочень даже стОит

RO>А как насчет проверки того, что подстрока между N-ным и N+1-м пробелом входит в словарь? Кстати, f(char*, size_t) с этим тоже справится. А f(SomeContainer const &) — нет.
1) Ты сам ответил.

Проектирование таки рулит намного больше итераторов.
2) ИМХО в этой задаче не жалко копировать строку, если это от чего-то удобно...

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

R>Здравствуйте, Roman Odaisky, Вы писали:

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

R>Имхо, тут двухсвязный список — то, что доктор прописал.
тут еще одна возможность появляется. Если смарт поинтеры в список связаны, то можно иенять сам обьект на ходу, если пройтись по списку

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

R>>Имхо, тут двухсвязный список — то, что доктор прописал.
P>тут еще одна возможность появляется. Если смарт поинтеры в список связаны, то можно иенять сам обьект на ходу, если пройтись по списку

ИМХО еси есть такая нужда, то дешевле таки иметь какие-то прокси-объекты...

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

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

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

E>Это помогает под виндой.
E>Под Linux'ом загрузчик запросто может прилинковать потроха SO к потрохам хоста.

Если so правильно приготовить, то не сможет. Надо эти символы просто повырезать во время линковки so-шки, а как это уже особенности конкретного линковшика.

P>>тут еще одна возможность появляется. Если смарт поинтеры в список связаны, то можно иенять сам обьект на ходу, если пройтись по списку
E>ИМХО еси есть такая нужда, то дешевле таки иметь какие-то прокси-объекты...

Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

L>Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.

Если указателей мало, то не жалко лишнего new

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

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

L>>Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.

E>Если указателей мало, то не жалко лишнего new

Не путай указатели вообще и указатели на конкретный объект

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

R>Не путай указатели вообще и указатели на конкретный объект

Ну я так понимаю, что временем жизни указуемого объекта мы не управляем, так что выбора особого нет

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

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

R>>Не путай указатели вообще и указатели на конкретный объект

E>Ну я так понимаю, что временем жизни указуемого объекта мы не управляем, так что выбора особого нет

При чём тут время жизни указываемого объекта?

L>>Не факт что дешевле. Если указателей мало (а такой случай довольно часто встречается) — то не надо где-то хранить прокси-обьект, избавляемся от одного new.
E>Если указателей мало, то не жалко лишнего new

Я говорю о ситуации когда обьектов много, но на каждый из них всего 1-2-3 указателя. Тогда linked_ptr будет выгоднее shared_ptr — не нужно будет лишнего new (для обьекта-прокси) на КАЖДЫЙ выделенный "реальный" обьект. Мне кажется что это будет быстрее чем даже в случае самого оптимизированного аллокатора для проксей.
Кстати, для такой ситуации наверняка односвязный циклический список (вместо двусвязного) для linked_ptr будет идеей, достойной рассмотрения.

... << RSDN@Home 1.2.0 alpha rev. 717>>

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

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

John Robbins в книге Debugging Applications for Microsoft .NET and Microsoft Windows рекомендовал не использовать STL. Хотелось бы надеяться, что в новом издании он эту рекомендацию убрал; но пока-что если заказчик сошлется на Роббинса, отвечать ему в духе "а jazzer сказал, что это глупость" не очень перспективно. И обрати внимание, Роббинс говорил про STL, а boost и хочешь использовать, и разрешение имеется, а как получишь пару сотен ворнингов при его сборке, так ... слов нет, одни буквы.

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

A>>Это я знаю, но boost не входит в стандарт. Плюс не во всех конторах разрешено его использовать.

А>Ну что я могу сказать...
А>Ждите, когда появится рабочий компилятор C++0x

А>А сейчас вы умными указателями вообще не пользуетесь?

Да я же не про себя писал.
Есть конторы, где даже наследование стараются не использовать.
Умные указатели — очень удобная вещь, которая позволяет использовать некоторые преимущества С++ (автоматический вызов деструктора при выходе из области видимости). Имхо лучше неоправдано использовать умный указатель, чем не использовать вообще, т.к. в большинстве случаев наличие этих указателей сильно повысит надёжность программ. Естественно, извратиться всегда можно, но сделать это уже сложнее, чем с голыми указателями.
Если какой-нибудь смарт-поинтер будет в стандарте (auto_ptr не считаю), то это должно увеличить их использование. Соответственно немного, но улучшится качество программ.
Представьте ситуацию — приходит программист в небольшую фирму, видит, что в проекте используются обычные указатели и говорит менеджеру, что не плохо бы использовать например boost::shared_ptr. Надо — подключить новую библиотеку, обучить всех сотрудников работать с ней, потратить некоторое количество времени только на сбор буста, что в первый раз наверняка вызовет сложности, затем тратить время на переписывание существующего кода и рисковать, что не будут внесены новые "особенности" программы. А заказчики ведь не ждут, и для мелкой фирмы это может быть критично.
Конечно не обязательно переписывать весь код, даже компилировать буст для использования указателей не надо, но как минимум остаётся риск некомпетентного использования нового инструмента.
А в случае стандарта — этот программист просто берёт и пишет так как ему нравится. Если к его коду не будет претензий — возьмётся за чужой, где также может постепенно вводить указатели там, где посчитает нужным.

Здесь на форуме часто проскакивает, что stl вредно использовать, что уж говорить про отдельную библиотеку.

	От:	alzt
	Дата:	22.08.07 10:56
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	22.08.07 11:56
Оценка:

	От:	Аноним
	Дата:	22.08.07 13:19
	Оценка:

	От:	Erop
	Дата:	22.08.07 13:46
	Оценка:	1 (1)

	От:	Erop
	Дата:	22.08.07 13:47
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	22.08.07 16:55
Оценка:	+1

	От:	Cyberax
	Дата:	22.08.07 23:00
	Оценка:	1 (1) +1

От:	remark	http://www.1024cores.net/
Дата:	23.08.07 05:14
Оценка:	1 (1) +2

От:	Андрей Коростелев	http://www.korostelev.net/
Дата:	23.08.07 06:33
Оценка:	8 (1)

	От:	Roman Odaisky
	Дата:	23.08.07 07:10
	Оценка:	1 (1) +1

	От:	Константин Л.
	Дата:	23.08.07 09:15
	Оценка:

	От:	Alex Alexandrov
	Дата:	23.08.07 17:54
	Оценка:

От:	johny5	https://www.facebook.com/TachyonWars/
Дата:	24.08.07 00:09
Оценка:	+1

От:	hVostt	http://hvostt.ru
Дата:	24.08.07 09:31
Оценка:	+1

От:	dr.Chaos	Украшения HandMade
Дата:	19.09.07 12:45
Оценка: