Вышел Boost 1.35

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

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

>Если и надо передавать клиенту именно _копию_ - то какие претензии к auto_ptr?

Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.

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

Нет, в стандартном C++ попрждающий метод должен возвращать auto_ptr.

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

Ладно, пусть. Но ставить необходимость клонирования в getBar в вину auto_ptr - это просто ни в какие ворота.

> в стандартном C++ попрждающий метод должен возвращать auto_ptr.

Это сильно зависит от того, что именно называть "стандартным Си++"

>>Если и надо передавать клиенту именно _копию_ - то какие претензии к auto_ptr?

>Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.

Афигеть!

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

>Нет, в стандартном C++ попрждающий метод должен возвращать auto_ptr.

А в каком месте стандарта C++ это утверждается?

И что, разработчики Boost-а, ACE, Qt, Poco, STLSoft, а так же все их пользователи являются злостными нарушителями стандарта C++, когда они создают и используют вещи типа boost::shared_ptr, ACE_Refcounted_Auto_Ptr, Poco::AutoPtr и т.д.?

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

>Ладно, пусть. Но ставить необходимость клонирования в getBar в вину auto_ptr - это просто ни в какие ворота.

Это точно.

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

То, что ты говоришь сейчас
> 1) У меня есть memeber field "_bar" охраняемый auto_ptr. 2) Мне надо клиенту кода дать к нему доступ.
Некислая разница, не находишь?

> Если возвращаешь Bar* то клиенту кода не понатно, что дальше с этим указателем делать - удалять его или нет.
Если код на с++ вариантов быть не может. Удалять не надо никогда.
При передаче/разделении владения, возвращаться должен смартпойнтер.

Bar& GetBar()
{
return *m_bar;
}

Bar GetBar() const
{
return *m_bar;
}

На выбор. Какие проблемы?

Говори, раз надо.

+1

>> в стандартном C++ попрждающий метод должен возвращать auto_ptr.

>Это сильно зависит от того, что именно называть "стандартным Си++"

Вот это в Ц++ и раздражает больше всего - куча трактатов как правильно писать. Как правильно реализовать operator=? Через идиому swap + temp object. Какой ньанс есть в перегруженных operator-ах типа operator+() ? Возвращать надо по значению. Какой ньанс есть в перегруженных operator-ах типа operator<() ? Они должны быть const-методами чтобы const-aware алгоритмы из stl не переглючило с четерехкилобайтным отчетом об ошибке компиляции. Какой ньюанс есть в auto_ptr? Он не обладает семантикой значений. Как надо копировать объекты с семантикой значений? Через конструктор копирования. Как надо копировать полиморфные объекты? С помощью клонирования. Как избежать забывания перегрузки виртуального метода clone() в производном классе? С помощью помещения виртуального метода doClone() в protected-секцию класса и вывода в public секцию неперегружаемого метода clone() который вызывает виртуальную функцию doClone() и сравнивает типы через RTTI, вызывая Assertion Error при несовпадении.

Etc весь двухтомник Мейрса, двухтомник Саттера, обоюдный высер Саттер + Александресу. Причем рекоммендации все время меняются с критикой в пух и прах предыдущих рекоммендаций. Похоже на советскую традицию нагружать школьников всякой херней типа "переведи 1 Кг из системы Си в систему СГС" с каким-нибудь подвохом. Олимпиады выигрывали всякие аутические индивиды, которые однако в реальном производстве были беспомощными.

> Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.
Очень странная самоцель. Разумное объяснение существует?

> Нет, в стандартном C++ попрждающий метод должен возвращать auto_ptr.
Это ещё что за новости??
Возврат по стеку или любого другого смартпойнтера компилятор не скомпилирует?

> это в Ц++ и раздражает больше всего - куча трактатов как правильно писать. Как [...] Какой [...]

Ну да, всё так. Си++ - сложный (переусложненный) язык, с этим кто-то спорит? Но речь шла об auto_ptr и shared_ptr.

А то, о чем ты говоришь, достаточно логично, если знать о том, как всё реализуется. Пойми это, и не надо будет зубрить частности (если тебе это еще нужно, конечно).

> в реальном производстве

Такое впечатление, что ты выгорел на каком-то запущенном Си++-проекте.

P.S. "нюанс", без "ь".

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

зыж >10 лет занимаясь программированием профессионально (и системным, и прикладным) как-то не заметил ни одной области, в которой C++ был бы адекватным выбором. конечно, если разработчики знают ещё что-то, а не только C++.

>зыж >10 лет занимаясь программированием профессионально (и системным, и прикладным) как-то не заметил ни одной области, в которой C++ был бы адекватным выбором. конечно, если разработчики знают ещё что-то, а не только C++.

Вам просто повезло.

PS. C++ далеко не идеальный язык и я бы с удовольствием сменил бы его на что-нибудь более удобное, но временами конкурентов у него действительно нет.

> Как правильно реализовать operator=? Через идиому swap + temp object.
Далеко не всегда, но такой приём есть. Можно посчитать за нюанс.

> Какой ньанс есть в перегруженных operator-ах типа operator+()? Возвращать надо по значению.
Это не нюанс, это основы языка. Если ты про оператор сложения, то непонятно как ещё, кроме как по значению? Если ты про постинкремент, то это снова не нюанс, а сама его суть.

> Какой ньанс есть в перегруженных operator-ах типа operator<() ? Они должны быть const-методами чтобы const-aware алгоритмы из stl не переглючило с четерехкилобайтным отчетом об ошибке компиляции.
Это не нюанс, это основы языка. Методы не меняющие состояния объекта должны быть объявлены как константные.
> Какой ньюанс есть в auto_ptr? Он не обладает семантикой значений.
А должен? _Таких_ нюансов море - навскидку, он ещё парсить регэкспы не умеет.
> Как надо копировать объекты с семантикой значений? Через конструктор копирования. Как надо копировать полиморфные объекты? С помощью клонирования.
Это тоже основы языка. Что тебя тут удивляет? Невозможность создать копию объекта неизвестного класса?
> Как избежать забывания перегрузки виртуального метода clone() в производном классе?
[бред поскипан]
Надеюсь, это завуалированный первоапрельский розыгрыш?
Если нет, то ататат и смотреть в сторону чисто виртуальных функций.

Мда... А ведь это азы. Что уж тогда говорить о нюансах.

> дети часто удивляются, отчего [...]

Да, дети многого не понимают - на то они и дети.

> как-то не заметил ни одной области, в которой C++ был бы адекватным выбором. конечно, если разработчики знают ещё что-то, а не только C++.

А ты знаешь Си++?

> 10 лет занимаясь программированием профессионально (и системным, и прикладным) как-то не заметил ни одной области, в которой C++ был бы адекватным выбором.
"А я голой жопой ежей давил".

>Какой ньанс есть в перегруженных operator-ах типа operator<() ? Они должны быть const-методами чтобы const-aware алгоритмы из stl не переглючило с четерехкилобайтным отчетом об ошибке компиляции.

Какой нахрен "нюанс"?! Такие методы должны быть const просто by design! Только не говори мне, что ты объявляешь методы как const только когда что-то явно требует этого (как в приведённом тобой случае).... =\

бедняга. ничего, заживёт.

нет, мы всё больше на gw-basic…

>Вам просто повезло.

возможно.

>но временами конкурентов у него действительно нет.

честно говоря, вижу только одно условие для этого: передали нечто, уже написаное на C++, которое надо поддерживать и развивать.

о, нет, наврал. ещё есть: идиот-заказчик оговаривает в ТЗ конкретный язык, а не функциональность.

>>но временами конкурентов у него действительно нет.

>честно говоря, вижу только одно условие для этого: передали нечто, уже написаное на C++, которое надо поддерживать и развивать.

>о, нет, наврал. ещё есть: идиот-заказчик оговаривает в ТЗ конкретный язык, а не функциональность.

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

А, например, софт для вот такого дизеля -- http://www.research.att.com/~bs/abstraction-and-machine.pdf -- вы бы на чем делали? На plain C?

Не завидуй, тебя, может, тоже вылечат.

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

тут что-то одно лишнее, имо. впрочем, Oberon прекрасно справится.

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

вот как раз в таких условиях первым же решением было слить C++ в помойку.

>А, например, софт для вот такого дизеля — http://www.research.att.com/~bs/abstraction-and-machine.pdf — вы бы на чем делали? На plain C?

на Oberon-2. возможно, с допиливаниями в виде UNTAGED POINTERS и C как back-end'ом.

> Oberon прекрасно справится.

O_O ты не Irsi часом?

>>А, например, софт для вот такого дизеля — http://www.research.att.com/~bs/abstraction-and-machine.pdf
>> вы бы на чем делали? На plain C? 

>на Oberon-2. возможно, с допиливаниями в виде UNTAGED POINTERS и C как back-end'ом.

И получили бы такую же производительность, как в C++?

А как на счет реализации арифметики, которую в C++ реализации сделали на шаблонах?
В Oberon-е бы все ручками делали? Вроде:

sl := FixPoint16.Mul(UnsigRelSpeed,FuelIndex);
IntLoad := FixPoint16.Mul(sl,
  FixPoint16.Add(PointSevenFive,
    FixPoint16.Mul(sl,
      FixPoint16.Sub(PointFiveFour,
        FixPoint16.Mul(PointTwoSeven,sl)
      )
    )
  )
) ...

>> Как избежать забывания перегрузки виртуального метода clone() в производном классе?

>[бред поскипан] Надеюсь, это завуалированный первоапрельский розыгрыш? Если нет, то ататат и смотреть в сторону чисто виртуальных функций.

Base : public Cloneable<Base> -> Derived1 -> Derived2

Если в Derived2 забыли перегрузить clone(), то при клонировании Derived2 будет вызываться clone() от Derived1, который будет возвращать инстанс Derived1. Читать вообще умеешь?

Самый узкий ботлнек в голове разработчика.

>> Передача копии - это способ оставаться в рамках std, то есть std::auto_ptr и не цепляться к бусту.

>Очень странная самоцель. Разумное объяснение существует?

Было впадлу собирать буст под MSVC 6. Так все проекты и выросли из MSVC 4-5-6 без супа-пупа-дупа фичей стандартного С++. В мире GNU если было и лучше, то ненамного. Торвальдсу вон g++ нехватило. Может оно и к лучшему.

>> Нет, в стандартном C++ порождающий метод должен возвращать auto_ptr.

>Это ещё что за новости??

Я сказал.

> Base : public Cloneable<Base> -> Derived1 -> Derived2
> Читать вообще умеешь?
Ну провафлил, бывает. Под впечатлением от предыдущих "нюансов", не иначе.
По существу сходу ничего не скажу, никогда не сталкивался с необходимостью в Clone.
Итого: два "нюанса" из пяти - не бред. Всё равно показательно.

> Было впадлу собирать буст под MSVC 6
Что само по себе напрашивается на аплодисменты.
Loki собирать тоже было впадлу?
В конце концов всегда есть возможность завести свой велосипед (любой степени заимствования).
Если, конечно, не впадлу.

>>> Нет, в стандартном C++ порождающий метод должен возвращать auto_ptr.
>> Это ещё что за новости??
> Я сказал.
"Поздравляю вас, гражданин, соврамши"

какая из букв в слове mirage нечитабельна? O_o

> какая из букв в слове mirage нечитабельна? O_o

Это ответ "да" или "нет"?

P.S. "Леди Винтер, графиня де ля Фер, леди Кларик" (с) ;)

>И получили бы такую же производительность, как в C++?

полагаю, повыше.

>А как на счет реализации арифметики, которую в C++ реализации сделали на шаблонах?

кто-то выше говорил про экономию памяти? O_o

>В Oberon-е бы все ручками делали?

что, внешние препроцессоры религия запретила — на самый крайний случай? хотя это глупо и ненужно, на самом деле. и вложеность такая не нужна, отлично заводятся временные переменные, которые оптимизатор сам выкидывает. получаются вполне нормально читаемые строки. IMPORT FixPoint16 := FP16; и так далее. и всю эту дребедень компилятор спокойно заинлайнит.

да не стоит так за меня переживать, право же…

нужно, наверное, очень много пить в честь 1-го апреля, чтобы прочитать «mirage» как «irsi».

> нужно, наверное, очень много пить в честь 1-го апреля, чтобы прочитать «mirage» как «irsi».

Не-а, нужно увидеть Irsi в l-t, рекламирующим Оберон.

>> Было впадлу собирать буст под MSVC 6 >Что само по себе напрашивается на аплодисменты.

А ты ее собирал под MSVC 6? В stlport хотя бы потрудились сделать nmake скрипт. Разбираться в связке чей-то непонятный jam + ms cl + ms линкер действительно впадлу, тем более что овчинка выделки не стоит - MSVC 6 плохо поддерживал т.н Стандарт, так что трахаться с бесконечными воркараундами в бусте желания не было.

>Loki собирать тоже было впадлу?

loki? под msvc 6 ? попробуй.

ну так а я тут при чём? я вообще Оберон не упоминал, пока меня не спросили, на чём бы я стал писать. спросили — ответил. точно так же там могло оказаться bit scheme, например, или forth. просто я выбрал нечто более близкое к C/C++, иначе совсем нечестно. %-)

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

а за удаление камента в новостях скор снимают? мне ещё 30 поинтов до нуля скинуть надо. ну, на всякий случай проверим: я охуительно рад, да.

> loki? под msvc 6 ? попробуй.
Я использовал Loki под msvc6 в продакшене ещё 4 года назад.
Перед этим, естесно, попробовал.
А что, есть проблемы?

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

>А что, есть проблемы?

Например, отсутствие partial template specialization и template template classes.

>Я использовал Loki под msvc6 в продакшене ещё 4 года назад.

Это хуже малолетнего фанатства.

>>И получили бы такую же производительность, как в C++?

>полагаю, повыше.

Сильно пришлось бы постараться, чтобы повыше получилось, однако http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ooc&...

>>А как на счет реализации арифметики, которую в C++ реализации сделали на шаблонах?

>кто-то выше говорил про экономию памяти? O_o

Ой, шаблоны, оказывается ведут к расходу памяти? Просветите, плз.

>>В Oberon-е бы все ручками делали?

>что, внешние препроцессоры религия запретила — на самый крайний случай? хотя это глупо и ненужно, на самом деле. и вложеность такая не нужна, отлично заводятся временные переменные, которые оптимизатор сам выкидывает. получаются вполне нормально читаемые строки. IMPORT FixPoint16 := FP16; и так далее. и всю эту дребедень компилятор спокойно заинлайнит.

Ага, конечно. То, что в C++ пишется простым арифметическим выражением в Oberon-е нужно разложить вручную на элементарные составляющие. Т.е. написать раза в 3-4 больше кода, а потом надеятся, что оптимизатор все это заинлайнит.

Если с Oberon-ом все так прекрасно, не объясните, почему встроенное ПО на C++ пишут все, кому не лень, а на Oberon-е нужно днем с огнем искать? Если уж Oberon такой серьезный конкурент в этой области...

> отсутствие partial template specialization и template template classes.
С танцами, я так понимаю, тоже не всё гладко?

> Это хуже малолетнего фанатства.
От тебя это действительно смешно слышать.

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

пруфлинк или не бывает

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

браво :)

>почему встроенное ПО на C++ пишут все, кому не лень

мне это, кстати, тоже непонятно

>Если код на с++ вариантов быть не может. Удалять не надо никогда.

А вот tailgunner другого мнения - он не видит смысла результат
порождающего метода оборачивать в auto_ptr, хота удалять его надо.
Разберитесь между собой сами.

Bar& GetBar()
{
return *m_bar;
}

Bar GetBar() const
{
return *m_bar;
}

Бугагага. Это твой код? Возвращение по ссылке рассматривать не будем,
т.к ни один Ц++ фэн не знает точно когда использовать ссылку, а когда
указатель. По мне так ссылки нужны только чтобы передать параметр по const-ссылке или чтобы вернуть результат operator[] или что-то еще
для реализации семантики значений.

Ну да ладно. Второй вариант: совершенно очевидно что Bar это
полиморфный объект, так как он лежит в куче и доступен через указатель
Теперь вопрос: как ты полиморфный объект
собираешься вернуть *по значению* ? Произойдет срезка. loki он
использовал в продакшене на msvc6, бугагага.

> tailgunner другого мнения - он не видит смысла результат порождающего метода оборачивать в auto_ptr, хота удалять его надо.

Это потому, что ты мутно формулируешь задачу - то дать доступ к члену класса, то к его копии.

> Разберитесь между собой сами.

Уже.