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

Qt вмешивается в синтаксис языка

нет. они наколбасили говноскрипт, который перегоняют в плюсовый код. но никак на синтаксис плюсов это не влияет. не надо сочинять.

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

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

говноскрипт

Какая равница? Я тебе могу написать говноскрипт, который брейнфак будет транслировать в Форт. Будешь утвеждать что брейнфак это форт?
Фактически Qt это не C++.

убираем gcc. теперь давайте, «программируйте на кутэ». а я посмеюсь.

вот что такое язык программирования, а не детская песочница.

Ок, скармливаем GCC Qt-шные листинги. И что GCC скажет? Ничего хорошего.
Qt и С++ это разные языки. Да, похожи. Но и С и С++ похожи, но от этого не становятся одним языком.

но он компилится (внезапно!) в плюсы

А Vala это язык программирования или говноскрипт?

Qml не компилируется в плюсы. Он вообще никуда не компилируется. Разве что ты имеешь в виду всякие jit и прочее.

Qt и С++ это разные языки.

Откуда только такие эксперты с завидной регулярностью появляются. Qt — это не язык. 100500 раз данная тема на LOR-е обсуждалась.

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

А если придираться то ты бессовестно соврал, вот у меня нет ни одной версии gtk, но есть несколько qt5 приложений. kde нет.

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

маргинальщину мы оставим в стороне

Какая разница сколько она обсуждалась?

Кардинальная. Это в первые 10 раз можно было терпеливо объяснять людям их заблуждения. А сейчас остается разве что отправлять «малолетних дебилов» (с) в поиск.

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

Какой к херам синтаксис? На вход C++ному компилятору подается тот же самый исходник, что и moc-у. Это значит, что C++ный компилятор спокойно жует тоже самое, что и moc.

А теперь ответьте пожалуйста: вы и вправду такой дебил, что этого не видите?

О, а про moc и Qt != C++ ровно год назад был огромный срач на Хабре, который сегодня после свистопляски РКН'а уехал в Нидерланды и сменил домен, ну это просто к слову — ждём linux.org.com, так вот, хабработы заминусовали все адекватные комментарии: https://habr.com/company/infopulse/blog/327176/

На вход C++ному компилятору подается тот же самый исходник, что и moc-у

Тогда зачем он нужен, moc-то? :)

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

Именно. Без предварительной обработки моком компилятор Си++ справится? Нет? Почему?

Компилятор - да, справится. Линкер будет ругаться на undefined reference-ы из генерируемого кода

Без предварительной обработки моком компилятор Си++ справится?

Да.

Нет? Почему?

Может потому, что для вас нет разницы между компилятором и линкером?

Может потому, что вы не имеете представление, что скрывается за макросами Qt?

Может потому, что вы вообще не знаете, что Qt предоставляет набор макросов, а не новых ключевых слов?

Компилятор - да, справится.

Ок.

Не получится, весь топик только и именно про неё.

Да и вообще, зачем оставлять маргинальщину в стороне на маргинальном форуме? И почему вы говорите «маргинальщина» так, будто это что-то плохое?

Почему вы меня спрашиваете? Спросите EXL.

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

Да мне вообще насрать. Я ничего против Qt не имею и в обморок при его упоминании не падаю и про какие-то Zink не вспоминаю.

На вход C++ному компилятору подается тот же самый исходник, что и moc-у. Это значит, что C++ный компилятор спокойно жует тоже самое, что и moc.

А теперь рассмотрим экстремальный пример: синаксис и семантика паскаля, все макросы раскрываются в пустоту, компилятор с++ спокойно кушает исходник, а реальный код весь генерируется moc-ом, линкер разрулит. Ну как, это всё ещё стандартный с++ код?

KiCAD ещё на нём. На wx удобно было переходить после MFC, чем-то они были похожи... может теми же картами сообщений... хм... *задумался*

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

Они и позиционировали его как «кроссплатформенный MFC». Или я неправильно помню?

А теперь рассмотрим экстремальный пример

Кому нехрен делать, тот пусть купит селедку и морочит ей голову.

Ты отмораживаешься, потому что очевидный ответ - нет, это не цпп. А дальше встаёт вопрос о том, а где граница? На которой у тебя нет ответа по религиозным причинам.

ждём linux.org.com

Скорее linux.org.cz.

Вроде в шindows gtk не очень, поэтому сделали ещё один уровень абстракции.

потому что

Потому что:

a) обсуждается Qt и C++, а не какой-то абстрактный экстремальный пример, какого-то хера вытащенный из вашей головы на свет божий. Если вам этот пример дорог и близок, найдите сочувствующих и с ними его обсасывайте со всех сторон;

b) ситуация с Qt и C++ многократно обсуждалась. В частности, следующие аспекты:

- на вход C++ компилятору подается тот же самый С++файл, что и на вход moc-у. Что означает, что Qt _никак_ не изменяет синтаксис C++. Если бы изменял, то при компиляции пришлось бы давать исходник на вход moc-у, а уже выхлоп moc-а на вход C++ компилятору. И делать бы это пришлось для любого файла, в котором использовались бы «ключевые слова» из Qt. Но это, очевидно, не так;

- выхлоп moc-а можно написать самому. И вообще обойтись без moc-а.

Все это говорит о том, что Qt не делает из C++ другой язык программирования, что moc в Qt — это всего лишь генератор кода, коих множество, просто в качестве исходного описания он берет C++ные исходники, а не idl-файлы в случае CORBA или proto-файлы в случае ProtoBuf-а.

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

хз, помню что после MFC он у меня как по маслу пошёл, сам удивился. А так вполне годный тулкит.

а) Этот пример показывает, чем занимается moc с экстремальной точки зрения, для удобства рассуждений.

б) Всё это применимо к моему абстрактному примеру.

Следовательно, вывод «Qt не делает из C++ другой язык программирования» неверен.

Ну всё... их не остановить, это уже битва насмерть. Уже на личности перешли, уже религию упоминали... )))

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

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

Следовательно, вывод «Qt не делает из C++ другой язык программирования» неверен.

Да откуда на LOR-е столько людей с проблемами в логике?

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

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

Так что это приверженцам идеи о том, что «Qt — это не C++», следует сперва доказать свой тезис.

Если что-то по счастливой случайности компилируется компилятором с++, но после этого без внешней обработки не работает так, как написано, то это не с++.

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

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

Если что-то по счастливой случайности компилируется компилятором с++, но после этого не работает так, как написано, то это не с++.

Что в Qt работает не так, как написано?

Может в C++ еще и errno работает не так, как написано?

Я уже проиллюстрировал свою идею своим экстремальным примером

Про экстремальный пример выше уже было сказало.

Хотите пример другого языка, построенного поверх C++, посмотрите на Apple-овский Flow из FoundationDB: https://apple.github.io/foundationdb/flow.html

Вот там, насколько я могу судить, действительно расширен синтаксис C++ и добавлена новая семантика. И flow-файлы нужно сперва пропустить через actorcompiler, а уже затем выхлоп actorcompiler-а следует подавать на вход C++компилятора. И это принципиально отличается от того, что мы имеем в случае Qt.

Что в Qt работает не так, как написано?

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

flow-файлы нужно сперва пропустить через actorcompiler, а уже затем выхлоп actorcompiler-а следует подавать на вход C++компилятора. И это принципиально отличается от того, что мы имеем в случае Qt.

Принципиальное отличие - это отсутствие во flow-файле инклуда с пустыми дефайнами, дабы файл мог быть проглочен компилятором с++? Потому что в остальном всё то же самое - внешняя тулза генерирует дополнительный код, который нужно скормить компилятору с++.

не случайно в фаровском порте задействовано Far Manager успешно портирован под Линукс

Скомпилируй тот же код без использования moc

Етить-колотить, я что, разговариваю не просто с дебилом, но еще и малограммотным дебилом? Компиляция и линковка в C++ — это разные вещи. Скомпилировать C++ный код с Qt-шными «расширениями» можно без проблем.

Или по-твоему сигналы - это не расширение синтаксиса и семантики?

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

Принципиальное отличие

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

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

В случае с Flow мы это видим. Файл a.actor.cpp отдается actorcompiler-у, получается a.actor.g.cpp, который уже скармливается C++ компилятору.

Тоже самое мы видели в случае Cfront-а: файл a.cpp отдается на вход cfront-у, получается a.cpp.c, который уже скармливается C компилятору.

В случае с Qt этого нет в принципе. Если есть .hpp-файл с объявлением C++ класса, в котором задействуются Qt-шные «ключевые слова» signals и slots, то этот же .hpp-файл, без каких-либо преобразований отдается обычному C++ компилятору.

Ну и да, мой упоротый, но малограмотный «друг», на вопрос про errno сможете ответить?

Компиляция и линковка в C++ — это разные вещи. Скомпилировать C++ный код с Qt-шными «расширениями» можно без проблем.

Программу-то запускать будешь без линковки? Или слинкуешь с чем-то, что скомпилировано из того же самого исходника другим путём?

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

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

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

Ну а moc что делает? Если вместо использования отдельного файла с декларациями, из одного файла исходника получается два объектника, сделанных разными путями, это такая принципиальная разница?

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

Без вашего ответа на вопрос про errno не вижу смысла продолжать дискуссию.

А что с errno не так, это же просто макрос?

А что с errno не так, это же просто макрос?

Т.е. ответа не будет. Ожидаемо.

Пока вы не поймете, почему я вас спрашиваю про errno, вы не сможете понять, почему Qt-шный emit — это не расширение языка, а такой же макрос, как и errno.

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

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