Вышел Boost 1.35

даже страуструп уже пишет статьи про то, что надо бы сделать в С++ multimethods, которые уже давно существуют в Common Lisp

она реализует и lisp & scheme, а вот clos'а там как раз и нету

> multimethods, которые уже давно существуют в Common Lisp

И не только в CLOS, идея старая. Назвать это "стонами о CLOS" я бы не решился.

> она реализует и lisp & scheme, а вот clos'а там как раз и нету

Ну так чего ради ее привели в разговоре о CLOS? 8)

я не знаю зачем ее привели в качестве примера

>Видимо, аккуратные девелоперы программируют только в тех областях, где можно программировать аккуратно без приведения типов =))))))

Либо программируют с использованием средств, позволяющих делать аккуратное приведение типов ;)

> Либо программируют с использованием средств, позволяющих делать аккуратное приведение типов ;)

Например?

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

Давайте рассмотрим в первую очередь именно аспект вычислений, а не распределённости :) Очевидно, что для научных работников самым лучшим вариантом будет, если их любимому матлабу или максиме можно будет просто сказать сетевые адреса машин, на которых можно работать, а все программистские нудности типа транзакции, прокси-скелетоны, распределённая сборка мусора и т.п. останутся на совести разработчикам этих матлабов и максим. Главное - не учить никакой новый (специализированный!) язык, в котором элементарного Фурье нет в стандартной библиотеке. Или в котором, о, боги, есть такой п...ц, как boost::mpl, на котором предлагают сделать систему физических измерений ;)

QueryInterface, boost::variant, boost::any

> Главное - не учить никакой новый (специализированный!) язык, в
> котором элементарного Фурье нет в стандартной библиотеке. Или в
> котором, о, боги, есть такой п...ц, как boost::mpl, на котором
> предлагают сделать систему физических измерений ;)

+1.

>Использование собственных аллокаторов в приложении не спасает отца русской демократии?

Да, садишься за код и начинаешь городить инфраструктуру проекта. Через неделю обнаруживаешь что в плане собственно функционала еще и конь не валялся. Еще через неделю плюешь, сносишь все и пишешь тупо через виртуальные функции и downcasting. Правда с некоторых пор я начал сразу писать на C89 - кариеса меньше.

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

Я тупо открыл <memory> в c++ lib и обнаружил что там operator new реализован тупо через malloc().

>А вы посмотрите на ACE_Refcounted_Auto_Ptr и макрос ACE_SYNCH_MUTEX для случая, когда приложение компилируется под однопоточный режим. Опять же ACE_Refcounter_Auto_Ptr построен на C++ных шаблонах.

Проще удалять в том же *.c файле в котором происходит выделение. И не иметь ликов из-за отсутствия исключений. Вообще, неплохо бы SEH из винды перетащить.

>> начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали.

>То, что ты в разговоре о "auto_ptr/shared_ptr" жалуешься исключительно на счетчик ссылок и фрагментацю, показательно.

Что показательно? Все эти косяки "интеллектуальных указателей" начинают проявляться когда проект уже большой и превратился в помойку. На proof-of-concept'ах килобайт по сорок все работает замечательно.

> Что показательно? Все эти косяки "интеллектуальных указателей" начинают проявляться когда проект уже большой и превратился в помойку.

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

О каких косяках ты постоянно говоришь?
Чем не устраивает Loki::SmartPtr?
Или бог запрещает определить BOOST_SP_USE_QUICK_ALLOCATOR?
Если "косяки" представляют из себя прогиб перформанса на "большых проектах" из-за boost::shared_ptr можешь не отвечать, диагноз ясен.

>>То, что ты в разговоре о "auto_ptr/shared_ptr" жалуешься исключительно на счетчик ссылок и фрагментацю, показательно.

>Что показательно?

auto_ptr не использует счетчик ссылок и не ведет к фрагментации - он практически всегда на стеке. Насчет фрагментации от мелких shared_ptr - тоже сомнительно. Всё смешано в одну кучу.

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

Вот именно - когда _уже_ превратился. Не из-за смарпойнтеров же он в нее превратился.

>Чем не устраивает Loki::SmartPtr?

Хорошая кстати вещь. 2 my mind лучшая имплементация. Но тут та же ситуация что и со стрингами - std::string vs std::wstring vs Bicycle1::TMyCoolString Bicycle2::TVasyaPupkinCoolString.

>Если "косяки" представляют из себя прогиб перформанса на "большых проектах" из-за boost::shared_ptr можешь не отвечать, диагноз ясен.

Косяки в том, что как на Си++ не пиши, получается говно. Поэтому лучше не комплексовать и делать говно изначально.

>auto_ptr не использует счетчик ссылок и не ведет к фрагментации - он практически всегда на стеке.

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

Свой аллокатор пишется во-первых тогда, когда это даст выгоду (а это в 90% проектов не надо, т.к. botteneck-и не там), во-вторых аллокатор, абсолютно не фрагментируемый на фиксированные размеры (а особенно sizeof(void*)) пишется за считанные часы. Проблемы не там ищете.

>>Чем не устраивает Loki::SmartPtr?
> тут та же ситуация что и со стрингами - std::string vs std::wstring
и какая же тут ситуация???

> Косяки в том, что как на Си++ не пиши, получается говно.
Это не проблема смартпойнтеров. Решается заменой говнодела на девелопера.
> Поэтому лучше не комплексовать и делать говно изначально.
Это сразу всё проясняет. Психология непрофессионала.

> Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять.
О чём ещё можно говорить после такого высказывания?

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

Естесно, там, где он применим.

> Чтобы auto_ptr передать кому-то надо объект клонировать

ыы

Британские учёные впервые передали auto_ptr овечке Долли.

>> Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять.

>О чём ещё можно говорить после такого высказывания?

Кончаем трепологию

class Foo {
std::auto_ptr<Bar> _bar;
public:
...
std::auto_ptr<Bar> getBar() {
return std::auto_ptr<Bar>(_bar->clone());
}
...
};

>> Косяки в том, что как на Си++ не пиши, получается говно.

>Это не проблема смартпойнтеров. Решается заменой говнодела на девелопера.

Под С++ девелоперов не существует. Только говноделы.

>> Поэтому лучше не комплексовать и делать говно изначально.

>Это сразу всё проясняет. Психология непрофессионала.

О блин. Психолахи на ЛОР.

> Чтобы auto_ptr передать кому-то надо объект клонировать если не хочешь его потерять.

std::auto_ptr<Foo> MakeFoo()
{
return std::auto_ptr<Foo>(new Foo());
}

...
std::auto_ptr<Foo> p = MakeFoo();
p->Bar();
...
Вот тебе передача объекта _без_ клонирования и _без_ потери объекта.

> Кончаем трепологию
Кончай смешить людей.

> Под С++ девелоперов не существует. Только говноделы.

Так и напрашивается подпись "Миша, 16 лет".

s/говноделы/мазохисты/

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

>std::auto_ptr<Foo> MakeFoo()
>{
>return std::auto_ptr<Foo>(new Foo());
>}

>Вот тебе передача объекта _без_ клонирования и _без_ потери объекта.

Это неэквивалентный пример. Да и нахрен тут auto_ptr?

Почему не

Foo* foo;
try {
foo = makeFoo();
foo->bar();
...
} finally {
pFoo = null;
}

А наверно потому что Страус такой же даун.

> но оно будет заведомо производительней аналогичного на LISP'е. или нет ?

Или нет. Лисп ничуть не тормознее Си, а при определённой сноровке - и заметно шустрее.

>> Под С++ девелоперов не существует. Только говноделы.

>Так и напрашивается подпись "Миша, 16 лет".

Иди KDE4 разглючивай. Миши 16 лет наваяли, теперь надо доводить.

>Foo* foo;
>try {
>foo = makeFoo();
>foo->bar();
>...
>} finally {
>pFoo = null;
>}

Это на каком языке? O_o

>>Foo* foo; >>try { >>foo = makeFoo(); >>foo->bar(); >>... >>} finally { >>pFoo = null; >>}

>Это на каком языке? O_o

На C++ если бы Страус был вменяем.

UPD: в finally блоке переменная конечно называется не pFoo а foo.

>> Это на каком языке? O_o

> На C++ если бы Страус был вменяем.

Ну-ну. Это был бы такой Си++ со сборкой мусора, finally и null вместо NULL? Ты мог бы просто сказать, что написал на смеси Си++ и Явы, но надо же обязательно пнуть Страуструпа, иначе никрута.

Малыш, у меня нет цели унизить тебя.
Своими постами ты обдристал себя сам по самые помидоры и без моего участия.
Если тебя интересует мера твоего незнания c++, я могу помочь тебе её раскрыть. Если же в тебе просто клокочет подростковая моча, прости, мне это неинтересно. Играй в эту игру со своими сверстниками.

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

> Да и нахрен тут auto_ptr?
А воображение включить?

Bar::Bar()
: m_foo(makeFoo())
{
...
}

>class Foo {
>std::auto_ptr<Bar> _bar;
>public:
>...
>std::auto_ptr<Bar> getBar() {

Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

>Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

Имеет место передача владения. Если возвращаешь auto_ptr<Bar> то одназначно даешь клиенту кода понять что он - владелец того инстанса который возвращает метод getBar(). Он может его отсоединить от auto_ptr и присоединить к shared_ptr. Или вручную с ним работать. Если возвращаешь Bar* то клиенту кода не понатно, что дальше с этим указателем делать - удалять его или нет.

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

Бл*дь, 1) У меня есть memeber field "_bar" охраняемый auto_ptr. 2) Мне надо клиенту кода дать к нему доступ. Ссылки auto_ptr не считает, значит чтобы передать _bar наружу надо сделать clone().

>>Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

>Имеет место передача владения.

Ага, то есть о модели владения вы знаете. Тогда скажите, как вы будете реализовывать эту модель владения в C?

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

PS: Оставь телефончик, ты из Питера как я погляжу. Надо поговорить.

>> Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

> Имеет место передача владения.

Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

> o_O Чего-то я в жизни не понимаю.

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

>>> Зачем здесь getBar возвращает auto_ptr<Bar>? Почему не Bar *?

>> Имеет место передача владения.

>Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

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

>> o_O Чего-то я в жизни не понимаю.

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

А я... а я... а я на Питоне умею, вот!

>>Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

>Владения копией.

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

>>> o_O Чего-то я в жизни не понимаю.

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

>А я... а я... а я на Питоне умею, вот!

Поздно каешься, грешник! :)

>>>Передача _клиенту_ владения указателем на закрытый член класса? o_O Чего-то я в жизни не понимаю.

>>Владения копией.

>Если и надо передавать клиенту именно _копию_ - то какие претензии к auto_ptr? Не говоря о том, что копию клиенту можно передать как голый указатель - если ему надо, пусть обернет ее в auto_ptr или что-нибудь другое.

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

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