GTK C *_new functions returning GtkWidgets

Enjoy your plain C OOP.

возвращать и хранить Derived*

и не парься.

Что за удобство такое возвращать base класс из «конструкторa»?

Тот самый ООПшный полиморфизм.

Какие нафиг классы и наследники? Это ж сишечка. Возвращается всегда указатель на структуру, у него класса нет, это просто адрес в памяти, указывающий на какую-то байду. А быть эта байда может и жнецом, и игрецом, и на дуде игрецом; структуры в сишечке не наследуются, посему тип один на всё многообразие «классов». В гутакэ специально накостыляли макросы для «приведения типов», которые чекают, что по данному указателю лежит, то это или не то, что ты имел в виду. Причём ты можешь их не юзать и пихать напрямую одни и те же указатели во все функции с аргументами совместимых типов. Работать будет так же, но вот если сломается — без этих макросов придётся долго и муторно дебажить, чтобы понять, где зрада.

не переча конвенциям Gtk.

А есть где почитать?

Ну имхо они на статистике свои конвенции основывали.
Т.е., если ты создал виджет, то с вероятностью близкой к 100% ты его положишь в контейнер => каст на GtkWidget тебе нужен, и вот он, держи его.
А вот дальше... будешь ли ты вызывать методы MyDerivedFromGtkWidget, либо методы кого-то между GtkWidget и MyDerivedFromGtkWidget по цепочке наследования — тут бабка надвое сказала.
С ненулевой вероятностью ты просто повесишь callback и все, не сохраняя указатель и не вызывая методы на месте.

Имхо следует придерживаться конвенции возврата GtkWidget, чтобы интерфейсы были однотипные везде. Этакий Coding Style.

А вот у себя в private для удобства вполне можно хранить указатель на тип, методы которого чаще дергаешь. Т.е. вариант 2.
Либо, если дергаешь разные методы, то вариант 1.

@Tayler: Вот я тоже так, подумал, везде в GTK все, что наследуется от GtkWidget* возвращает GtkWidget*, например gtk_source_view_new(), gtk_box_new(), да все, что угодно.

Я так и понял, что из-за того, что нету в GTK implicit upcast'a. С другой стороны если в *Private одни GtkWidget*-ы - читаемость стремится к нулю.

@Moondancer: все, что ты сказал правда, но никак не относится к вопросу, который я задал. Посмотри документацию Gtk и «конструктры» «классов» «наследующих» од GtkWidget*. *Private это отдельная структура, где хранятся приватные данные «класса». То, что это все основано на макросах и хаках (хранению struct Parent внутри struct Derived) не мешает ему быть OOP и иметь конвенции.

@av0r в документации любого виджета. Например сравни:

https://developer.gnome.org/gtksourceview/stable/GtkSourceView.html#gtk-sourc...

vs

https://developer.gnome.org/gtksourceview/stable/GtkSourceView.html#GtkSource...

А если честно, то я бы сам с удовольствием, что-то по этому поводу почитал. ;)

Ответ Tayler'а меня устраивает, но я все же для читаемости перелопачу немного код, с которым имею дело, т.е.:

1. Пусть то, что наследует от GtkWidget* в blabla_ew() возвращает GtkWidget* а не Blabla*, раз уж такая конвенция (выросшая из отсутствия implicit upcast'а)
2. Пусть все, что лежит в *Private будет скастовано на Blabla*, тогд открывая *Private будет сразу виден layout данного конкретного виджета (оверлеи в нем там внутри, вбоксы или еще чего)

Причем p2 это лично мое наблюдение, что когда в коде

struct BlablaPrivate {
    GtkWidget *right_widget;
    GtkWidget *left_widget;
    GtkWidget *cool_widget;
    GtkWidget *some_bar_widget;
    GtkWidget *yet_another_widget;
}

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

Используй Vala и таких вопросов возникать не будет

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

Не, про это я в курсе. Я имел в виду, есть ли какие-то руководства по гтк-шному ООПу? Какие они накрутили макросы и для чего они используются?

Думаю где-то тут: https://developer.gnome.org/gobject/stable/gtype-conventions.html или тут https://developer.gnome.org/gobject/stable/ и в других доках на developer.gnome.org. Гугли GObject site:developer.gnome.org. Документация действительно хорошая, но немножко плохо структурирована, чатиь там часть тут.

@Moondancer: ты знаешь, что первый компилятор С with classes (CFront) генерировал C code? Ты знаешь, что Vala генерирует C код? В тюринг-полном языке (как шаблоны например) в C++ на них можно сделать все, вот хотя бы https://www.youtube.com/watch?v=PJwd4JLYJJY. Это сумасшествие, но это возможно.

А если еще учесть, что OOP вообще должно умереть:

• https://www.youtube.com/watch?v=QM1iUe6IofM
• https://www.youtube.com/watch?v=IRTfhkiAqPw

А GObject вполне семе mature объектно-онриентированная модель с reference counting (прямо как в C#) и даже кажеся с gargabe collection в случае cyclic refernce? Здесь могу ошибаться.

Не надо приписывать тупиковой ветви развиия науки computer science (OOP) какие-то вещи, которых в ней нет. Эта ерунда (диаграммы наследования и прочая родом из времен SQL хиерархичность можно релизовать не чем угодно. А настоящего OOP и в Java нет, посмотрите вот эти видео:

• https://www.youtube.com/watch?v=KtHQGs3zFAM
• https://www.youtube.com/watch?v=pjd0IB_8xD8
• https://www.youtube.com/watch?v=gPP7Bleg214

Кроме того, в GTK они использовали libffi (http://sourceware.org/libffi/), чтобы использовать свою объектуню моделья ЛЮБОМ языке. И посмотри сколько binding'ов для GKT? Объектно, там необьъектно, какая разница? Эта объектность ничего не кому ни дела и не выполнила ни одно обещания: https://www.dreamsongs.com/Files/ObjectsHaveFailedSlides.pdf. Какая разница на чем реализовывать это?

Лично меня это поражает и восхищает (написание regexp/json парсера в compile-time). Не знаю, кому это нужно, но звучит мозгораздирающе. А разговоры о том, что это сишечка, в ней можно вернуть тольку указатель на структуру, а в структуре хоть жнец, хоть игрец, да, в C type system слабее, но у тебя не получится сделать так:

struct X {
};

void f(struct Y*);
f(&X);

Разве что я совсем не знаю C.

PS Не надо сужать глаза, вешая на них шоры.