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

> вещи вроде smart_ptr легко реализовать самому без всяких boost

Один я помню, что в бусте был баг умном указателе?

># gcc ... BoZo.cc

У меня кстати слева не # а $.

И заголовок поменять на "топ-флеймы"

> Нахрен мне нужно вместе с каждым своим cpp файлом компилировать несколько сотен килобайт из std:: и буста?

на то и существуют precompiled headers ;)

> Не так. Флейм про ГТК, флейм про Рейзера, флейм про BSD

Культурном, образованном обществе это называется: "Новость про ГТК", "Новость про Рейзера", "Новость про BSD"...

>>Речь идет о конкретном случа сигналов в бусте - есть к ним какие-гнибудь претензии, кроме awful hackery by Alexandrescu?

>Нахрен мне нужно вместе с каждым своим cpp файлом компилировать несколько сотен килобайт из std:: и буста?

Мля. Представь, что добрая фея вытащила сигналы из буста и отвязала их от std::. Тогда - какие претензии?

>> Нахрен мне нужно вместе с каждым своим cpp файлом компилировать несколько сотен килобайт из std:: и буста?

>на то и существуют precompiled headers ;)

Оно в Visual C++. В GNU варианте оно вроде бы тоже есть, но не пробовал.

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

относительно давно уже есть в gcc

> К фее, думаю, претензий нет.

Ы. Точно не архиерей?

2Absurd: имелись в виду претензии не к фее, а к сигналам.

%)

Когда меня так настойчиво спрашивают - уже начинаю сомневаться...

Wake up, Neo.

> Мне хватает того что каждая *инстанциация* шаблона std::vector увеличивает бинарь на 4Кб.

Вызывающе неверная информация.

pppp

>Представь, что добрая фея вытащила сигналы из буста и отвязала их от std::. Тогда - какие претензии?

Претензии в том что boost::signal это кусок говна и использовать я это не буду, т.к это кусок говна.

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

>>У любого метода любого объекта должна быть возможность взять адрес и присвоить его указателю на cdecl с той же сигнатурой

Боже мой, что с тобой?
Твое отражение стремает тебя,
Да ты просто невменяем, где ты ходил?

>В тру ОО языке указатели не нужны.

Даже не знаю, как спросить. Вы сборщик мусора противопоставляете ООП?

>> Программист не обязан знать, как работает инструмент?

>А при чем тут это?

При том, что по-вашему (насколько я понял) smart-pointer'ы не позволяют полностью забыть о том, что программист работает с указателем, а не с "обычной" переменной.

>> Ок, как по-вашему должно было бы быть?

>В тру ОО языке указатели не нужны.

Smalltalk перестал быть тру ОО ?
C# я сомневаюсь был ли он, но с вашей подачи перестал ... :(

Вы и так уже договорились, :))
по вашему вообще OO языков не существует, никто не подходит :)))

> Вы сборщик мусора противопоставляете ООП?

Нет. ООП я противопоставляю возможность обратиться по произвольному адресу.

> smart-pointer'ы не позволяют полностью забыть о том, что программист работает с указателем, а не с "обычной" переменной.

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

> Smalltalk перестал быть тру ОО ?

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

>Не тупой, в нем заложена вся функциональность. В GTK объявляется две структуры - одна описывает объект, другая его тип (вот она тупая).

Вообще то, по секрету, вторая структура есть и в С++, vmt называется, и присобачена к каждому классу. В С её надо делать ручками, ессно, но ведь Glib делался под присобачиваемость, от чего и реализован на С. Потому всё и делается ручками. vala - это обёртка на с, позволяющая эту "тупую" структуру руками не писать, и об удалении мусара не беспокоиться, но не более того. Мне кстати, понравилась идея.

>Не ведаю что это такое, но всем и без него хорошо. удаление объектов при наличии циклических ссылок без него не работает. //скотинко

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

а что тут плохого? я сегодня к примеру переписывал часть wx-й библиотеки для печати в пдф, точнее утилитку к ней для конвертации шрифтов - в ней есть несколько больших вложенных циклов, внутри работа со строками с помощью wxStringTokenizer для разбивки на строки, заменил на strchr с последующим сдвигом указателя начала текущей строки - в результате функция которая выполнялась 2-3 секунды выполняется мгновенно, зачем лишать себя дополнительных возможностей для оптимизации/упрощения кода? никто ж не насилует :)

>> Smalltalk перестал быть тру ОО ?

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

http://www.delorie.com/gnu/docs/smalltalk/gst_34.html
ну вот, :(((

>Сколько раз ты на последних 5 страницах видел упоминание про ГТК именно версии 3? Тут GTK vs Qt + C+glib vs C++

ну я ж предлагаю не "флейм про ..." а "флейм посвященный ...". Дескать приуроченный к такому-то событию)

Авторы C++ ещё при рождении языка поставили ему два плюса. Ещё один плюс - и бан на двадцать лет. :-|

Аццки жжош! %)

http://img373.imageshack.us/my.php?image=gtkdp0.png ухоха! =)

капча smodits

Жуть какое. И что - реально можно использовать, разыменовывать? И еще - это гнутое расширение или стандарт?

> Жуть какое.

Да это FFI. В Питоне такое можно, в Руби наверняка тоже.

ух-ты а у меня рекламы нет, хоть я ее и не резал вроде, но реклама в тему, +1 :)

> http://img373.imageshack.us/my.php?image=gtkdp0.png ухоха! =)

Шрифтыыыыыыы....

что шрифты?

наверное это привычка так реагировть на скриншоты, вызванная посещением галерии ЛОРа

> Жуть какое. И что - реально можно использовать, разыменовывать? И еще - это гнутое расширение или стандарт?

то есть гнутое - это уже не кошерно ?
многие языки позволяют такое и OO и чисто функциональные
наличие объекта указателя не превращает язык в не ОО, вообще наличие чего либо не уменьшает возможности языка :)))
если вы хотите утверждать что с++ не ОО надо сказать чего в нем нет для ОО а не что в нем есть :))))
ведь Object* obj - это только синтаксический сахар для std::pointer<Object> obj; ;)

>ведь Object* obj - это только синтаксический сахар для std::pointer<Object> obj; ;)

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

>О чем и речь. Использовать С с парой синтаксических плюшек.

Ну так если эти "плюшки" избавляют от необходимости городить двухметровые костыли, описанные в заглавном посте, то пуркуа бы и не па?

чем catch не подходит?

>чем catch не подходит?

Тем что это не finally

> чем catch не подходит?

Подходит только форма try {} catch(...) {}, потому что иначе ( если catch'ей больше 1) придется дублировать код освобождения ресурсов.

>"Тонны макросов" в gobject добавляют кучу того, что в плюсах как языке просто нет - и пришлось бы добавлять другую (ок, чуть меньшую) тонну макросов.

Т.е. тот язык, в котором для получения одного и того же результата нужно добавить БОЛЬШЕ всяких разных хаков, считается ЛУЧШЕ? Я ниасиливаю такую аргументацию, извините.... =\

>http://img373.imageshack.us/my.php?image=gtkdp0.png ухоха! =)

ROFL!!! Ждем рекламы дом2 и MS =)

>Вы когда-нибудь забывали сделать деструктор виртуальным? А, например, использовали виртуальное наследование вместо невиртуального - или наоборот? Такие ошибки ловить бывает увлекательно, если дерево наследования развесистое...

Блин, и Вы туда же....

Один очень активный в данном треде товарищ тоже как-то возмущался такими "нюансами синтаксиса", как константные методы класса.... =\

Раз у нас такая пьянка, то в ход могут пойти аргументы "вы когда-нибудь забывали проверять длину строки в С?" и прочие подобные прелести....

хоть это и не Ъ, но можно освобождение ресурсов прописать в конце функции и сделать туда goto

> хоть это и не Ъ, но можно освобождение ресурсов прописать в конце функции и сделать туда goto

Из catch?

а что смущает?

Проблема не в том, что в плюсах можно напортачить. А в том, что он создает ВИДИМОСТЬ простоты и защищенности - но на деле этого нет. Куча неявных правил, которые несложно нарушить. С так не обманывает - там сразу видно, что надо быть аккуратным и осторожным.

> а что смущает?

Если надо будет в конце catch сделать throw;, goto не подходит.

все равно не вижу проблемы - с++ дает функционал, если кто-то сам путается в своем же коде, или не способен осилить "Go to declaration", чтоб посмотреть от чего он собственно порождается, то никакой язык не поможет

>>ведь Object* obj - это только синтаксический сахар для std::pointer<Object> obj; ;)

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

именно что фича, много ли языков позволят корректно освободить ресурсы ?
даже имея finally ? это то место, где языки со сборкой мусора нервно курят в сторонке :))

>>Наследование, инкапсуляция, полиморфизм - что из перечисленного реализуется макросами?

>В С++ нет ни первого ни второго ни третьего. Могу расписать.

Распиши, пожалуйста. Я уже как минимум третий заинтересованный человек в этом треде, изъявивший желание это услышать.

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

>хоть это и не Ъ, но можно освобождение ресурсов прописать в конце функции и сделать туда goto

В Майкрософте не Страуструпы работают, в Visual C++ c и в Си и Си++ можно сделать так:

my_error_t result;
__try {
....
result = E_SOMETHING_WRONG;
__leave;
....

} __finally {
... cleanup
}
return result;

Причем __finally отработает и в нормальной ситуации для клинапа после работы, и в результате C++ - исключения в вызываемом в блоке коде т.к С++ исключения все равно через SEH, и по __leave; . В случае __leave ошибка не полетит наверх, оно просто прыгнет в __finally.