С++ 2018

Как успехи с лиспом поверх дотнета? Не забросил?

но разве кроссплатформенный софт не подразумевает интеграцию с целевой платформой

Это и есть те самые 5% кода.

хер забить на chromebook

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

это реальные четкие парни.
Мощный чел

Ребята, мы ему веру подрываем... не нааадооо...

Если взять мой любимый Microsoft, то это, конечно же, C#

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

Был вообще шанс пересобрать программу, сложнее hello world, без тонны #ifdef?

Нет. Как и сейчас, собственно говоря.

Я так делал только когда начинал его учить. Потом стало понятно, что чем проще пишешь, тем лучше.

Действительно всё кроме GUI

Вот только кроме удобного формошлёпства в C# нет ничего хорошего.

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

Just as planned

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

Лучше бы всё сделали через условный systemctl и написали GUI для хомячков.

Перемножение матриц - синтетическая дрочильня.

Нет.

В реальном мире оно встречается в основном в шейдерах на видеокарте

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

Пишу новый продакшн код на С++ с распределенной командой в рамках транснациональной корпорации. Сегфолтов не было

uniqie_ptr буквально бесплатен

http://gchandbook.org/

Прочитай вот эту книжку и там тебе расскажут, что видимость из корней потоков - аппроксимация «нужности» объекта. Настоящее определение нужности - нерешаемая задача. И эти языки текут запросто - попросту сохраняя ссылку в укромном месте какой-то забористой структуры. Я уже не говорю о истощении дескрипторов и прочих вещах. Конечно чтобы этого не происходило, придумали определенные практики программирования. Так же как и в языках без GC есть свои практики

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/csharpcore...

Погуглил

Тогда мы завершили синхронизацию.

Может быть.

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

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

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

я вообще на C# пишу, на .Net Core, который кстати и на Линуксе есть

В Debian не вижу родного пакета.

А и да, у MS вообще то весь .Net Core в опенсорсе

Вместе с портабельным GUI?

Но будет Windows-only конечно. Переводить WPF на уродскую архитектуру иксов и ogl я бы не взялся ни за какие деньги.

Ясно.

Но WPF и некоторые еще другие вещи типа AD - технологии чисто физически виндовые

А Samba не умеет AD под линуксом?

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

разрастающимся монструозным

Посмотри внимательнее на Джаву.

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

О! Тогда не мог бы ты объяснить, как сделать софтовый блиттинг с прозрачностью? Прочитать битмап с экрана, скопировать на него все нечёрные пиксели из спрайта (с нужными деформациями), скопировать обратно. С разумной частотой кадров. Можно сперва копировать, потом масштабировать. Но быстро, и не пользуясь системной поддержкой прозрачности. https://github.com/tkzv/OpenXCOM.Tools/blob/28fb294da7e723e0f860d1dd3f56b19a9... https://github.com/tkzv/OpenXCOM.Tools/commit/28fb294da7e723e0f860d1dd3f56b19...

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

Ха! ХА! Такого кала нам не надо, это я тебе как пользователь дрисни на электроне и джаве говорю. И эту проблему ты не решишь увеличением «мощности» железа.

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

когда уже закопают

моё мнение, никогда. С++ хорош прежде всего тем, что на нём уже ты можешь написать любую систему/ПО в том виде, в котором ты её представляешь. И она будет обладать теми свойствами, которые ты в неё заложишь. Это промышленное производство программного продукта. Когда «изобразительность» языковых поделий на 25 месте вместе с «эффективностью» программирования и «лёгкостью» освоения.

«Если взять мой любимый Microsoft,» - это что, шутка, троллинг или убеждения ТС?

Только вот указатели и объекты на стеке особого прироста производительности не дают.

Производительность просаживается из-за следующих вещей: 1) виртуальная машина, 2) нехватка оптимизации под конкретную архитектуру, 3) сборщик мусора 4) динамическая типизация.

C# с грехом пополам может отказаться только от последнего из 4-х пунктов.

Теоретически, возможно написать фронтенд C# для gcc, который позволит хотя бы приблизиться по производительности к С, однако это автоматически будет означать отказ от .NET и сборщика мусора, поэтому на практике это никому не интересно, раз даже Java фронтенд для гцц не потянули (а он был).

Какие конкретно проблемый у Qt по вашему мнению?

Например, на маке он не поддерживает ввод дополнительных знаков через зажатую клавишу. На форумах anki треды про это с года так 2013го, воз и ныне там - фреймворк не поддерживает. https://bugreports.qt.io/browse/QTBUG-71394

Да, я выше писал, что с маком всё плохо.

Виндовый Ribbon довольно удобная штука, как и куча других вещей. Интеграция с Microsoft Surface Dial, как пример.

Сделай мне такое на Qt. Ответ «ненужно» не принимается.

Чего нет? И что надо? C# 7 или вот скоро выходящий 8 по фичам обогнал чуть не скалу.

Не рантайма, еще раз. Просто WPF это условно говоря биндинги к Direct3D+Direct2D. Чтобы портировать его на линупс надо портировать туда Direct3D сначала.

виртуальная машина

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

нехватка оптимизации под конкретную архитектуру

Как будто с плюсами такого быть не может.

сборщик мусора

Еще раз, сборщик мусора по сравнению с «умными указателями» и malloc - производительность даже повышает.

Чего нет?

Работы с железом не через жопу.

И что надо?

Отсутствие анальной привязки для прикладной разработки к MS Windows. Нормальная работа с CLI, а не то паскалеподобное убожество, которое там есть.

Вот и вся инфраструктура C# биндинги. Это плохо.

Еще раз, сборщик мусора по сравнению с «умными указателями» и malloc - производительность даже повышает.

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

https://www.devmachines.com/qtitanribbon-overview.html

странные и не очевидные вещи.

А можно пример-два? Любопытно

Отсутствие анальной привязки для прикладной разработки к MS Windows.

В каком месте эта привязка в случае .Net Core?

Нормальная работа с CLI, а не то паскалеподобное убожество, которое там есть.

https://docs.microsoft.com/en-us/dotnet/api/system.console.openstandardinput?...

.Net не исполняет байт-код, он сразу компилирует в нейтив.

Ох, лол

Programs written for .NET Framework are compiled into Common Intermediate Language code (CIL), as opposed to being directly compiled into machine code. During execution, an architecture-specific just-in-time compiler (JIT) turns the CIL code into machine code.

Там банальный JIT вместо нормального оптимизирующего компилятора

Как будто с плюсами такого быть не может.

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

Еще раз, сборщик мусора по сравнению с «умными указателями» и malloc - производительность даже повышает.

вы ещё раз не привели пруфов

Еще раз, сборщик мусора по сравнению с «умными указателями» и malloc - производительность даже повышает.

Я тоже бы послушал как умные указатели просаживают производительность. Давай начнем с unique_ptr. intrusive_ptr я не мерял, shared_ptr действительно медленнее mark-sweep, но я вот сходу даже не помню часто они у нас в коде встречаются.

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

Там банальный JIT вместо нормального оптимизирующего компилятора

Байткод компилируется сразу при загрузке assembly (dll/exe). Машина не исполняет его. Есть еще AOT, это когда весь код в ассембли прекомпиливается вообще заранее. Так например устроены все системные библиотеки Net Framework, стдлиба, WPF, итд. Но и самому так можно. google://ngen.exe

В Core немного по другому, но суть та же https://github.com/dotnet/coreclr/blob/master/Documentation/building/crossgen.md

вы ещё раз не привели пруфов

Я стопицот раз это доказывал и показывал еще в своем жж. Лень повторяться. Гугли про локальность памяти, фрагментацию, итд. А про умные указатели вообще говорить нечего даже, это помоему очевидно. Но можешь также погуглить «reference counting vs gc performance»

unique_ptr

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

С ходу тяжело вспомнить, учитывая что 2 последних года я юзаю питон и кресты, тем более странными они мне казались лет 8 назад, когда я только-только с ним начал возиться. Главное почаще стыковать управляемый и неуправляемый код и встретится много всего занимательного. Самое странное что я видел было когда делал отрисовку на Windows Forms через GDI+ ЕМНИП, и при определённых параметрах приложения (уже не вспомню что там было необычного, но что-то было редко используемое) наткнулся на очень интересный баг (кстати, ХЗ, пофиксили ли его, надо будет поковырять свой старый код, вроде я сохранял его где-то на флешке), связанный с тем что меню (не контекстное, а обычное), которое как бы не должно никак реагировать на рисование на отдельном объекте пропадало с концами, не перекрывалось рисунком, а именно исчезало с концами.

А из того что там не баг, а фича, так это округление которое там по дефолту. Ну и что-то типа такого, может порадовать девелоперов до глубины души

static void Rec(int i)
{
    Console.WriteLine(i);
    if (i < int.MaxValue)
    {
        Rec(i + 1);
    }
}

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

RAII не бесплатно.

Все не бесплатно. Но при чем тут RAII?

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

Джампа? Ты о чем? Какие вырожденные случаи? unique_ptr это вырожденные случай? Или реализация malloc, которая как GC берет параметр mx(не знаю как он называется в .Net) и выделяет себе столько памяти, сколько там указано и никогда не отдает системе? Это конечно хорошо, что ты слышал про reference counting, но он тоже разный бывает для случаев потоко(не)безопасности самого счетчика, да и то из-за того, что Intel все еще не сделал дешевый вариант атомарного инкремента(если мне не изменяет память, то он занимает 40 инструкций).

Не вся, а виндовый UI. Главная проблема портирования WPF в том, что в Direc** все интегрировано друг с другом, там все строится на DXGI, и соответствующих концепциях, сурфейсы там, которые можно шарить из Direct3D в Direct2D и даже в DXVA(видео чтобы показывать), и так далее.

unique_ptr это вырожденные случай

unique_ptr основывается на RAII а оно дорогое. Это как если все оборачивать в try {} finally {} Вырожденный случай это когда оное можно заменить на if+goto, а не использовать инфраструктуру обработки исключений и защиты от stack unwinding

Или реализация malloc, которая как GC берет параметр mx(не знаю как он называется в .Net) и выделяет себе столько памяти, сколько там указано и никогда не отдает системе

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

unique_ptr основывается на RAII а оно дорогое.

У меня для тебя плохие новости, ты видимо не читал реализацию. Оверхед для unique_ptr в clang/gcc относительно malloc минимален. Относительно конструктора/деструктора оверхед можно считать погрешностью. Но тут есть важный момент - пустой unique_ptr бесплатен по памяти, а вот любой объект в языках с GC имеет не нулевой размер(если память не изменяет что-то около 18 байт для Java).

Это как если все оборачивать в try {} finally {} Вырожденный случай это когда оное можно заменить на if+goto, а не использовать инфраструктуру обработки исключений и защиты от stack unwinding

По-моему, ты не понимаешь что такое unique_ptr. И да, мы не используем stack unwinding и экспешены. Правда в одном треде я уже наврал про перформанс различных libunwind и к своему стыду так и не перемерял производительность.

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

Да, тут ты прав, хотя я бы сказал, что 99.99999999999%, ибо только в FB/Google работает больше 100k разработчиков из которых уже 1k набирается. И эти 99% предпочитают GC не потому, что C++ говно, а потому что для их задач не критично использование этого самого GC.