Будущее GTK

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

клоун, твои "познания" gobject вызывают только громкий смех в зале (ц)

>на С++ можно писать гораздо компактнее и эффективнее.

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

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

в гуевых _приложениях_ и плюсы никому не нужны - в 90% случаев хватит питона =)

>> Сложность написания кода на С++ равна сложности написания кода на С плюс трудозатраты на войну с С++.

>А ты не борись с ним - используй его.

лолшто?

>Впрочем, если ты начинал с Явы, лучше там и оставайся.

Я начинал с Watcom С++ 10 + dos4gw.

>>> Сложность написания кода на С++ равна сложности написания кода на С плюс трудозатраты на войну с С++.

>> А ты не борись с ним - используй его.

> лолшто?

Какое слово непонятно? Ты спроси, я объясню.

>> Впрочем, если ты начинал с Явы, лучше там и оставайся.

> Я начинал с Watcom С++ 10 + dos4gw

Тогда ты просто ниасилил Си++. Впрочем, тебе это уже говорили.

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

>лолшто?

Майкрософт пыталась сделать что-то ООП на базе С++. Получился СОМ. Поинтересуйся что такое Аггрегация.

>> Я начинал с Watcom С++ 10 + dos4gw

>Тогда ты просто ниасилил Си++. Впрочем, тебе это уже говорили.

Что такое "Осилить С++" ? Что-то написать чтобы работало? Да без проблем. Но код никаких приемуществ перед Си иметь не будет. Я это уже говорил.

> Что такое "Осилить С++" ? Что-то написать чтобы работало? Да без проблем. Но код никаких приемуществ перед Си иметь не будет.

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

> клоун, твои "познания" gobject вызывают только громкий смех в зале (ц)

Клоун, так врать в лицо ты будешь своим красноглазым братьям по разуму
Вот код:

// номер раз:
#define GTK_WIDGET(widget) (GTK_CHECK_CAST ((widget), GTK_TYPE_WIDGET, GtkWidget))

// номер два. такие проверки идут в каждой функции
void
gtk_widget_style_get (GtkWidget *widget, const gchar *first_property_name,...)
{
  va_list var_args;
  g_return_if_fail (GTK_IS_WIDGET (widget));

// номер три. кусок типичного гтк-кода
  gtk_widget_style_get (GTK_WIDGET (button), 

имеем две одинаковые проверки одна на входе, другая внутри функции.
в то время как в С++: button.get_style(); и никакие проверки не нужны.

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

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

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

> Я начинал с Watcom С++ 10 + dos4gw.

Фигасибе, начинал с ваткома и так и не осилил. Талантище, ебт

>> Что такое "Осилить С++" ? Что-то написать чтобы работало? Да без проблем. Но код никаких приемуществ перед Си иметь не будет.

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

Не получится. В результате лавинообразного разрастания инфраструктуры проекта с учетом бинарной модульности, интерфейса со скриптовыми языками, сериализации etc получится COM. А при написании COM кода собственно сам C++ путается под ногами.

> Не получится. В результате лавинообразного разрастания инфраструктуры проекта с учетом _кривизны рук_

исправлено во имя истины

>> Не получится. В результате лавинообразного разрастания инфраструктуры проекта с учетом _кривизны рук_

>исправлено во имя истины

Да, ты прав. При отсутствии артрита руки должны хорошо гнуться в локтях.

> Не получится. В результате лавинообразного разрастания инфраструктуры

Ты смишной. В открытом OpenCASCADE 130Мб сырцов на С++, есть поддержка питона и проект успешно развивается. Просто кое у кого ручки кривые, а сваливает на С++

>> Не получится. В результате лавинообразного разрастания инфраструктуры

>В открытом OpenCASCADE 130Мб сырцов на С++

Это достижение? И что этому проекты дал С++?

>Есть поддержка питона и проект успешно развивается

Проблема не в том чтобы вызвать питон, а в том чтобы питон мог проинстанциировать твой объект и вызвать у него твой метод.

>Вот код:

да ты ещё тупее, чем я думал

был бы у тебя хоть грамм мозгов - ты бы потрудился посмотреть, что такое g_return_if_fail и *_CHECK_CAST

а потом бы почитал, что такое G_DISABLE_CAST_CHECK и G_DISABLE_DEBUG

но поскольку ты непроходимо туп - ты этого не сделал

>бредятина, можно написать враппер или сгенерировать его.

в итоге получается куча говна с нехилым оверхедом, а плюсы не имеют никакой возможности проверить соответствие двух объектов, классы которых объявлены в скрипте (если не предусмотреть ещё один дополнительный механизм проверки типа, как это сделано в Qt через виртуальный метод getClassName (или как-то так)).

собсно, своё скудоумие ты уже продемонстрировал.

> ты бы потрудился посмотреть, что такое g_return_if_fail и *_CHECK_CAST

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

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

какая феерическая чушь.

>В си из-за примитивности языка невозможен даже банальный ап-каст от button к widget.

И мы заюзаем С++, напишем для каждого ресурса оболочку с деструктором, почешем репу как мы будем деструктить связанные объекты которые перед деструктингом надо разъединить, вместо тупого указателя на функцию будем использовать шаблон порождающий инстанс полиморфного типа, размещенный в куче на который будет ссылаться смарт-указатель обернутый в оболочку с перегруженным operator(). Но зато у нас будет динамический апкастинг. Зашибись.

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

Ну и бред. Неудивительно, что с С++ у тебя не срослось.

> Но зато у нас будет динамический апкастинг

Твой "уровень" в С++ теперь понятен.

Олсоу, апкастинг (т.е. от дочернего к базовому) в С++ всегда статический: Widget &w = button;

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

>Ну и бред. Неудивительно, что с С++ у тебя не срослось.

Talks are cheap - show us the code. Прежде чем в GDI удалять перо надо в контекст отбражения воткнуть старое перо. Напиши деструктор. Я это делал в __finally блоке - слава богу что в MS работают люди поумнее Страуструпа.

>> Но зато у нас будет динамический апкастинг

>Олсоу, апкастинг (т.е. от дочернего к базовому) в С++ всегда статический: Widget &w = button;

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

> Talks are cheap - show us the code. Прежде чем в GDI удалять перо надо в контекст отбражения воткнуть старое перо. Напиши деструктор. Я это делал в __finally блоке - слава богу что в MS работают люди поумнее Страуструпа.

Лол, ты все сделал через жопу, а С++ тебе виноват.

struct PaintBlock
{
	int idx;
	HDC hdc;
	PaintBlock(HDC dc) { hdc = dc; idx = SaveDC(dc);}
	~PaintBlock() {RestoreDC(hdc, idx);}
};

void draw(HDC dc)
{
	PaintBlock blk(dc);
	// bla-bla-bla
}

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

Опять двойка. Вообщем не с твоими познаниями С++ критиковать.

>Опять двойка. Вообщем не с твоими познаниями С++ критиковать.

vtable задействуется при апкастинге:

class T3 : public virtual T1, public virtual T2 {
public :
T3();
virtual int f1();
virtual int f2();
virtual int f3();
private :
int d3;
};

void x1(T1& t);
void x2(T2& t);

void x3(T3& t) {
x1(t);
x2(t);
}

Получается такое :

void __cdecl x3(class T3&):
push esi
mov esi,[esp+8] ;t
mov eax,[esi+4] ;vbtable
mov ecx,[eax+4]
lea eax,[ecx+esi+4] ;(T1&)t [via vbtable]
push eax
call (void __cdecl x1(class T1&))
add esp,4
mov edx,[esi+4] ;vbtable
mov eax,[edx+8]
lea eax,[eax+esi+4] ;(T2&)t [via vbtable]
push eax
call (void __cdecl x2(class T2&))
add esp,4
pop esi
ret

>Talks are cheap - show us the code. Прежде чем в GDI удалять перо надо в контекст отбражения воткнуть старое перо. Напиши деструктор. Я это делал в __finally блоке - слава богу что в MS работают люди поумнее Страуструпа.

>Лол, ты все сделал через жопу, а С++ тебе виноват.

struct PaintBlock { int idx; HDC hdc; PaintBlock(HDC dc) { hdc = dc; idx = SaveDC(dc);} ~PaintBlock() {RestoreDC(hdc, idx);} };

А что с пером?

> vtable задействуется при апкастинге:

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

>> vtable задействуется при апкастинге:

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

но по любому это не статическое преобразование.

> В гноме ты идёшь в диалог настройки панелей и говоришь "Хачу динамические клавиатурные комбинации прямо щаз" и получаешь их. В кедах ты прыгаешь с бубном и gtkrc

Логично - в гноме ты тоже будешь прыгать с kcmshell. Однако мы говорим про тулкиты, а не DE.

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

какой ты тупенький. Аж смешно. Ты посмотри все-таки сначала, что это за проверки в glib, на которые ты тут наезжаешь. И в каких случаях они компилятором вставляются. А потом подумай, какой контроль над плюсовыми проверками есть у твоих кривых ручонок =)

ну и как dynamic_cast переехал в compile time - тоже интересно. Расскажешь?

>В си из-за примитивности языка невозможен даже банальный ап-каст от button к widget.

интересно, как button'ы и прочие в обработчики сигрналов передаются, где этот самый кастинг в widget нужен? Не иначе, как через libastral.so

>какая феерическая чушь.

что, не понял нифига, да детка? На курсах по сиплюсплюсбилдеру про это не говорили? =)

> А что с пером?

RestoreDC вернет сохраненное в SaveDC состояние. и перо тоже. твой трах с пером не нужен.

> Ты посмотри все-таки сначала, что это за проверки в glib, на которые ты тут наезжаешь

я уже все написал выше с примерами кода.

> ну и как dynamic_cast переехал в compile time - тоже интересно. лолшто? это ты к чему?

> интересно, как button'ы и прочие в обработчики сигрналов передаются, где этот самый кастинг в widget нужен

для особо тупых повторяю еще раз: кастинг в widget из дочерних классов всегда статический. обратный может быть либо динамическим либо статическим если тип известен заранее.

> что, не понял нифига, да детка

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

>> А что с пером?

>RestoreDC вернет сохраненное в SaveDC состояние. и перо тоже. твой трах с пером не нужен.

Перо надо удалять после того как восстановлен контекст. Полагаемся на порядок вызова деструкторов? В таком случае перо должно быть на более внешнем уровне чем контекст, чтобы сначала был восстановлен контекст а потом удалено перо. Кроме того, результат внешнего вызова SaveDC ты не проверяешь, как последнее быдло.

>я уже все написал выше с примерами кода.

что ты написал? ты тупо скопипастил, совершенно не соображая, что этот код делает

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

в случае скриптовых языков тип _никогда_ не известен заранее. Это раз. Во-вторых, кастинг дочерних виджетов в сях ничего не делает в рантайме. Но ты походу этого не знаешь просто =)

>ручная эмуляция С++ в гтк и сотни вынужденных проверок по сути есть костыли, а не техническое достижение

ты идиот. Объектная модель плюсов ГОРАЗДО уже модели gobject. Так что твои высеры про "эмуляцию" показывают лишь степень твоей АБСОЛЮТНОЙ некомпетентности.

> Перо надо удалять после того как восстановлен контекст.

С чего ты взял? Можно безопасно удалять обьекты выбранные в DC. GDI гарантирует это. К тому же ты как последнее быдло создаешь и удаляешь GDI обьекты во время отрисовки. Так никто не делает. Обьекты обьявляются в классе и создаются заранее, а отрисовка только рисует. Это и быстро и нет того траха который ты сам себе изобрел.

>> Перо надо удалять после того как восстановлен контекст.

>С чего ты взял? Можно безопасно удалять обьекты выбранные в DC. GDI гарантирует это.

AFAIK c win2000 и далее.

>К тому же ты как последнее быдло создаешь и удаляешь GDI обьекты во время отрисовки.

Даже если толщина и стиль всех линий неизвестны во время отрисовки и берутся по мере выфетчивания информации из схемы данных?

> в случае скриптовых языков тип _никогда_ не известен заранее

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

> Во-вторых, кастинг дочерних виджетов в сях ничего не делает в рантайме приехали. в рантайме он не делается, в компайл-тайме тоже, спрашивается нахера тогда там тонны этих макросов?

> ты идиот. Объектная модель плюсов ГОРАЗДО уже модели gobject.

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

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

У тебя что же в отрисовке еще и выборка из базы стоит? ололол, ппц. Тем не менее если так хочется:

void draw(HDC dc) { CPen ppp; // создаем обьекты { // рисуем PaintBlock blk(dc); // bla-bla-bla } }

форматирование забыл

void draw(HDC dc)
{
	CPen ppp; // создаем обьекты
	{ // рисуем
		PaintBlock blk(dc);
		// bla-bla-bla
	}
}

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

>У тебя что же в отрисовке еще и выборка из базы стоит?

Информацию которую надо визуализировать можно брать из libastral ?

>void draw(HDC dc) { CPen ppp; // создаем обьекты { // рисуем PaintBlock blk(dc); // bla-bla-bla } }

А нафиг городить вокруг каждого GDI объекта оболочку с деструктором если в __finally блоке можно явно написать код деинициализации? Культ RAII ?

> нафиг городить вокруг каждого GDI объекта оболочку с деструктором если в __finally блоке можно явно написать код деинициализации? Культ RAII ?

А нафиг городить для каждого GDI-объекта ручной вызов деинициализации в каждом __finally? Культ __finally, да?

> А нафиг городить вокруг каждого GDI объекта оболочку с деструктором если в __finally

Код с деструкторами более компактный и отсутствие утечек gdi обьектов гарантируется. А в твоем кривом быдлокоде мало того, что используется нестандартный __finally, так еще и гарантии на утечки нет.

>Обьектная модель должна буть удобной, а не широкой.

это мантра? Сиди в дельфях, там компоненты - ещё удобнее, чем говноплюсы

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

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

> если некоторые кретины думают, что в плюсах нет утечек памяти благодаря волшебным деструкторам - это не значит, что их там нет

если некоторые кретины думают, что в Си/Питоне/Яве/pickyourpoison нет утечек памяти благодаря Glib/refcounting/GC/whatever - это не значит, что их там нет.

P.S. ничего личного :D

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

ты пустословие-то для красноглазиков оставь.

>P.S. ничего личного :D

ты мне пост покажи, где я говорю, что в си/питон/ява нет утечек памяти благодаря чему-либо. Иначе ты - обычное быдло, подобное ананимусу-плюсофилу.

ничего личного, ага

> ты мне пост покажи, где я говорю, что в си/питон/ява нет утечек памяти благодаря чему-либо

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

> Иначе ты - обычное быдло, подобное ананимусу-плюсофилу

Анонимный брат говорит дело, причем в более корректной форме, чем ты.

> ничего личного, ага

Что, задело? А ведь я только повторил твои слова ;)

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

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

почитай вопли про рульность деструкторов.

>Анонимный брат говорит дело, причем в более корректной форме, чем ты.

анонимный кретин уже продемонстрировал своё полное незнание glib/gtk

ты, впрочем, тоже его регулярно демонстрируешь

>Что, задело? А ведь я только повторил твои слова ;)

я, в отличие от быдла, не утверждаю, что тот или иной инструмент является "серебряной пулей".

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

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

Покажи мне, где написано, что деструкторы гарантируют отсуствие утечек памяти.

>>анонимный кретин уже продемонстрировал своё полное незнание glib/gtk

>ты, впрочем, тоже его регулярно демонстрируешь

Бгг. Ты меня путаешь с кем-то - я вообще ни слова не сказал о gtk.

> я, в отличие от быдла, не утверждаю

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

Здесь этого вообще никто не утверждал. Так что, как говориться, "красота - в глазах смотрящего" ;)

> анонимный кретин уже продемонстрировал своё полное незнание glib/gtk

Лол, смешно. Тебя мордой в очевидные костыли тыкают, а ты все "божья роса".

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

бугага. У тебя знания даже не на нуле, а в отрицательной области

>В С++ строгая типизация, умные указатели, умные контейнеры и исключения.

манглинг, перегрузка операторов, отсутствие интроспекции, рефлексии, . А отладка просто сказка. Особенно отладка шаблонов. А ещё такая мегавещь есть, как неявный вызов конструктора копирования компилятором. Неявное добавление оператора присваивания. И опять сказочная отладка, если код пишет больше одного человека.

>Меньше кода, меньше ошибок, а утечки фактически исключены,

опять мантра?