Здравствуйте, 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 просто позволяет обнаруживать умирание объекта. Просто указатели в принципе не могут.

Erop wrote:

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

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

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

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

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

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

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

Erop wrote:

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

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

Erop wrote:

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

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

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

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

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

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

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

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



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

Не, я в 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];
}

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

Здравствуйте, 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 работал.
По-хорошему, конечно, нужно было сделать

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

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

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

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

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

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

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

Здравствуйте, 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&gt;

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

> .>Я так и не понял что он не позволяет. Всё он позволяет, особенно в купе с 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, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.

> Просто хочу объяснить, что возможна точка зрения, согласно которой 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 отвечает, что это слишком для него сложно, то и отношение к нему соответствующее.