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

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

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

история культи. я её не изучала. это википедия культи сообщает такие факты.

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

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

Это опасное заблуждение. У переносимого языка должна быть система управлениями зависимостями, которая не привязана ни конкретным ОС, ни к пакетным менеджерам этих ОС.

В C++ этого нет и при кросс-платформенной разработке приходится разбираться с этим всем самостоятельно.

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

Получалось и более чем получалось. Как раз за счет того, что до 2005-го у них Qt/Windows была доступна только под коммерческой лицензией.

Сама же по себе поддержка кросс-платформы (т.е. Unix-ов и Windows) в Qt была чуть ли не с самого начала.

потом они её бросили на произвол опенсорца.

Потом TrollTech был куплен Nokia, которая преследовала свои цели. А потом Qt досталась Digia, которая умудрилась выстроить вокруг Qt очень хороший маркетинг. И заставила Qt динамично двигаться в перед.

При этом Qt продолжает продаваться.

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

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

Да уж, настало время окуительных открытий.

Сама же по себе поддержка кросс-платформы (т.е. Unix-ов и Windows) в Qt была чуть ли не с самого начала.

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

но не суть. я уже не хочу обсуждать это жирное УГ. оно не достойно такой траты времени. ненужно и обсуждать ненужно :)

почему-то история об этом умалчивает.

Какая-такая история?

In the summer of 1990, Haavard Nord and Eirik Chambe-Eng (the original developers of Qt and the CEO and President, respectively, of Trolltech) were working together on a database application for ultrasound images written in C++ and running on Mac OS, Unix, and Windows.[1][84] They began development of «Qt» in 1991, three years before the company was incorporated as Quasar Technologies, then changed the name to Troll Tech and then to Trolltech.[1]

The toolkit was called Qt because the letter Q looked appealing in Haavard's Emacs typeface, and «t» was inspired by Xt, the X toolkit.[1]

The first two versions of Qt had only two flavors: Qt/X11 for Unix and Qt/Windows for Windows.

Это все из Wikipedia: https://en.wikipedia.org/wiki/Qt_(software)#History_of_Qt

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

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

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

Ануткать, удиви меня, детка.

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

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

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

Браво, с таким пафосом выжать из себя несколько пустых банальностей — это мощно, ящитаю.

Уж думал здесь будут какие-то рассказы, как приходилось бороться с платформами с 9-ти битовыми char-ами. Или с DSP, на которых все типы (хоть char, хоть long) были 32-х битовыми. Но не случилось.

это тоже было. правда, не 9 битовые, а 32-битовые чаще встречаются. и на FPGA я писала. там вообще нет ни байтов, ничего. как сам сгруппируешь сигналы в обработке - так и будет. и много чего ещё. но там нет С (точнее, есть но он там неэффективен), поэтому не суть.

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

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

У вас проблемы с восприятием?

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

Если что-то подобное появится над C++, частью языка это не будет. А вот помощь для менее упоротых и более здравомыслящих разработчиков будет и еще какая.

Если что-то подобное появится над C++, частью языка это не будет.

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

и поэтому Qt - не «язык программирования».

Думаю, что определенной категории C++ников, которые в C++ ничего кроме Qt не пробовали и не видели, этого просто не объяснить. У них даже moc — это компилятор. А Q_OBJECT и emit — не специфические для библиотеки дефайны, а новые языковые конструкции. Тут, боюсь, даже медицина бессильна.

У них даже moc — это компилятор
расшифровка moc - метаобъектный компилятор, прямо в названии

Просвятишь, что же это на самом деле?

А Q_OBJECT и emit — не специфические для библиотеки дефайны, а новые языковые конструкции.

А foreach - новая языковая конструкция, или дефайн?

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

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

Просвятишь, что же это на самом деле?

Кодогенератор.

А foreach - новая языковая конструкция, или дефайн?

Вы совсем дебил или только на LOR-е? https://github.com/qt/qtbase/blob/4351c2af45768bcb68b5bb996c1fb6e24dc9556b/sr...

А foreach - новая языковая конструкция, или дефайн?

это синтаксический сахар. без него итераторы прекрасно работали и работают.

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

RAII - для неосиляторов? Так и запишем.

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

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

И зачем придумали Си? Сто лет без него жили-не тужили, тем более что на ассемблере можно писать вполне.

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

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

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

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

И удаляют все throw.

Современные оптимизирующие компиляторы уже во многих случаях генерируют asm код, который эффективнее написанного руками. JVM например умеет всякие хаки на SSE делать когда надо и трюки для избежания блокировок там, где они на самом деле нужны. Она умеет понимать, когда блокировка захватывается тем же самым тредом, что и в предыдущий раз и не брать Ее по новой, а просто слегка придерживать с прошлого раза - biased locking. Много таких штук. То есть конечно если написать синтетический тест, то руками напишешь asm/C, что бы он был быстрее. С тем же синтаксическим деревом - в плюсах или сях тебе надо будет память перевыделять при его изменении, в случае JVM она 99% вероятности уже выделена и оверхед на создание объектов будет близок к нулю. Да, за это расплачиваешься тем, что оно жрет кучу памяти, но я всегда выбираю скорость против памяти. Опять же, можно посмотреть на HFT - область где всегда идёт гонка за минимальный latency. Так там почти везде Java. Их модель - выделить пачку памяти заранее, руками, вне кучи (всякие структуры данных на memory mapped files) чтобы избежать оверхеда на gc, натравить ботов для прогрева и потом в продакшн. Про измерение производительности лучше посмотреть презентации от того же Шипилева и понять, что спор этот беспредметный :)

Языки для разных задач, разных ниш. Сравнение некорректно.

Кто в здравом уме решит создавать приложение со сложной бизнес-логикой на Си++? Или системную утилиту на Java?

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

И я бы не стал переоценивать так называемый «горячий путь». Каких только подобных статей не писали в прошлом! И еще напишут.

Тут такое дело. Есть принцип: «выигрывая в малом, обычно проигрываем в большом». Можно интерпретировать так: выигрывая в малом на байтиках (ред. подставить нужное) в Си++, плюсовые программисты часто проигрывают в случае сложных приложений тем программистам, которые создают подобной сложности системы на Java. Диалектика во всей красе

А ничего что у Q_OBJECT и emit семантика выходит за пределы любых дефайнов?

Никуда она не выходит. Обычные макросы, которые используются обычным способом для обычного упрятывания бойлерплейт-кода «с глаз долой». Тысячи библиотек так делают, только никому в голову, например, не приходит называть Boost.Fusion или Boost.Hana надмножеством C++.

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

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

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

Нет языка Qt, нет такого надмножества языка C++. Программирование — это инженерная дисциплина и программист, будучи инженером, должен понимать что и как работает. Если программист, по незнанию или из-за врожденного дебилизма этого не понимает и воспринимает фреймворк в качестве нового языка (пусть даже и диалекта), то программирование из инженерной дисциплины превращается в шаманство: здесь такой ритуал выполнили, здесь такой, здесь это заклинание произнесли, здесь сорок поклонов отвесили и... Хорошо, если заработало. А если нет, то начинается «явсесделалаононеработает», «STL — говно, никаких гарантий», «С++ — мертворожденный язык с мертворожденной экосистемой» и т.д. Хотя проблемы вовсе не в языке, в головах у тех, для кого moc — это компилятор, который компилирует Qt-шные программы.

А как же Cabal hell?

Никуда она не выходит

Если бы не выходила, то и реализовалась бы средствами дефайнов или чего-то еще из C++. Ан нет, не может.

Fusion и Hana работают (выражаются) в рамках C++, кутешный foreach тоже. А range for - нет, это (относительно C++03) новая языковая конструкция, хоть и похожая на foreach. Если понятно почему, то понятно и то что Q_OBJECT - новая языковая конструкция. На нее целая рефлексия навешана (если верно помню), и это «обычный макрос»?

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

* «The keyword [foreach] is a Qt-specific addition to the C++ language» - из документации Qt, например.

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

Если бы не выходила, то и реализовалась бы средствами дефайнов или чего-то еще из C++. Ан нет, не может.

Послушайте, формальный вы наш, я программирую на C++ достаточно долго, чтобы застать инструменты, которые требовали от разработчика включать в свои классы что-то вроде:

class My {
  PERSISTENT(My)
  ...
};

В итоге программисту приходилось:

1. Делать IDL файл вида:

type My {
  attr name: string;
  attr surname: string;
  ...
}

2. Скармливать этот IDL файл отдельному IDL компилятору. Получать на выходе несколько C++ных файлов, например, My_interface.hpp и My_implementation.cpp.

3. Потом нужно было подлючать в свой hpp-файл сгенерированный IDL-компилятором My_interface.hpp:

#if !defined(MY_HPP)
#define MY_HPP

#include "My_interface.hpp"

class My {
  PERSISTENT(My);
  ...
};
...
#endif

Но при этом никому не приходило в голову называть всю эту хрень новым языком или диалектом C++. Может быть потому, что в начале 90-х малолетних дебилов (с) в программировании было на порядки меньше, чем сейчас.

Qt-шный moc работает по точно таким же схемам. Только a) ему не нужнен отдельный IDL-файл и b) у него Q_OBJECT даже не затачивается под конкретный класс (что делает задачу еще проще).

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

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

Ну а dll hell многих останавливает от размещения кода в dll/so-шках?

Использование любого инструмента можно довести до абсурда. Но в C++ и инструмента-то такого пока нет (по крайней мере, общераспространенного).

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

Продолжать действительно неинтересно, да и негигиенично.

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

Нет, но там есть удобный инструмент для работы с потоками.

Моя, по-моему, тоже.

Нет. У вашей «точки зрения» проблемы с аргументами.

пакетный менеджер не нужен
unique_ptr не нужен
RAII не нужен

Тебе на пенсию по вредности давно пора. Годы колхозного embedded из кого хочешь в 40 лет сделают брюзжащего старика.

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

не такой уж он и колхозный. ну, разве то считать колхозом Канаду и США. да и банковское оборудование наше поставлялось в 15 стран, включая Швецию, Францию. так что я хорошо понимаю, что в языке программирования действительно нужно, а что лучше бы выкинуть и никогда не вспоминать.

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

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

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

Скажите, а в 2017-м году еще осталось программирование без слов «продукт», «бабки», «продажи»? Я пошел в программирование, так как все вышеперечисленное мне глубоко омерзительно. Я вообще кто, программист или торгаш?

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

Что именно в современных плюсах:

a) ведет к монстроузности?

b) ведет к потере оптимальности?

это замечание было к вопросу о «колхозе». кстати, Гознак тоже на нашем железе работает. так, между прочим.

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

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

вставка всяких ненужных проверок, которые не отключаются.

Каких проверок?

большинство фич с RAII.

RAII в C++ с самого-самого начала, вообще-то.

В современном-то C++ что не так с производительностью?

это замечание было к вопросу о «колхозе»

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

не надо засорять сишные вещи попсятиной, которая там не нужна даром

Не было ни Heartbleed, ни Cloudbleed.

Вот и для GNU/Linux программы в существующих DE нужно переписывать на Java или C#.

Как хорошо, что этого никогда не будет.

Не зарекайся.

Red Hat (который активно работает в т. ч. и над Java/JVM) сделает какую-нибудь принципиально новую DE для современных компьютеров и уже завтра Canonical Ltd. начнёт брать оттуда наработки (как они делают сейчас с GNOME 3), послезавтра какой-нибудь Debian сделает это «принципиально новое DE» дефолтным (как это получилось с GNOME 3), а «через неделю» будет такая картина:

http://esxi.z-lab.me:666/~exl_lab/screens/systemdwins.png

Уйду на фряху тогда.

Не было ни Heartbleed, ни Cloudbleed.

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