Зачем нужен wxWidgets?

Но то, что объявленные сигналы без использования внешних утилит не имеют реализации - факт.

Из этого вовсе не следует, что Qt расширяет C++.

В C++ вы можете поставить только заголовочные файлы от какой-нибудь не header-only библиотеки, но не будете иметь .a/.so/.lib файлов. При этом свой код вы скомпилируете, но не слинкуете.

Это же не означает, что подобная библиотека расширяет C++.

ЛОР такой ЛОР. Зашёл и правда узнать зачем нужен wx, а тут про Qt.

Qt — это не язык

А vala - это язык?

Это же не означает, что подобная библиотека расширяет C++.

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

А vala - это язык?

Когда я последний раз смотрел на него, а это было довольно давно, это был язык, который, ЕМНИП, транслировался в C.

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

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

В контексте разговора про «Qt расширяет C++» это вообще не имеет значения.

Я могу на libclang написать тулзу, которая будет читать из моих C++ных исходников описания структур данных (скажем, унаследованных от определенного типа) и генерировать код для их сериализации/десериализации. Это вовсе не будет означать, что я расширил C++.

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

Какая разница один язык или разные?

Топик не читай, мозги не включай, сразу отвечай?

Зачем нужен wxWidgets? (комментарий)

Мне всё равно.

Ещё скажи, JS/CSS удобнее.

Если Qt за счёт moc расширяет C++, почему moc можно заменить обычными макросами?

Так нельзя же. Приходится повторять декларации. А не то можно сказать, что вызов moc можно заменить кодом, который он генерирует.

не будет означать, что я расширил C++

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

А почему не будет?

Вы утомили своими дебильными вопросами. Хотите, чтобы вас воспринимали всерьез, потрудитесь вменяемо обосновать почему это будет _расширением языка_.

Потому что ты добавляешь семантику, даже если код остаётся тем же самым. Как если бы в С добавить сборщик мусора - код тот же, но есть нюансы.

Потому что ты добавляешь семантику, даже если код остаётся тем же самым.

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

Так что я просил вменяемое объяснение, но вы не смогли, что меня не удивляет. Поэтому можно считать, что когда человек заявляет, что Qt «расширяет» С++, то это яркий показатель. В лучшем случае непрофессионализма и непонимания. Но, имхо, гораздо вероятнее — просто показатель дебилизма.

_любая_ библиотека «расширяет» язык

Есть разница между вызовом внешних функций, укладывающимся в рамки языка, и внешней по отношению к компилятору обработкой кода, которая как раз приводит к изменению языка. Да, чаще всего можно достичь той же функциональности просто библиотекой, но если некая функциональность реализована обработкой кода, то это изменение (расширение) языка.

и внешней по отношению к компилятору обработкой кода, которая как раз приводит к изменению языка

Вы не сможете показать это «изменение языка» в случае с Qt.

но если некая функциональность реализована обработкой кода, то это изменение (расширение) языка.

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

Яркий пример — declspec(dllimport/export). Вот это расширение языка. Или предлагаемые сейчас co_await/co_yield/co_return — это так же расширения.

У расширения есть ярчайшая лакмусовая бумажка: может ли обычный компилятор съесть код с расширением. Если не может, значит речь идет о расширении. Если может — нет никакого расширения языка.

Вы сейчас ответите, что вы с этим не согласны. Но мне пофиг, т.к. вы не можете аргументировать и показать наглядно, почему «расширение» языка, при котором сам язык не меняется, может считаться расширением языка.

может ли обычный компилятор съесть код с расширением

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

почему «расширение» языка, при котором сам язык не меняется

Я уже приводил пример с питоном в комментах.

Но это не так в случае с Qt.

Это вам так кажется.

Я уже приводил пример с питоном в комментах.

Вы много х*йни в комментариях написали, но ни одного реального примера не было.

Это вам так кажется

Тогда почему код с сигналами не запускается, если не слинковать выхлоп moc-а?

реального примера не было

Что считать реальным? Реально используемый код, а не гиперболизированный пример?

Вот похожая вещь из мира с++: директива override. Можно сделать #define override для старых компиляторов и сказать, что это С++98, и программа даже будет работать так же, если директива применена к месту. Но если компилировать с новым стандартом, появляются отличия.

Ну так вот, override является расширением языка или нет?

Тогда почему код с сигналами не запускается, если не слинковать выхлоп moc-а?

По той же самой причине, по которой вы не можете собрать свой код с библиотекой, от которой у вас есть только заголовочные файлы, но нет файлов реализации. Ваш К.О.

moc в Qt — это обычный кодогенератор, которых для C++ великое множество. Начиная от старых CORBA-овских IDL-компиляторов, заканчивая модным нынче protoc. Отличие moc-а от других кодогенераторов в том, что на вход он получает C++ный исходник, а не какой-то специализированный IDL.

Но если кто-то поставит себе цель сделать альтернативу moc-у, которая потребует не C++ный исходник, а отдельный idl (или какие-нибудь PCH/PDB-файлы), то вполне можно повторить функциональность moc-а и сгенерировать тот код, который и нужен будет для функциональности Qt.

И это принципиально отличается от настоящих расширений языка, таких как упомянутых выше declspec(dllexport), co_yield или даже принятого в C++11 range-for, для поддержки которых нужен будет транслятор исходного С++ного кода в какое-то другое представление (или, как в случае с declspec — сохранения специальной информации в объектных файлах).

Реально используемый код, а не гиперболизированный пример?

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

Ну так вот, override является расширением языка или нет?

По отношению к С++98 является. И вы бы не задавали таких дебильных вопросов если бы внимательно читали то, что я вам второй день подробно объясняю.

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

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

moc в Qt — это обычный кодогенератор, которых для C++ великое множество. Начиная от старых CORBA-овских IDL-компиляторов, заканчивая модным нынче protoc. Отличие moc-а от других кодогенераторов в том, что на вход он получает C++ный исходник, а не какой-то специализированный IDL.

Отлично, что в понимании этого мы сходимся.

Но если кто-то поставит себе цель сделать альтернативу moc-у, которая потребует не C++ный исходник, а отдельный idl (или какие-нибудь PCH/PDB-файлы), то вполне можно повторить функциональность moc-а и сгенерировать тот код, который и нужен будет для функциональности Qt.

Да, можно. Но к нашему спору это отношения не имеет.

И это принципиально отличается от настоящих расширений языка

Чем отличается-то? Возможностью альтернативы в виде idl?

По отношению к С++98 является.

Напомню один из предыдущих тезисов:

У расширения есть ярчайшая лакмусовая бумажка: может ли обычныйкомпилятор съесть код с расширением. Если не может, значит речь идет о расширении. Если может — нет никакого расширения языка.

Компилятор с++98 может съесть код с override и пустым дефайном. Ровно как обычный компилятор может съесть код с signal и соответствующим дефайном (правда, нихрена не слинкуется, но опустим этот момент). Почему же вы считаете, что в первом случае это расширение, а во втором нет?

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

Нет, вы опять говорите о каких-то своих тараканах.

Чем отличается-то? Возможностью альтернативы в виде idl?

Тем, что функциональность Qt достигается _обычными_ языковыми средствами без _расширения_ языка.

Компилятор с++98 может съесть код с override и пустым дефайном

И вы не получите эффекта от override. Никак.

Тогда как функциональность Qt можно получить и без moc-а.

И вы не получите эффекта от override. Никак.

С помощью внешней утилиты - легко.

Тогда как функциональность Qt можно получить и без moc-а.

Можно. Но не в рамках того же синтаксиса.

функциональность Qt достигается _обычными_ языковыми средствами без _расширения_ языка.

Давайте ускорим спор: какой аргумент, который вы применяете к Qt, неприменим к override (+внешняя утилита, если используем компилятор с++98), по вашему мнению?

С помощью внешней утилиты - легко.

Ануткать. После этого можно будет продолжить разговор.

Запускаем компилятор с++11 на том же коде, и он нам внешним образом выдаст ошибку, если что не так.

Запускаем компилятор с++11 на том же коде

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

Т.е. свой аргумент про компилятор от C++98 вы помножили на ноль

Компилятор с++98 - компилятор твоего кода

Компилятор с++11 - внешняя утилита, результат компиляции отбрасывается. Использован как пример внешней утилиты, делающей необходимые проверки для override.

Что именно не нравится?

Что именно не нравится?

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

Расширение — это такое изменение языка, которое не может быть поддержано обычным компилятором языка.

В случае с C++98 и override мы имеем именно это: обычный компилятор (т.е. компилятор C++98) не может должным образом обработать эту конструкцию. И нам нужен необычный, модифицированный компилятор/транслятор, в который специально добавлена поддержка данного расширения.

В случае с Qt мы всегда (всегда, Карл!) находимся в рамках того же самого C++ компилятора. Никаких изменений в компилятор для поддержки фич Qt вносить не нужно, обычный компилятор просто берет и транслирует C++ный код с использованием Qt-шных фич.

А если перефразировать, что в этом тезисе становится неверным?

В случае с C++98 и override мы имеем именно это: обычный компилятор (т.е. компилятор C++98) не может должным образом обработать эту конструкцию. И нам нужен необычный, модифицированный компилятор/транслятор, в который специально добавлена поддержка данного расширения.

В случае с C++ и signal мы имеем именно это: обычный компилятор не может должным образом обработать эту конструкцию. И нам нужен необычный, модифицированный (дополненный внешней утилитой) компилятор/транслятор, в который специально добавлена поддержка данного расширения.

обычный компилятор просто берет и транслирует C++ный код с использованием Qt-шных фич.

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

В случае с C++ и signal мы имеем именно это: обычный компилятор не может должным образом обработать эту конструкцию.

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

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

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

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

Так что куда ни плюнь, в случае с Qt нет никакого расширения языка C++.

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

Он мог бы и сразу .o выдавать, это к делу вообще не относится

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

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

В общем, я понимаю всё это так: ваша точка зрения состоит в том, что вы закрываете глаза на существование moc-а и генерируемый им код.

Он мог бы и сразу .o выдавать, это к делу вообще не относится

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

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

Еще раз: к вопросу расширения языка (именно _расширения языка_) это не имеет никакого значения. Тем более, что компилятор в случае C++ вообще не занимается сборкой программ (по крайней мере широкораспространенные компиляторы этого не делают).

ваша точка зрения состоит в том, что вы закрываете глаза на существование moc-а и генерируемый им код.

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

Qt расширяет возможности C++ разработчика (так же, как это делает какой-нибудь boost.fiber или boost.stacktrace). Но он не расширяет язык.

были бы более уместны

Я напротив, не вижу абсолютно никакой разницы.

к вопросу расширения языка (именно _расширения языка_) это не имеет никакого значения

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

Я напротив, не вижу абсолютно никакой разницы.

Меня это не удивляет.

Я считаю

По этому поводу уже был дан совет: купите селедку и морочьте ей голову.

будь это генерация кода для сигналов или просто проверка корректности аннотированного кода (как в случае с override)

Вы еще скажите, что clang code analyzer, coverity или PVS-Studio расширяют язык. А то ведь они тоже занимаются проверкой кода. В том числе и аннотированного.

Или что gsl (который guidelines support library) расширяет язык, поскольку в MS пилят статический анализатор, который на основании знания C++ Core Guidelines и семантики gsl проверяет корректность кода.

Любопытно, а вы считаете, что override является расширением языка исключительно если он реализован непосредственно в компиляторе, но ни в коем случае не во внешней утилите?

Я считаю, что вы за деревьями леса не видите. Например, поменяйте override на final. И учтите влияние final на результирующий объектный код. Или вместо override возьмите noexcept. Или constexpr.

Вы берете какой-то частный случай и на его основе пытаетесь натянуть сову на глобус.

Audacity же!

Вы берете какой-то частный случай

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