Производительность Java, C и C++

Производительность создания прог на Java высока, а вот проги на C++ пишутся медленнее. Почему так, у кого какие гипотезы?

Почему люди используют в основном C++ или другие ЯП (например, C или Python) для написания десктопных приложений для оконной системы? Почему же получаются такие уродства, как например диалог сохранения файлов на Gtk3, в то время, когда тот же самый диалог на Gtk2 выглядит и работает лучше. Почему происходит явная деградация GUI Look&Feel, написанного на нативном ЯП, и как будто никто этого не замечает?

Так что здесь хотелось бы видеть не апелляцию к авторитетам, и не утверждения о том, что «я 20 лет пишу на Qt, это офигенский фреймворк, а moc называется Meta-Object Compiler», а какую-то элементарную логическую цепочку.

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

Я бы вот хотел понять, чего вам не хватает: мозгов или желания прочитать то, что здесь писали? Ибо речь шла не о том, что Qt отстой, а о том, что есть области, в которых Qt будет не лучшим выбором. И для таких областей люди разрабатывают альтернативы. Те же самые Imgui или Nana.

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

ага я тоже по твоему примеру начну щас ...

кто здесь?.. где я нахожусь..

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

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

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

По теме разговора у вас есть что сказать?

ну все таки.

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

Поскольку можно скормить С++ компилятору определение Qt-шного класса и получить нормальный .o/.obj-файл

очень смелое утверждение. этот obj файл наверно потом куда-то можно применить, кроме /dev/null?

впрочем как и утверждение что moc делает из «С++» «С++»: на самом деле он делает из «Qt» «С++» а это два разных языка, потому что то, что до moc, нельзя собрать С++ным компилятором и получить работающую программу.

очень смелое утверждение.

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

этот obj файл наверно потом куда-то можно применить, кроме /dev/null?

Можно вручную написать код функций, которые генерирует moc, скомпилировать их в отдельный .o/.obj файл, а потом слинковать с Qt-шными библиотеками.

на самом деле он делает из «Qt» «С++» а это два разных языка

Это всего лишь ваша вера. Ибо вы это «утверждение» даже не пытаетесь сфальсифицировать.

«Hello World» на 8 МБ — это сильно.

Можно вручную написать код функций

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

Ибо вы это «утверждение» даже не пытаетесь сфальсифицировать.

а зачем? если Qt С++ным компилятором в работающий код не компилируется?

я даже не знаю что тут ответить

Это было очевидно с самого начала.

а зачем?

Как раз затем, чтобы проверить истинность вот этого своего высказывания:

«если Qt С++ным компилятором в работающий код не компилируется?»

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

Можно вручную написать код функций

Можно вручную написать код функций

Можно вручную написать код функций

Т.е. аргументов больше нет?

Сравните трудоемкость сделать вручную реализацию virtual-функций или корректного вызова конструктора объекта при наличии исключений (а это то, что делал, например, Cfront) с ручной реализацией нужных Qt-шных функций на обычном C++.

Языковые фичи C++ вы, кроме как компилятором (хотя бы уровня Cfront-а) вы никак больше не реализуете. А вот для Qt можно создать свой генератор, который будет брать описания не из C++, а из каких-нибудь IDL-файлов. И генерировать при этом код, позволяющий использовать Qt.

по теме к которой вы в итоге сводите? про пукан? или...? в итоге опять приписывание мне чужого, и чрезмерный ЧСВ(уточню ваш)... не лопните «не очень любезнейший»... то что вас переговорить не реально это уже понятно, вам можно вообще спорить с самим собой, результат будет тотже...

1)итог Qt это тот же C++ , 2)moc компилятор, вопреки вашему чесанию языка, пукана, и прочих частей,(почешите сразу все, потрите мазью от зуда и думаю будет успокоение) 3)Qt как инструмент которым не надо затыкать все амбразуры не имеет аналогов, (можете снова почесать пукан , ну так для контроля.)

еще раз без словоблудия (может еще рукоблудия), берем ваши исходники -> moc -> все как с обычным c++.

никто не навязывает, машинный код компактнее.

moc компилятор, вопреки вашему чесанию языка

В очередной раз повторю вопрос: чем вы это обоснуете? Ну кроме проездов по личностям оппонентов?

не я это начал, нефиг охреневать в атаке, по вашей терминологии это генератор, для меня компилятор, спорить не буду это не имеет никакого практического смысла(ну если только покормить ваше ЧСВ)...

не я это начал

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

Производительность создания прог на Java высока, а вот проги на C++ пишутся медленнее. Почему так, у кого какие гипотезы?

на Java больше программистов, на C++ выше порог вхождения

Почему люди используют в основном C++ или другие ЯП (например, C или Python) для написания десктопных приложений для оконной системы?

никто не хочет издеваться над пользователем

Почему происходит явная деградация GUI Look&Feel, написанного на нативном ЯП, и как будто никто этого не замечает?

так и ява использует биндинги к нативным библиотекам

Вам не кажется, что пора заканчивать этот диспут? А то боюсь скоро будет что то типа - «Я тебя по Ип вычеслю». А стороны ни то что к консенсунсу не приходят, да еще и во флуд уходят.

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

ваш бред тут тоже никто не просил квакать...

так и ява использует биндинги к нативным библиотекам

Не во всём. Swing рисуется сам через Java2D.

Не во всём. Swing рисуется сам через

кмк swing выглядит в разы хуже GTK-3 и является издевательством над пользователем

Вам не кажется, что пора заканчивать этот диспут? А то боюсь скоро будет что то типа - «Я тебя по Ип вычеслю». А стороны ни то что к консенсунсу не приходят, да еще и во флуд уходят.

это же ЛОР )

А можно пример скриншота, где Swing своим явлением «поднасрал» в гармонично выглядящий набор нативных оконных программ?

А можно пример скриншота, где Swing своим явлением «поднасрал» в гармонично выглядящий набор нативных оконных программ?

ты комментарий-то читал на который отвечаешь?)

Я хочу конкретный и наглядный пример «издевательства над пользователем» видом Swing- компонентов GUI с комментариями где что сделано по-уродски и «выглядит в разы хуже Gtk3». Если пример не сможешь привести, значит с тобой, балаболом, и говорить не о чем.

Какой софт, кроме IDE есть на java под десктоп?

Из того, что я использовал: JDownloader (автозагрузка файлов с сайтов с ожиданием загрузки); SweetHome3D. Ещё есть RAW «конвертер» LightZone.

Но то, что на Java много пооулярного десктопного софта больше похоже на фантазии.

Ещё TuxGuitar, JabRef вспомнил, но это тоже не назовёшь распространённым. Возможно, частично OpenOffice.

SweetHome3D - стандартный Swing.

TuxGuitar не на Swing, а на SWT.

JabRef видоизменённый Swing, но старается чего-то там подстроить под систему:

> /usr/local/bin/jabref
20:20:19.575 [AWT-EventQueue-0] INFO  net.sf.jabref.migrations.PreferencesMigrations - Migrating old custom entry types.
20:20:19.711 [AWT-EventQueue-0] WARN  net.sf.jabref.JabRefGUI - There seem to be problems with OpenJDK and the default GTK Look&Feel. Using Metal L&F instead. Change to another L&F with caution.

OpenOffice - это C++, на Java там база данных HSQLDB и JDBC-драйверы доступа.

Но то, что на Java много пооулярного десктопного софта больше похоже на фантазии.

На самом деле много десктопного софта на Java. Но он либо заброшен и им никто не занимается (создавался для определённой ниши, работа выполнена - все свободны), либо никому не нужен по большому счёту, как например, JEdit, JFTP, у которых есть нативные аналоги.

SweetHome3D - стандартный Swing

Это уже на их совести (плагины предлагают писать на Java):

developing plug-ins requires special skills, and you should know how to program in Java with an IDE.

Swing, SWT - библиотеки для разработки графических интерфейсов пользователя на языке Java. Так что всё-таки на Java.

SWT — это JNI-обёртка над Gtk2 и Comctl3d.dll. Использует контролы соответствующих оконных систем. К Swing не относится никак. Все приложения на Swing выглядят одинаково что на *nix, что на win*. Нюансы могут быть только с отрисовкой шрифтов.

Для запуска приложения на Swing с нужной «шкуркой», которая эмулирует внешний вид и поведение контролов того или иного тулкита, в строке запуска java необходимо указать (например):

java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel MyApp

java -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel MyApp

java -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel MyApp

java -Dcom.sun.java.swing.plaf.motif.MotifLookAndFeel -jar MyApp.jar

Этим, если в самой программе жёстко не запрограммирована установка типа L&F (UIManager.setLookAndFeel(«javax.swing.plaf.metal.MetalLookAndFeel»);), обеспечивается отрисовка всех окон приложения в стилях соответствующих тулкитов (первые два системных не переносимы между *nix и win*). Однако, этого мало — заголовки окон (обрамление WM) останутся нативными. Заменить обрамление с WM на Swing заголовок можно только в коде самой программы. Как это сделать программисту, можно посмотреть в исходниках демонстрационных приложений к JDK; в исходниках JEdit это есть, так как допускает полную пользовательскую настройку своего внешнего вида. Пользователь же при запуске обычного Swing-приложения заменить отображения заголовков окон из командной строки запуска или свойствами среды не в состоянии.

Так вот, целосный GUI на Swing предполагает не только отображение содержимого окон в раскладке отрисовываемого тулкита (своего собственного, нативного, космического), но и заголовки окон, диалоги сохранения файлов и т.д. тоже представляются в стиле и поведении заданного Swing UI. У программистов есть выбор: показать программу на Swing такой, какая она есть без настроек, либо максимально приблизить её вид к нативному. У пользователя довольно ограниченный оперативный простор по изменению внешнего вида Swing-приложений, в файле <JAVA_HOME>/lib/swing.properties он может задать предпочитаемый класс UI:

swing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel

Лень читать полотно, выскажу свое мнение по это поводу.

• На джаве быстрее писать.
• На джаве легче делать массштабируемую архитектуру.
• Из своего собственного опыта скажу, что на производительность в последнее время мало кто смотрит при выборе языка (в малом и среднем бизнесе так точно). Разница в среднем раз в 5 между джавой и сями. Язык уже довольно долго существует и довольно таки неплохо был вылизан за это время. Тем более дешевле купить железо подороже, чем оплатить часы разработки.