Планы по выпуску GTK+ версии 3

> Как мне сделать замыкание, не городя дополнительного класса?

Если класс анонимный - не вижу в чем принципиальное желание не иметь дополнительного класса. Места на диске жаль? Если теоретически - да, за отсутствие замыканий жабку пинали и будут пинать. Если пракически - этой проблемы нет в 99.(9) случаев.

> только из-за того, что EJB это требует?

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

> Как мне поработать с файлом, не городя целый экран try-finally?

Никак. В других языках для тех же проверок придется делать целый экран if-then-else-ов. Какая разница? Или Вы считаете, что джедаи не проверяют возвращаемых кодов? Кстати, если совсем ломает - сделайте один try и один finally. Все последствия - на ваш счет.

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

При этом надстраивание этажей для получения ОО из C почти никого не смущает.

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

Извечная проблема баланса между скоростью и универсальностью.

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

Это еще вопрос.

> При этом надстраивание этажей для получения ОО из C почти никого не смущает.

Можно (и нужно!) над трубами построить высокоуровневый абстрактный ОО API - и тогда станет все равно, трубы или нет под ним. Трубы можно спрятать так, чтобы их никто не видел

С языками этот ход не пройдет.

не перекручивайте мои слова :) писать кривой код можно в чем угодно, насчет "сложности детекта ошибок, заложенных в базовых класах, ростут явно круче чем линейно, по мере усложнения уровней абстрагирования" - абсолютное 4.2, именно разделение кода на классы позволяет абсолютно точно найти место ошибки, вместо перелопачивания кучи функций по порядку, дальше - "Неподходит С++ для "больших" проектов", ну явно те же 4.2, за примерами ходить далеко не надо - КДЕ 3.5.9, так что в вас говорит предубежденность, а не логика

>> Как мне сделать замыкание, не городя дополнительного класса?

> Если класс анонимный - не вижу в чем принципиальное желание не иметь дополнительного класса.

Интерфейс в любом случае приходится объявлять.

> Места на диске жаль?

Не на диске. Это дополнительная запись в списке классов, автодополнении... Когда их много, становится трудно ориентироваться.

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

Да вот только санки обещали от этой недоделки избавиться :) Но в "будущих версиях"

>> Как мне поработать с файлом, не городя целый экран try-finally?

> Никак. В других языках для тех же проверок придется делать целый экран if-then-else-ов.

Почему же? Например, ifstream вполне закроется своим же деструктором.

Но всё же в целом получаем большую многословность явы.

> Можно (и нужно!) над трубами построить высокоуровневый абстрактный ОО API - и тогда станет все равно, трубы или нет под ним. Трубы можно спрятать так, чтобы их никто не видел

Угу, надстроим корбу, а потом начнём удивляться, а чой-то оно тормозит :)

> С языками этот ход не пройдет.

Не распарсил.

> Но всё же в целом получаем большую многословность явы.

+1. Это правда. Но вместе с тем она очень проста как язык. Намного проще плюсов.

> Угу, надстроим корбу, а потом начнём удивляться, а чой-то оно тормозит :)

Купим проц побыстрее, памяти побольше. Оптимизация фигня, по сравнению с хорошими интерфейсами (да, я жаваписец)

> Не распарсил.

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

>> Но всё же в целом получаем большую многословность явы.

> +1. Это правда.

О чём я и говорил.

> Но вместе с тем она очень проста как язык. Намного проще плюсов.

Конечно проще. И ограниченней. Отстрелить на ней яйца гораздо сложнее.

> Отстрелить на ней яйца гораздо сложнее.

C - если вы захотите выстрелить себе в ногу, то сделаете без проблем.

C++ - вы можете выстрелить себе в ногу, даже если не хотели этого.

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

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

> Конечно проще. И ограниченней. Отстрелить на ней яйца гораздо сложнее.

Это гигаплюсище для индустриального программирования. Для того и делали. И халва аллаху. 90% программистов при входе в офис надо одевать смирительную рубашку.

>> Конечно проще. И ограниченней. Отстрелить на ней яйца гораздо сложнее.

> Это гигаплюсище для индустриального программирования. Для того и делали.

Ключевая подстрока "индус" :)

и "триальный"

[:]|||[:]

>>> Инкапсуляции, соотвествующей (неопубликованному) определению Absurd@LOR, в Си++ нет :)

>> Инкапсуляция - сокрытие деталей реализации от клиента кода.

>Спроси капитана Очевидность - он скжет, что даже Си отвечает такому определению "инкапсуляции".

А Си++ не отвечает, бугага =)

>>> Инкапсуляция - сокрытие деталей реализации от клиента кода.

>> Спроси капитана Очевидность - он скжет, что даже Си отвечает такому определению "инкапсуляции".

> А Си++ не отвечает, бугага =)

Как скажешь.

>> Спроси капитана Очевидность - он скжет, что даже Си отвечает такому определению "инкапсуляции".

> А Си++ не отвечает, бугага =)

Мсье всё ещё путает "клиента кода" с компилятором?

>> JVM это как город спроектированный по регулярному плану, т.е с противопожарными рвами и канализацией. И поэтому потолок для роста объема кода намного выше.

>Как мне сделать замыкание, не городя дополнительного класса?

А как мне в С++ передать куда-то указатель на метод безо всяких костылей типа Loki::Functor или boost::function?

>Как мне не плодить SomethingBean ещё и интерфейс Something, хотя он используется только одним классом, в EJB только из-за того, что EJB это требует?

Ынтерпрайз блин. Как будто в С++-центричном COM/DCOM/COM+ было иначе.

>Как мне поработать с файлом, не городя целый экран try-finally?

А это правильно - RAII должен сдохнуть. Деинициализация должна производиться только явно в finally блоке. Собственно Торвальдса багофича С++ с "исключением в деструкторе" и бесит больше всего. Было бы в стандартном С++ что-то типа оффтопичного SEH может быть и было бы ядро или его часть на плюсах.

> Было бы в стандартном С++ что-то типа оффтопичного SEH может быть и было бы ядро или его часть на плюсах.

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

>> Было бы в стандартном С++ что-то типа оффтопичного SEH может быть и было бы ядро или его часть на плюсах.

>Бугага. Поищи в архивах обсуждение предложения реализации механизма исключений в ядре - может, станешь относится к Торвальдсу объективнее.

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

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

>Да вот хз

Что хз? Не стал искать?

> под оффтопиком ядропейсатели вроде бы нормально живут на С с SEH исключениям.

Живут. Они и с Си++ живут.

> А как мне в С++ передать куда-то указатель на метод безо всяких костылей типа Loki::Functor или boost::function?

Реализовав классом правильный интерфейс и передав ссылку на класс.

> Ынтерпрайз блин. Как будто в С++-центричном COM/DCOM/COM+ было иначе.

У тебя тяжёлое наследие оффтопичных говнотехнологий.

> А это правильно - RAII должен сдохнуть. Деинициализация должна производиться только явно в finally блоке.

Ты просто не умеешь пользоваться фишками области видимости. Банальнейший пример: QMutexLocker.

>> под оффтопиком ядропейсатели вроде бы нормально живут на С с SEH исключениям.

>Живут. Они и с Си++ живут.

У них С++ очень специфичен. Можно сказать, они не пользуются ни стандартной библиотекой, ни RAII, ни RTTI, ни экзепшенами. И кроме того у них вагон нестандартных расширений. Как будто Линукс Кернел Тиму нечего делать кроме как бодаться с лэнгвидж-лоерами из gcc и делать другую библиотеку для С++, пригодную для системного программирования. Работа встанет на год, а может на два. И я сомневаюсь что результаты будут хорошими.

>> А как мне в С++ передать куда-то указатель на метод безо всяких костылей типа Loki::Functor или boost::function?

>Реализовав классом правильный интерфейс и передав ссылку на класс.

А в Жаве что, не так?

>> Ынтерпрайз блин. Как будто в С++-центричном COM/DCOM/COM+ было иначе.

>У тебя тяжёлое наследие оффтопичных говнотехнологий.

Напиши свой Ынтерпрайз Тикль.

>> А это правильно - RAII должен сдохнуть. Деинициализация должна производиться только явно в finally блоке.

>Ты просто не умеешь пользоваться фишками области видимости. Банальнейший пример: QMutexLocker.

Я сказал - RAII в морг, значит в морг. Только аккуратная инициализация, возможно в несколько стадий и аккуратная деинициализация с соблюдением нужной последовательности действий, возможно в несколько стадий.

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

>Что хз? Не стал искать?

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

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

>>Что хз? Не стал искать?

> Кинь ссылку.

Лень. Я за этим следил когда-то давно в реальном времени :)

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

Даже и близко ничего похожего (ты вообще читал - "в ядре"? там голый Си, предлагалось что-то типа SEH). Великий Линус не счел механизм исключений достаточной причиной реализовывать {set,long}jmp на всех платформах.

>>> А как мне в С++ передать куда-то указатель на метод безо всяких костылей типа Loki::Functor или boost::function?

>> Реализовав классом правильный интерфейс и передав ссылку на класс.

> А в Жаве что, не так?

Parse error: мысль not found :)

> Напиши свой Ынтерпрайз Тикль.

Лужа бурлит.

> Я сказал - RAII в морг, значит в морг.

О, Великий!

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

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

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

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

Разруха не в языках, а в головах. Почти цитата.

Вопрос - у кого 8)

> Как будто Линукс Кернел Тиму нечего делать кроме как бодаться с лэнгвидж-лоерами из gcc

Ходят слухи, что в lkml под gcc копают... :)

>>>> А как мне в С++ передать куда-то указатель на метод безо всяких костылей типа Loki::Functor или boost::function?

>>> Реализовав классом правильный интерфейс и передав ссылку на класс.

>> А в Жаве что, не так?

>Parse error: мысль not found :)

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

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

>Да-да, а давайте ещё назовём то место, где будет производиться аккуратная деинициализация деструктором.

Там где надо там деструктор и вызовем. Явно. Например в finally блоке.

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

А ты вспомни, как ты задачу поставил: "не используя Loki::Functor или boost::function". С ними чудным образом получается короче. (Речь-то шла о многословности явы)

>> Да-да, а давайте ещё назовём то место, где будет производиться аккуратная деинициализация деструктором.

> Там где надо там деструктор и вызовем. Явно. Например в finally блоке.

Ну молодец, пиши, дублируй один и тот же код.

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

>А ты вспомни, как ты задачу поставил: "не используя Loki::Functor или boost::function". С ними чудным образом получается короче. (Речь-то шла о многословности явы)

Ты вообще разбирался как они работают? Можешь на пальцах, словами описать процесс инстанциации шаблона для boost::function с двумя параметрами, допустим int и std::string ?

>> Там где надо там деструктор и вызовем. Явно. Например в finally блоке.

>Ну молодец, пиши, дублируй один и тот же код.

Ну дублированный или плохо нормализованный это не значит сломанный код. Код с С++ исключениями и RAII - это именно сломанный код.

> Ты вообще разбирался как они работают? Можешь на пальцах, словами описать процесс инстанциации шаблона для boost::function с двумя параметрами, допустим int и std::string ?

А нафига? Работает и ладно.

> Ну дублированный или плохо нормализованный это не значит сломанный код.

Языки высокого уровня придуманы в т.ч. для снижения количества дублированного кода на одинаковые действия.

> Код с С++ исключениями и RAII - это именно сломанный код.

Только в твоём маленьком, уютном выдуманном мирке.

> дублированный или плохо нормализованный это не значит сломанный код

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

>> Ты вообще разбирался как они работают? Можешь на пальцах, словами описать процесс инстанциации шаблона для boost::function с двумя параметрами, допустим int и std::string ?

>А нафига? Работает и ладно.

Типичное плюсофильское виляние. То "я обязан знать как оно работает", то "работает и ладно". А там много тонкостей. Например, если есть Loki::Functor с параметром const std::string& он должен инстанциировать operator(const std::string&) и переходник с таким же параметром. Однако Loki::BindFirst не должен у себя внутри хранить ссылку, он должен хранить инстанс std::string, так как строка которую биндят к параметру может быть разрушена к тому момент когда этот функтор вызовут и следовательно надо сделать копию объекта-значения внутри биндера. Ты можешь навскидку накидать шаблон для дедукции такой вещи?

>> Ну дублированный или плохо нормализованный это не значит сломанный код.

>Языки высокого уровня придуманы в т.ч. для снижения количества дублированного кода на одинаковые действия.

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

> Однако Loki::BindFirst не должен у себя внутри хранить ссылку, он должен хранить инстанс std::string, так как строка которую биндят к параметру может быть разрушена к тому момент когда этот функтор вызовут и следовательно надо сделать копию объекта-значения внутри биндера. Ты можешь навскидку накидать шаблон для дедукции такой вещи?

Я читаю маны. И поэтому "трока которую биндят к параметру может быть разрушена к тому момент когда этот функтор вызову" для меня не станет неожиданностью.

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

Если пишешь через ж*пу, что поведение программы зависит от порядка вызова деструкторов, то не удивительно, что схватишь сегфолт. Так что тут не к языку надо претензии предъявлять, а к рукам/голове писавшего.

>> Однако Loki::BindFirst не должен у себя внутри хранить ссылку, он должен хранить инстанс std::string, так как строка которую биндят к параметру может быть разрушена к тому момент когда этот функтор вызовут и следовательно надо сделать копию объекта-значения внутри биндера. Ты можешь навскидку накидать шаблон для дедукции такой вещи?

>Я читаю маны. И поэтому "трока которую биндят к параметру может быть разрушена к тому момент когда этот функтор вызову" для меня не станет неожиданностью.

Это неправильное поведение, BindFirst должен консервировать параметры до момента вызова. Он кстати так и делает, но на некоторых версиях Intel C++ это не работает.

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

Любой любитель Си++ - черезжопный программист по определению. Либо платонический любитель плюсов типа tailgunner'а которому на Сях видимо скучно, и ищет приключений на свою голову. Тебе вообще нельзя разрешать кодить на Си++ - ты опасен. Ни Си++ надо разрешать кодить только тем кто Си++ терпеть не может. Либо старым Сишникам. При обязательном соблюдении максимально унылых кодинг стандартов.

"Любой любитель Си++ - черезжопный программист по определению" - настолько же безосновательное заявление, как и "Любой человек с ником Absurd - пидорас по определению", как видно фактов у вас нет, а доказать( прежде всего себе самому ) свою правоту( точнее доказать, что то, что вы не осилили( прежде всего культуру программирования ) - это все фигня ) ой как хочется :)

> Тебе вообще нельзя разрешать кодить на Си++ - ты опасен.

Я ж расстрелян :)

> Ни Си++ надо разрешать кодить только тем кто Си++ терпеть не может. Либо старым Сишникам. При обязательном соблюдении максимально унылых кодинг стандартов.

Наверно, потому ты на нём и пишешь(вроде было где-то выше по треду). И пытаешься тем самым обосновать свою ярую страсть к ненависти инструмента.

>"Любой любитель Си++ - черезжопный программист по определению" - настолько же безосновательное заявление, как и "Любой человек с ником Absurd - пидорас по определению", как видно фактов у вас нет

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

> следовательно надо сделать копию объекта-значения

Я был не в курсе таких подробностей. Это что ж - там еще и конструктор копирования по ходу вызывается?

ЗЫ Конструкторы копирования я всегда любил - надо постоянно помнить о том, что при неаккуратности компилятор начнет копировать объекты. И вообще я тихонько млел от того, что в плюсах две конструкции могут в общем случае приводить к разным результатам:

C a = b;

и

C a; a = b;

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

Да. Вы хотите назвать это недостатком языка?

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

Первый недостаток я бы обобщил так "в нормальном ОО языке не должно быть способа передать объект по значению, с неявным копированием". Или еще более общо (но это надо подумать, возможно, я погорячился), "неявное копирование объектов мастдай эз сач".

> Первое мое предложение - да, это недостаток языка.

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

> Второе - ... можете считать это неким моим личным когнитивным диссонансом. Хотя не думаю, что я одинок в нем.

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

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

> Первый недостаток я бы обобщил так "в нормальном ОО языке не должно быть способа передать объект по значению, с неявным копированием". Или еще более общо (но это надо подумать, возможно, я погорячился), "неявное копирование объектов мастдай эз сач".

Если рассматривать идеально сферический ОО язык безо всяких претензий на допущение оптимизированных реализаций операций, то да.

>а чем оно лучше Qt?

GTK+ - LGPL

А, ну ну... GPL на помойку, даёшь LGPL...