Опять бомбит за кресты

Пфф, опять меряют С++ мерками стандарта С++98…

С использованием современного функционала стандартов С++11,14,17 можно писать код, который от ваших там .NET не очень-то и отличается.

vector<pair<int, double>> vect = {{1, 2.0}, {3, 4}};

for(auto &[int_v, dbl_v]: vect)
    cout << int_v << " " << dbl_v << endl;

Добавить до кучи огромную базу кастомизируемых надстроек над IDE вроде автоматических линтеров кода (линтер - средство, не допускающее до коммита код, не удовлетворяющий определенным code conventions), кастомизируемых форматтеров вроде clang-format, uncrustify, и т.д., целую гору всевозможных библиотек, доступных по умолчанию в собранном виде в любом дистрибутиве Linux, что позволяет никогда не писать велосипеды, огромный выбор качественных и кастомизируемых редакторов кода и IDE (VS, Atom, Sublime, VSCode, Code::Blocks, QtCreator, Eclipse, …), - получим очень даже неплохой результат.

А еще в С++ есть Qt. Ничего лучше сигналов и слотов для реализации инкапсуляции не придумали (для них еще есть Boost::Signals2). Ненавижу обилие синглтонов в большей части виденных мной приложений - хоть на .NET, хоть на Java, хоть на С++. А сигналы/слоты позволяют их убрать. И в Qt еще графический фреймворк, который удобнее, практичнее, и функциональнее всех WPF, вместе взятых, имеющий поддержку CSS и JavaScript для реализации интерфейсных свистелок с перделками, если уж сильно захотелось.

А еще в С++ есть нативный OpenCV, который общепризнан как самая эффективная (в том числе, в плане производительности), полная, и крайне продуманная библиотека работы с графикой.

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

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

P.S. Да, Qt и OpenCV есть еще в Python.

P.P.S. Вышеописанные плюшки и радости с форматированием и прочим есть и в .NET. Для C#. Любые другие языки платформы .NET не имеют никаких шансов с ним конкурировать. Что, кстати, минус. А если уж пишешь на C# - будь добр, используй монструозную, отбитую на всю голову по размерам и тормозам Visual Studio, из которой давно пора выкинуть 90% никем не используемого функционала. А еще нормальной скриптовой системы сборки в ней нет, и поэтому при настройке проекта вместо православных CMake/qmake приходится пользоваться богомерзкими окошками, в которых черт ногу сломит при попытке найти хоть что-то. А еще есть UWP, который пиарился как “СОВЕРШЕННО НОВАЯ ПРЯМ КАК БОЛГЕНОС СИСТЕМА С НОВЫМИ ОКОШКАМИ И НЕСКУЧНЫМИ ОБОЯМИ ПРЯМО ИЗ МАГАЗИНА”, который не нужен, и на который потратили миллиарды долларов совершенно впустую. А еще Микрософты сейчас остервенело портят все свои Roslynы, .NET Core, и прочие великие достижения под линуксы, т.к. поняли, что десктоп-разработка в мире больше никому не нужна, а в мире бэкэнда царит линупс. Слегка опоздали, как мне кажется. Но это уже ИМХО.

P.P.P.S. В С++20 нас ждут std::ranges, корутины, и модули. Буду вообще жить аля питонист.

/subject

1 лайк

Есть один существенный показатель, который всё ещё сильно в пользу любого .NET-языка по сравнению с C++ — это размер стандартной библиотеки. Ясно, что C++это Тьюринг-полный язык, можно самому всё написать, или найти нужную библиотеку — с этим тоже проблем не будет (в отличие, скажем, от многих академических языков). Но всё же — это один дополнительный шаг. И в зависимости от библиотеки он часто связан с некоторым количеством боли по её сборке, добавлению в зависимости проекта (нормальных пакетных менеджеров так и нет в C++, кстати, а под .NET есть NuGet), а также выяснению лицензионных ограничений. Многие реалистичные .NET-приложения могут быть реализованы без раздумий об этом.

2 лайка

Да, отсутствие пакетного менеджера - главный камень в крестовый огород. Немножко нивелируется тем, что его обязанности зачастую выполняет пакетный менеджер ОС - но только в Linux, и далеко не всегда :frowning: Впрочем, смотря где искать - тот же AUR полон радостями на все случаи жизни.

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

Это ж чё надо с бедной программой делать? За 5 лет прода на С++ ни разу такого не встретил =3

Да и пространство нынче у процессов 64-битное, жирное. Вкупе с виртуальной адресацией, не очень понимаю, что к этому всерьез может привести.

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

В общем, прошу proof-of-concept.