Вышел Boost 1.35

> достаточно засунуть в объект дебильный метод __del__ :(

О том и речь. Если кто-то хочет отстрелить себе ногу, пусть.

> Поражает, что те, кто обсирает в этой ветке с++, также с ним знакомы весьма поверхностно.

ровно как и про яву, питон, руби, перл и <[не]нужное подставить>.

Все это просто инструмент.

>О том и речь. Если кто-то хочет отстрелить себе ногу, пусть.

проблема в том, что такое поведение неочевидно. Если я выделил память, и у меня нет сборщика мусора, очевидно, что её надо когда-то отдать. А вот если поведение класса резко меняется от добавления метода, это очень плохо. И неважно, что это "рыбу заворачивали". Мне-то от этого не легче...

>C++ хороший язык, но его либы - просто кошмар! Просто бесит зоопарк из кучи API-функций и отсутствие нормального ООП SDK. Boost тоже кладезь кода школьников со всего свету

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

>> Хм.... ACE? >Ice?

ICE можно сравнивать с TAO, но никак не со всем ACE. хотя в своей нише он, несомненно, очень крут. ну а asio - это вообще другая весовая категория, это как отвёртку с паровозом сравнивать

> проблема в том, что такое поведение неочевидно. Если я выделил память, и у меня нет сборщика мусора, очевидно, что её надо когда-то отдать.

Насколько я понимаю, объявляя __del__ программист говорит "Я беру на себя ответственность за циклические ссылки". Осилил он или нет, можно проверить с помощью gc.

>Поражает, что те, кто обсирает в этой ветке с++, также с ним знакомы весьма поверхностно.

не все

>Особенно высказывание о скором засилье быдлокодеров. Такого не будет никогда, так как с++ в изучении весьма сложен.

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

циклические ссылки не всегда очевидны. с помощью какого-нибудь observer'a их создать элементарно. другое дело, если умышленно их не создавать, слабые ссылки и всё такое. но тогда и сборщик мусора не очень то и нужен.

> Создаёшь 2 объекта с методами __del__, и делаешь между ними циклическую ссылку.

> а зачем ТАК делать? О_О

Чтобы доказать, что у питона косяков с памятью (якобы) не меньше чем в C++. >_<

> циклические ссылки не всегда очевидны. с помощью какого-нибудь observer'a их создать элементарно.

Если не объявить __del__, Питон их уберет сам.

> Особенно высказывание о скором засилье быдлокодеров. Такого не будет никогда, так как с++ в изучении весьма сложен.

Про C++ Builder в курсе? >_<

>Если не объявить __del__, Питон их уберет сам.

это понятно. но __del__ всё-таки иногда нужен. тред остановить, етс. можно конечно сделать это явно, но это явно, а это деструктор, но циклические ссылки :)

>К Алекандреску особых притензий нет, но вот как он появился в D начал гнуть язык в сторону С++. Он класный спец по С++ (хотя его трехэтажные шаблоны не одобряю). Но он сильно на этом с++ зациклен. Наприер благодаря ему сейчас в ди куча способов объявить константу.

про константы там вообще песня! то их бох уолтер кричал, что константы вообще не нужны ( и в 1-ой версии языка их вообще нет), то он вдруг решил что они нужны (а куда без них?) и настругал такого трехэтажия..., а проблемы всплывают и всплывают. прикол с рефлексивностью вообще песня! похоже, что на ди уже стоИт жирный Хе, а жаль. лучший С++ реально нужен и следующий стандарт всех проблем не решает...

Кто хорошо знает, не обсирают.

Не спорное. Чтобы нормально научиться писать на с++ (не на с!), нужно минимум полгода. Пока асилишь Майерса, Саттера, Александреску, Йоссутиса; сделаешь первый серьезный проект и тд. Если же углубиться в шаблоны, нужно еще больше.

Неа. Не довелось :)

это два разных вопроса. зачем нужен деструктор надеюсь понятно. зачем нужны циклические ссылки: class Object: def __init__(self): self.gui = ObjectGui(self).

всё вместе - объекты в gc.garbage

>Кто хорошо знает, не обсирают.

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

>Не спорное. Чтобы нормально научиться писать на с++ (не на с!), нужно минимум полгода. Пока асилишь Майерса, Саттера, Александреску, Йоссутиса; сделаешь первый серьезный проект и тд. Если же углубиться в шаблоны, нужно еще больше.

а по-твоему для того чтобы работать C++-программистом всё это необходимо знать ?

> это два разных вопроса. зачем нужен деструктор надеюсь понятно.

В питоне? Не понятно.

> зачем нужны циклические ссылки: class Object: def __init__(self): self.gui = ObjectGui(self).

Хмм... Апстену?

> Неа. Не довелось :)

Ну уж про MFC?

> похоже, что на ди уже стоИт жирный Хе, а жаль.

Ну ты прямо лишаешь веры в человечество :(

> уверяю тебя, ты заблуждаешься.

Слово "обсирать" имеет для меня довольно однозначную окраску. Критиковать и обсирать - две большие разницы.

> а по-твоему для того чтобы работать C++-программистом всё это необходимо знать ?

Да. Майерс - обязательно обе книги. Саттер эксепшнл с++ - обязательно. Александреску не модерн дизайн (это на любителя), а 101 кодинг стандартс, хотя там многое повторяется из Майерса - обязательно. Йоссутис, STL и темплейты - обязательно.

Можно, конечно, пописывать себе на с и называть себя программистом на с++, но мы-то знаем, что это не так.

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

Беру свои слова взад :-D

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

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

О, нашел тебя в этом топике. Ты в топике про Яву обмолвился, что Тикль совсем не для gui, а у него есть более правильные ниши. Не мог бы по-подробнее об этих правильных нишах?

>Слово "обсирать" имеет для меня довольно однозначную окраску. Критиковать и обсирать - две большие разницы

и тем не менее. как раз на ЛОРе можно легко убедиться в том, что вполне себе умные люди зачастую предпочитают именно обсирать

>Да. Майерс - обязательно обе книги. Саттер эксепшнл с++ - обязательно. Александреску не модерн дизайн (это на любителя), а 101 кодинг стандартс, хотя там многое повторяется из Майерса - обязательно. Йоссутис, STL и темплейты - обязательно.

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

>Можно, конечно, пописывать себе на с и называть себя программистом на с++, но мы-то знаем, что это не так

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

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

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

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

Что до понятности и простоты очередной системы, то почему же тогда возникают такие мегаобсуждения (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&... Что Вальтера даже вынудили написать const(FAQ) (http://www.digitalmars.com/d/2.0/const-faq.html)?

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

Так что слухи о понятности, простоте и полезности системы константности в D сильно преувеличены. По крайней мере пока, ведь D2.0 широко никем не используется.

Да может и не успеть использоваться, т.к. ходят слухи о том, что D2.0 будет завершен к осени, а затем начнется D3.

> Да может и не успеть использоваться, т.к. ходят слухи о том, что D2.0 будет завершен к осени, а затем начнется D3.

дада :(( И опять не будет совместим ни с D1, ни с D2. Не сделали бы второй С++

Ок, консенсус :)

>О, нашел тебя в этом топике. Ты в топике про Яву обмолвился, что Тикль совсем не для gui, а у него есть более правильные ниши. Не мог бы по-подробнее об этих правильных нишах?

Tcl - практически идеальный язык middleware, программный клей. он для этого проектировался, и большую часть своей жизни для этого использовался. язык управления процессами. интерпретатор достаточно маленький чтобы легко быть встроенным в сложную систему (как в MsgCourier), но достаточно мощный чтобы эту систему контролировать извне (как в Tcl ICE Lib). то, что у того же Python есть в Twisted - у Tcl есть в ядре. плюс высокая надёжность, небольшой footprint в память (а для крайних случаев есть Jim и eTcl) и очень простой синтаксис

GUI в смысле Tk никогда не задумывался для прикладного программирования. его туда тянуть стали по сути уже после ухода Остерхаута

>Насколько я понимаю, объявляя __del__ программист говорит "Я беру на себя ответственность за циклические ссылки"

вообще за всё. gc тоже не работает при этом. и лопается память. А всё из-за обратной совместимости, благодаря которой приходится сношать ужа с ежом, вот с такими результатами.

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

>> это два разных вопроса. зачем нужен деструктор надеюсь понятно.

>В питоне? Не понятно.

+1. При наличии finally и тем более with этот анахронизм должен умереть. Вместе с неюникодными строками

>> Да может и не успеть использоваться, т.к. ходят слухи о том, что D2.0 будет завершен к осени, а затем начнется D3.

> дада :(( И опять не будет совместим ни с D1, ни с D2. Не сделали бы второй С++

А что C++? Я вот с 92-го года практически бесболезнено с компилятора на компилятор переходил, но такого разрушения совместимости между разными редакциями C++, как в D не видел.

> А что C++?

А то, что D станет просто близнецом С++. Я не про то, что ломают совместимость. а про то куда они его ведут. А так все хорошо начичалось :(

Это конечнов стоит писать в nntp://news.digitalmars.com , но всё же:

Как насчёт транзитивных const и mutable для полей? Какие могут быть потенциальные проблемы?

>> А что C++?

>А то, что D станет просто близнецом С++. Я не про то, что ломают совместимость. а про то куда они его ведут. А так все хорошо начичалось :(

Теперь понял. Но ведь все широкоиспользуемые на практике языки вынуждены развиваться и их авторам приходится добавлять в них то, что в начале казалось явно лишним (достаточно вспомнить добавление генериков в Java и C#).

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

> Как насчёт транзитивных const и mutable для полей? Какие могут быть потенциальные проблемы?

Да я уже устал один и тот же пример приводить и в news.digitalmars, и здесь. Вот последняя попытка: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&...

>> Как насчёт транзитивных const и mutable для полей? Какие могут быть потенциальные проблемы?

> Да я уже устал один и тот же пример приводить и в news.digitalmars, и здесь. Вот последняя попытка: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&;. ..

Упс, запостил сообщение не дописав. Так вот, это всего лишь один пример, можно привести еще и другие, не только из многопоточности.

>В питоне? Не понятно. >Хмм... Апстену?

учиться, учиться и ещё раз учиться.

> Да я уже устал один и тот же пример приводить

Попробую привести в news.digitalmars другой пример, попроще. Примерно этот: http://alenacpp.blogspot.com/2005/10/mutable-constcast.html

>> Да я уже устал один и тот же пример приводить

>Попробую привести в news.digitalmars другой пример, попроще. Примерно этот: http://alenacpp.blogspot.com/2005/10/mutable-constcast.html

Боюсь, что этим Вальтера не проймешь, т.к. он явно против самого понятия "логическая" константность: http://www.digitalmars.com/d/2.0/const-faq.html#logical-const :

The problem with logical const is that const is no longer transitive. Not being transitive means there is the potential for threading race conditions, and there is no way to determine if an opaque const type has mutable members or not.

А я свой пример привожу потому, что Вальтер везде заявляет, что транзитивная константность в D2 -- это способ упрощения многопоточности. Хотя в моем примере это как раз не так.

> В питоне? Не понятно. >Хмм... Апстену?

> учиться, учиться и ещё раз учиться.

Именно. Вам. Начать можно с MVC. И finally. __del__ и деструуторы питоне не нужны. И __init__ в каждом классе - тоже не нужен, если подумать.

> __init__ в каждом классе - тоже не нужен, если подумать.

Это смотря о чем думать - так можно сказать, что конструкторы вообще не нужны, нигде и никогда.

Нет, я за описание мета-полей как членов класса, вместе с дефолтными значениями и маппингом из/в xml/json/etc. Мы не стобой разве флеймили на эту тему?

> я за описание мета-полей как членов класса, вместе с дефолтными значениями

Конструктор может делать как раз это.

> и маппингом из/в xml/json/etc

Маппинг не всегда есть.

> Мы не стобой разве флеймили на эту тему?

Да разве это был флейм? 8)

> Конструктор может делать как раз это.

Да, он их генерирует по полям класса. Кстати при желании можно сделать без геммороя и строгую проверку в __setattr__, сравнивая со списком полей класса, для тхе классво где оно полезно.

>> и маппингом из/в xml/json/etc

> Маппинг не всегда есть.

Опционно, конечно.

>> Конструктор может делать как раз это.

> Да, он их генерирует по полям класса

А может и не по полям класса :) Зачем лишать людей гибкости? По-любому, генерация значений - это код, поэтому конструктор неизбежен.

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

Это типа своя реализация __slots__? ;)

Пока не выйдет C++пох bosst:: не нужен. Я за красивый код, а их метод работы с переменным числом шаблонных параметров меня совсем не устраивает.

> Boost не дерьмо. Это C++ дерьмо, а Boost из этого дерьма честно выжимает максимум его убогих возможностей. Так что в стандарте он должен быть обязательно.

Посмеялся. Если бы C++ был дерьмом вы бы этого boost:: даже не увидели бы :-D

> А может и не по полям класса :) Зачем лишать людей гибкости?

Я себя лишаю, там где мне это удобно.

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

Да, но одын на всю программу ;)

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

> Это типа своя реализация __slots__? ;)

Сравнил! я могу на время тестов сравнивать и *типы* значения, переданного __setattr__, с известным мне типом значения по умолчанию!

>Если бы C++ был дерьмом вы бы этого boost:: даже не увидели бы :-D

эта фраза замечательна тем, что с ней невозможно поспорить :)