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

Ну C++ и есть более низкоуровневый «Qt». Рефлексия, сигналы/слоты и тд.

коллекция неадеквата неспешно пополняется)

Ещё раз: Qt и imgui предназначены для абсолютно разных вещей.

Создание GUI - это абсолютно разные вещи??? facepalm.jpg.

Сказал человек, который не может прожить и дня, чтобы не поныть как уныл Rust

Пруф? Где я говорил, что Rust уныл?

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

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

Ну C++ и есть более низкоуровневый «Qt». Рефлексия, сигналы/слоты и тд.

Наглядный образец Qt головного мозга.

Просто насколько я понимаю C/C++ - там такой масштабируемости нет, и для распараллеливания придётся переписывать код. Нет?

так и в java большую часть надо руками писать, разве что может быть чем больше ОЗУ тем реже можно GC прогонять

Если ты посмотришь внимательно, но на самом деле на java пишуться всякие довольно узконаправленные приложения - IDE, редакторы, в основном технические тулы. В этих приложениях как раз есть горячие пути, так же как в серверном софте. Взять IDE - у тебя есть закешированное синтаксическое дерево, все объекты тут, память вся аллоцированна и ты сидишь его меняешь по чуть-чуть.SweetHome3D - тоже самое. На самом деле у любой штуковины есть горячий путь. У плазмы у той же - особенно. У нее есть пачка виджетов, они закешированны, объекты не меняются, память практически не перевыделяется, а вычисления которые они выполняют всегда одни и те же, то есть через несколько проходов JIT-а они уже будут сравнимы или быстрее руками написанного asm-ма.

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

на asm я бы все-таки не замахивался ) кмк не настолько java оптимизирует выполнение + есть значительный оверхед от виртуальной машины. Чтобы java даже на hot-path была быстрее asm, это нужно какое-то очень редкое сочетание алгоритмов на горячем пути

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

просто обычно люди хотят сделать свои pet-проекты хорошо, и часто подходят к выбору инструмента основательно. Но тут наверное да, просто «что знаю, на том пишу»

И да, MS Visual Studio на C# + WPF переписали.

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

Создание GUI - это абсолютно разные вещи?

Ваши познания в теме GUI поражают. Да, imgui не предназначен для создания GUI в том виде, в котором его создаёт Qt. Или вы в серьёз считаете, что либу в 10к строк можно считать альтернативой Qt, у которого ~2M строк?

imgui просто перерисовывает всё содержимое каждый кадр, в то время как Qt обновляет только необходимые области. Это если совсем по простому. Ну а затем у нас добавляется интеграции с ОС, поддержка системных контролов, всякие треи, global menu, сервисы и прочее. Ну и не будем забывать, что Qt, о Боже, умеет создавать виджеты, окна и диалоги, в отличии от.

Но а так да, 1 в 1.

Где я говорил, что Rust уныл?

Это не вы врываетесь в каждую тему о Rust с нелепыми попытками доказать, что он всем хуже C++?

Наглядный образец Qt головного мозга.

То есть в C++ есть рефлексия на уровне языка?

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

Да, imgui не предназначен для создания GUI в том виде, в котором его создаёт Qt.

Есть такая задача: создание GUI. И эту задачу Qt и ImGUI решают. По разному, но решают. На этом основании их можно сравнивать между собой. И, по определенным критериям, перевес будет на стороне ImGUI.

Так что сравнение двух фреймворков для разработки GUI — это отнюдь не бред, даже если эти фреймворки находятся в разных весовых категориях.

> Где я говорил, что Rust уныл?

Это не вы врываетесь в каждую тему о Rust с нелепыми попытками доказать, что он всем хуже C++?

Если я это так часто делаю, вас же не затруднит привести конкретную цитату. Хотя бы одну.

То есть в C++ есть рефлексия на уровне языка?

На уровне языка нет на данный момент. Как из этого следует, что C++ — это «низкоуровневый Qt»?

То есть в C++ есть рефлексия на уровне языка?

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

Есть такая задача: создание GUI. И эту задачу Qt и ImGUI решают.

Есть такая задача - написание сайтов. Можно писать html4 в блокноте, а можно использовать современные инструменты, типа js, html5 и тд. Оба решают одну и ту же задачу. И, по определенным критериям, перевес будет на стороне html4.

fixed

Вы не понимаете даже основ построения GUI, но Qt всё равно плохой.

Если я это так часто делаю, вас же не затруднит привести конкретную цитату. Хотя бы одну.

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

Как из этого следует, что C++ — это «низкоуровневый Qt»?

Ну вот в Qt есть рефлексия. И реализуется она транслированием диалекта C++ в обычный C++. Можно ли, по-прежнему, считать Qt «просто библиотекой»?

И, по определенным критериям, перевес будет на стороне html4.

Да, аналогия верная.

Вы не понимаете даже основ построения GUI

Вам виднее, конечно же...

но Qt всё равно плохой.

Вас же не затруднит указать, где именно я это сказал?

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

Прекрасно. Теперь дайте цитату из этого флейма, где я бы сказал что-то плохое в адрес Rust-а. Ну, что он уныл. Или что он во всем хуже C++. Там же несколько страниц, неужели ничего нет?

Ну вот в Qt есть рефлексия.

Прекрасно.

И реализуется она транслированием диалекта C++ в обычный C++.

Там нет диалекта C++.

Можно ли, по-прежнему, считать Qt «просто библиотекой»?

Речь, насколько я помню, шла не о том, считать Qt простой библиотекой или нет. А о том, что moc, а не C++ компилятор выполняет компиляцию программы на Qt.

Ну вот в Qt есть рефлексия. И реализуется она транслированием диалекта C++ в обычный C++. Можно ли, по-прежнему, считать Qt «просто библиотекой»?

да. но не просто библиотекой, а жирной библиотекой, в которой дофига всего ненужного.

В жизни вообще дофига всего ненужного и жирного. Наши предки и вовсе камнями и палками обходились, а их предки и без этого, да?

Вас же не затруднит указать, где именно я это сказал?

То есть последний десяток сообщений был не об этом?

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

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

Перефразирую: вы считаете что Rust не лучше C++, на примерах, в которых Rust явно лучше.

Заранее цитата:

Количество приседаний, которые нужно сделать в C++ и в Rust-е одинаково.

Там нет диалекта C++.

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

Речь, насколько я помню, шла не о том, считать Qt простой библиотекой или нет.

ТС пытался тролить именно в эту сторону.

А о том, что moc, а не C++ компилятор выполняет компиляцию программы на Qt.

Как вы говорите «смотря что под этим подразумевать». moc выполняет часть задач компиляции.

в которой дофига всего ненужного

Лично вам?

То есть последний десяток сообщений был не об этом?

Нет. Началось все вот с этого:

Надо бы только понять, альтернативу Qt в какой именно нише. Если GUI, то резонный вопрос «нафиг надо?» (как инструмент для GUI Qt далеко не всем нравится, откуда и появляются imgui/nana).

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

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

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

Перефразирую: вы считаете что Rust не лучше C++, на примерах, в которых Rust явно лучше.

Это не «перефразирую», это вообще совсем другое. Ну и, как я понимаю, подтверждений для «Сказал человек, который не может прожить и дня, чтобы не поныть как уныл Rust» и «Это не вы врываетесь в каждую тему о Rust с нелепыми попытками доказать, что он всем хуже C++?» не будет совсем?

Это просто набор макросов и препроцессор?

+ кодогенератор, который анализирует код на C++.

С тем же успехом C++ просто надстройка на C.

С того момента, когда так можно было говорить, прошло уже лет 30, как минимум.

moc выполняет часть задач компиляции.

Это опять перефразирование «на лету», как я понимаю, ибо начиналось все достаточно однозначно:

Поэтому «И каким же компилятором нужно компилировать программу на Qt?» - moc. Обычный компилятор выдаст ошибки.

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

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

да. но не просто библиотекой, а жирной библиотекой, в которой дофига всего ненужного.

Это в вашем с++ дофига чего нет.

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

там нет ничего лишнего.

Да там вообще почти ничего нет

и есть миллионы библиотек, которые делают отдельные нужные вещи

Да, миллион разного уровня несовместимости друг с другом разных велосипедов.

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

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

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

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

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

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

Хоспаде, бред какой. Может ты в ембеддед пишешь?

Потому что на десктопе я культю ставлю один раз и используется она всем, что не использует gtk/glib. Это уже слишком большой зоопарк. Тут нафиг не нужны миллионы дублирующих друг друга библиотек разной степени корявости. Тут нужен единообразный апи для написания софта.

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

Вы опять перевернули всё с ног на голову. Дальше уже просто скучно.

библиотеки должны быть маленькие

Полностью с вами согласен. Только в C++, «та-даааам», нет пакетного менеджера. Отсюда и растут ноги фремворков и комбайнов: Qt, boost, poco, etc. Любая либа на C++ рано или поздно превращается в монстра, ибо нужны нормальные строки, потом фс, потом еще что-то и всё приходится велосипедить и всё друг с другом не совместимо. Экосистема мертворождённая.

библиотеки должны быть маленькие

Полностью с вами согласен. Только в C++, «та-даааам», нет

пакетного менеджера.

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

Вы вообще не смогли доказать не одного своего утверждения. Ожидаемо слились по каждому пункту.

Вы вообще не смогли доказать не одного своего утверждения. Ожидаемо слились по каждому пункту.

Чья бы корова мычала. Так что на счёт дефайнов и php?

Так что на счёт дефайнов и php?

www.linux.org.ru/forum/development/13290413?cid=13293089

Я бы тебя больше и не дёргал, но

Вы вообще не смогли доказать не одного своего утверждения.
Ожидаемо слились по каждому пункту.

Чья бы корова мычала.

Лол. Кто бы говорил =)

Я бы тебя больше и не дёргал, но

Утверждение про дефайны и PHP вдруг стало моим? С чего бы мне доказывать ваши бредовые утверждения?

Утверждение про дефайны и PHP вдруг стало моим? С чего бы мне доказывать ваши бредовые утверждения?

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

Очень трудно с тобой говорить.

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

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

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

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

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

Кто бы говорил =)

Отлично, давайте посмотрим на то, что говорили вы:

Поэтому «И каким же компилятором нужно компилировать программу на Qt?» - moc. Обычный компилятор выдаст ошибки.

Сказал человек, который не может прожить и дня, чтобы не поныть как уныл Rust

Это не вы врываетесь в каждую тему о Rust с нелепыми попытками доказать, что он всем хуже C++?

Где же пруфы по каждому из этих пунктов?

ну вот не надо мне сказки рассказывать. всё было. был буст, в котором уже сто лет всё это было реализовано.

Boost появился лет на 6 позже Qt. Не помню, когда именно в Qt появилась поддержка многопоточности (может как раз в начале 2000-х), а вот свои строки и контейнеры там были с 90-х, когда Boost-а еще не было.

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

Вот так вот. Ты всё путаешь, а бред несу я.

Я было подумал что ты редкостный наглец из-за твоих заявлений об отсутствии доказательств товарищу RazrFalcon, а на самом деле ты просто путаешься. Извини. Больше тебя не побеспокою.

пакетный менеджер (внезапно) в плюсах не нужен.

Вы сильно ошибаетесь. Большому количеству C++ников, которые не могут решать свои проблемы сами, аналоги RubyGems, Maven, Cargo, Cabal сильно бы не помешали. А если бы такой аналог стал де-факто кросс-платформенным стандартом, то жизнь для всех C++ников стала бы гораздо проще.

Ну вот, вместо того, чтобы задать вменяемый вопрос еще один пустозвон слился. Что для LOR-овских анонимусов очень типично.

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

А у меня к тебе больше нет вопросов. Ещё что-то или я пошёл своими делами заниматься?

строки и контейнеры были в STL ещё когда я в Универе в 90-х училась. абсолютно точно. причём это год так 95-96. что касается буста, он появился не помню точно когда, но тоже точно до 2000 года. в 1999 году они начали вести строгую версионность, но до этого он был уже несколько лет.

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

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

В датах могу ошибаться, но вряд ли сильно.

Первые версии STL сформировались где-то в 1993-ем, когда он еще расшифровывался как STepanov & Lee. Где-то в это же время его начали проталкивать в стандарт C++. И свой привычный вид STL (вместе с расшифровкой Standard Template Library) принял году в 1996-97-ом, а стандартизировали его в составе C++ в 1998-ом.

Qt вышел в свет в 1995-ом, хотя разработка его началась еще в начале 1990-х.

Boost, как проект, начался то ли в 1999-ом, то ли в 2000-ом, а с 2001-го о нем стало широко известно.

буст начался гораздо раньше 1999. в 1999 он уже получил распространение и они начали серьёзно заниматься версионностью и поддержкой. в 2003 буст уже активно использовался в разработке. причём он сразу позиционировался как кроссплатформа. а культя стала кроссплатформенной только в 2005 году. и то там периодически были какие-то войнушки с лицензиями.

язык программирования - это язык программирования.

Система управления пакетами помогает использовать язык. И к самому языку иметь опосредованное отношение. Например, Ruby никак не завязан на RubyGems (т.е. не будет RubyGems сам Ruby никак не изменится). Аналогично и Java с Maven-ом.

Но вот Maven-а и RubyGems-а очень сильно упрощают работу со сторонними библиотеками, что идет Java и Ruby только на пользу. Глупо отказываться от такого.

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

буст начался гораздо раньше 1999

Гораздо раньше — это вряд ли. Официальная история помнит только с сентября 1999-го: http://www.boost.org/users/history/old_versions.html

Так что если он и стартовал в 1998-ом (что логично, т.к. после стандартизации C++), то это все равно не гораздо раньше.

а культя стала кроссплатформенной только в 2005 году.

Сказки только не нужно рассказывать.