а не на макросах костыли лепить

Это вы про Q_OBJECT?

Не тралль, плеазе. Это я про GOBJECT.

Плюсую Qt, но справедливости ради

GTK пародия на ООП

С чего бы пародия? Там полноценное ООП.

Если нужен ООП, нужно брать язык с ООП

Только это не C++, где ООП тоже лепится костылями поверх языка. Ну да, поменьше костылей выходит.

Ну и вообще, человек не просил ООП, оно ему может и не нужно.

gtkmm тоже может использовать std::

wxWidgets кстати используют нативные контролы на каждой из платформ - линукс, виндовс, макос.

На линуксе там, кажется, тот же GTK дёргается, нет?

gtkmm же

С чего бы пародия? Там полноценное ООП.

Там всё держится на соглашениях. В крестах - встроено в язык.

C++, где ООП тоже лепится костылями поверх языка. нет.

Костыли поверх костылей.

А про Q_OBJECT...

Этот другой аноним и не троллит вовсе.

Не тралль, плеазе. Это я про GOBJECT.

Дело в том, что если не будет этого макроса (да, это макрос), то moc-компилятор не сможет создать файлов, содержащих метаинформацию о сигналах и слотах. Так что, если они (сигналы и слоты) нужны, то будьте любезны городить огород с макросом Q_OBJECT. Иначе вся система сигналов и слотов Qt, основанная на метаобъектах превратится в тыкву.

В GTK всё то же реализуется несколько более изящно. Но да, GOBJECT многим не нравится.

Что «нет»? В плюсы встроена только часть ООП, которой самому Qt и много кому еще не хватило. Где интроспекция, где метаобъектный протокол? В препроцессоре. Что у Qt, что у GObject. И оно всё на соглашениях, в Qt разве что в меньшей степени.

Спасибо, но я давно пишу с применением Qt и обо всём этом прекрасно знаю. Масштаб метамакросных костылей Qt не идёт ни в какое сравнение с костылями GObject, которые замахнулись на запиливание ООП в сишечку.

В GTK всё то же реализуется несколько более изящно.

Вот опять траллить начал. В сишечки нет некоторых фич, отсутствие которых, мешает нормально жонглировать «объектами». Я в кавычках пишу, потому что это не нормальные объекты. Например ручное инкрементирование счётчика ссылок через g_object_ref. Это особенно заметно, когда нужно передать «объект» в функцию. Приходится смотреть в документации что там: transfer full или transfer none. А ещё не забываем про floating reference. Всё это нужно постоянно держать в памяти, чтобы не выстрелить себе в ногу. Лучше эти усилия потратить на бизнес логику. А вот в крестах есть RAII. В общем, написание кода в ООП стиле на сишечке вызывает боль, а потому не нужно.

В плюсы встроена только часть ООП
Где интроспекция, где метаобъектный протокол?

С каких это пор вышеперечисленное стало обязательным набором ООП, без которого язык не сертифицируют, как ООП?

Вообще в крестах из-за одного RTTI ноют, а ты хочешь в runtime ещё интроспекцию засунуть. Жирнота. Молюсь, чтобы хотя бы в compiletime добавили. А то отсутствие в 2к20 хипстерского ORM для доступа к базе данных это позор.

GString != std::string

ноют

g++ -fno-exceptions -fno-rtti

Так нет никакого сертификата. Но то что обоим двум (и многим другим) это всё понадобилось, на что-то намекает. И то что в изначально объектных языках это всё сразу есть.

а ты хочешь в runtime ещё интроспекцию засунуть

Не хочу. Хочу чтоб C++ не приписывали возможности ООП кроме начальных и простейших. Или хотя бы не предлагали Qt в качестве избавления от «костылей на макросах».

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

Qbs был бы отличным вариантом решения проблем, но его закопали.

а почему закопали? qbs вполне себе потихоньку развивается…

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

Ну и будет нишевым. Если бы Qt его начали использовать по дефолту, это сильно продвинуло его. Но вместо этого будет костыльный cmake с паскализмами в языке. Тю.

https://www.opennet.ru/opennews/art.shtml?num=49519

https://www.qt.io/blog/2018/10/29/deprecation-of-qbs

Фактически это смерть проекта. Без финансовых вливаний он обречен на схожую судьбу с тем же Unity 8 или просто Unity.

https://code.qt.io/cgit/qbs/qbs.git/log/

https://code.qt.io/cgit/qbs/qbs.git/tree/changelogs/changes-1.16.0.md

https://store.pine64.org/?product=pinephone-community-edition-ubports-limited-edition-linux-smartphone

костыльный cmake с паскализмами в языке

Во-первых, это диалект лиспа; во-вторых, какие ещё паскализмы???

ключевые слова: begin, end, then и т.д. В нормальных языках используют фигурные скобки, а не буквенную писанину, которую нужно набирать тыщщщу раз на дню.

Мы на ЛОРе. Здесь экспертный анализ ЯП, включая грамматику и семантику, делается по символам, из которых лексемы состоят.

Фактически это смерть проекта.

Поживем - увидим (чертовски уж удобная штука).

//Эдуард, залогиньтесь уже

Эдуарду некогда. Недавно закончился календарь майя. Слишком много работы.

Все ядра ос «повседневности» написаны на си. Не вижу, чтобы современные линукс, винда и мак валились как вин95.

Ядра Windows и Haiku написаны на C++. В ядре Windows даже throw/catch работает. В 2020 году нет не единой причины использовать голый Си. В Си нет RAII и владеющих указателей, что приводит к битым указателям (use after free) и утечкам памяти. С++ может генерировать тот же машинный код при меньшем объёме исходного кода. Во всяких микроконтроллерах также без проблем можно использовать C++.

Правка: ядро Windows в основном на Си, но испльзовать C++ можно с ограничениями.

Qt, GTK пародия на ООП. Если нужен ООП, нужно брать язык с ООП, а не на макросах костыли лепить. Одна беда, Qt скурвился и LTS хочет начать зажимать.

ООП на С с макросами и указателями на функции лучше получается, чем дефолт в C++. можно нагородить какое-то подобие ObjC без ARC. C++ ущербен.

Чем лучше и зачем что-то городить?

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

Классы C++ лучше таблицы указателей на функции тем что компилятор проверяет совместимость типов и нельзя просто так перезаписать указатель на функцию. Это делает код безопаснее. Не говоря о том что таблицы указателей на функции выгладят ужасно. Исходники программ использующие GTK трудночитаемы в отличии от Qt.

Yeah, well, that’s just, like, your opinion, man.

Ты порешь чушь.

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

типо-безопасность не имеет отношения к ООП на самом деле.

Имеет и прямое. В Си невозможно реализовать эффективное ООП без небезопасного каста указателей, которое может привести к порче памяти.

несколько простых примеров, о которых ты скорее всего не слышал, т.к. кроме крестов ничего не видел:

class как объект.

протоколы и неформальные протоколы.

создание новых классов в рантайме.

интроспекция и рефлексия.

все это можно элементарно накрутить на коленке ДАЖЕ на C. заметь, я не предлагаю его использовать. просто ДАЖЕ на нем можно делать лучше чем на крестах.

Имеет и прямое. В Си невозможно реализовать эффективное ООП без небезопасного каста указателей, которое может привести к порче памяти.

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

мало того, в отличие от C++ – все это добро будет иметь стабильный ABI. который в C++ за все ~40 лет придумать не смогли.

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

В C++ можно писать код без единого static_cast/reinterpret_cast и из Си аналогов. Тип унаследованного класса совместим с базовым а this меняет тип при наследовании.

В C тоже можно. кто-то запрещает?

в отличие от C++ – все это добро будет иметь стабильный ABI

Уже давно в C++ используется Itanium ABI который доступен в GCC с 2001 года. В Haiku написанной на C++ стабильное ABI и старые программы дапускаются без перекомпиляции.

Покажи пример ООП Си кода без единого void* и кастов указателей.

Уже давно в C++ используется Itanium ABI который доступен в GCC с 2001 года. В Haiku написанной на C++ стабильное ABI и старые программы дапускаются без перекомпиляции.

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

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

Покажи пример ООП Си кода без единого void* и кастов указателей.

э нет дружок. это уже читерство. откуда взялось такое требование? в OOP безопасное приведение типов (наподобие dynamic_cast) это нормальное явление. во всех языках это применяется. ну кроме C++ конечно, в котором эта фича обычно отключена из-за оверхедов, и всякой кривизны, вылезающей с множественным наследованием реализации. а чтобы реализовать dynamic_cast, ты хоть усрись - а кастовать указатель «под капотом» придется. другой вопрос, что такой каст будет спрятан в фреймворке, и будет безопаснее некуда.

В C++ можно писать код без dynamic_cast и накладных расходов. Компилятор сам приведёт типы если вызывается метод базового класса. Си так не умеет.

я могу привести такой пример на C (по сути псевдокод, т.к. без конкретной реализации, но суть должна быть ясна – тот же GObject такое же имеет):

BaseType *objectOfBaseType = ..... init ....;
InteritedFromBaseType *object = InteritedFromBaseType_class->cast(objectOfBaseType) ; // <--- безопасный каст, возвращает NULL если тип невозможно привести

В C++ можно писать код без dynamic_cast и накладных расходов. Компилятор сам приведёт типы если вызывается метод базового класса. Си так не умеет.

ты просто не умеешь его готовить

Компилятор сам приведёт типы если вызывается метод базового класса

на кой хрен вообще нужно приведение типов при вызове метода базового класса?

безопасный каст, возвращает NULL если тип невозможно привести

В C++ это no-op, никакаго dynamic_cast не вызывается, проверка происходит во время компиляции.