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

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

зачем учить язык, если ты даже не знаешь что на нем делать собираешься?

Legacy.

Опять штоле?

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

По уму — \emptyset.

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

кроме смартфонов

Он там тоже активно используется.

системщина и околосистемщина

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

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

Блин, как вы пишете с этих лопат? Глаза в кучу, буквы пытаются, фу...

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

Кроссплатформенный слой для смартфонов.

Игры ещё

почитать - вот точно не скажу. наверное, есть что-то теоретическое, но такие проекты часто чисто прикладные, под конкретную задачу.
мы проектировали систему исходя из требований заказчика(это был Сбербанк): у них были миллионы агентов, местами очень фиговые сети, местами (во всяких там деревенских отделениях Сбера) интернет включался только по часам и аж через модем, огромный парк разных машин, от новейших мощных мейнфреймов в ЦОДах до каких-то древних компов типа x486 на окраинах. и требования у них были объединить весь этот зоопарк надёжной системой обмена данными. вот и городили им кастомное решение, чтобы работало всегда и везде. пистоны и жабы, ясное дело, в таких условиях бы не выжили. такая же фигня была у таможни.
обработка данных зависит, собственно, от того, что и зачем обрабатывать. например, когда мы делали автоматизацию Гознака, то там объёмы графических данных были очень велики. я делала кастомный вьювер для многогигабайтных файлов нестандартного формата. нужно было мапить файлы кусками в память, хитрым образом собирать из них видимое юзеру изображение и организовать морду для просмотра по разным плоскостям (видимый спектр, ИК, УФ), с навигацией и масштабированием, по большому отсканированному листу. ну и чтобы всё это не особо тормозило. собственно, никакие пистоны и жабы тут бы не справились даже близко. потому и писалось на плюсах.
если вникать в теорию обработки изображений - это векторная алгебра в полный рост. теория вся про операции над матрицами, векторная обработка. если вывод графики - то это OpenGL. про это всё написано много книг. но это не специфическая информация, а, скорее, общая. нельзя сказать, что проект на плюсах потребует конкретные алгоритмы. сильно зависит от целей проекта.

Геймдев, хайлоад сервера, критичный к скорости десктопный софт (всякие 2д/3д редакторы и т.д.), embeded

Научный софт ещё (тот, который много считает). То есть в той же нише, где фортран.

Я кажется понял что общее у всех проектов, для которых подходит С++ - «вероятность запуска на x486»

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

Я кажется понял что общее у всех проектов, для которых подходит С++ - «вероятность запуска на x486»

Конечно, гугль только на таком железе и работает.

Я делал отсылку к абсурдности аргументов собеседника, а не критиковал С++, на котором пишу каждый день

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

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

Браузеры, с которых мы пишем всякий бред на ЛОР.

держись подальше от dev'а

Любые CADы. Любые игры под любые девайсы. 90% софта, которым ты пользуешься, наконец. Дураки (ericsson, например) пихают плюсы в эмбедщину, потому что думающих людей найти трудно, а в c++ уже есть linked list :D

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

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

Ну это уже получше. Дейсвительно иногда рантаймы или компиляторы других языков отсутствуют. Иногда бывают уже существующий системы, с которыми взаимодействие сугубо через здоровенный header на С++. Можно писать адаптер, но иногда это не практично

Еще одна причина использовать компактный райнтайм в гигантских датацентрах - микросервисы в контейнерах. Обычно СPU не bottleneck. Но память определяет сколько простых примитивных сервисов можно упаковать в одну машину. Если в каждом из них еще зашит Java runtime, то это будет дорого. Тогда вообще лучше чтобы микросервисы крутились в гигантском JVM, но тогда их нельзя изолировать по CPU/RAM от друг друга, только по security

программист-фрилансер на плюсах практически не встречается, как вид.

Привет, я тут.

Над какими проектами работаете?

Если интересно, стукнитесь в жаббер (в профиле).

Не, я так, на лоре пофлеймить, у меня нету проектов чтобы предложить :) Просто интересно

Посмотри объявления оработе, в какие области требуются cpp разработчики. Например автоиндустрия, авиация, медицина - кругом CPP.

А мне сейчас и не нужны проекты. Так ваще в данный момент - LLVM, ещё git (но это си и perl, не кресты).

плюсы используется везде, где ложаются прочие :-)

очевидные области :

• точные быстрые вычисления,
• плагины и расширения для «убийц c/c++»,
• сами по себе «убивцы»,
• ядро(чисто С) и всё что к нему близко (тут плюс-плюс),
• недолгие проекты на известных тулкитах - на чистом C очень быстро пишутся проекты Gtk, на С++ - Qt.
• и наоборот проекты с длительными стадиями - если проект надо поддерживать и развивать как минимум 10-15 лет, просто конкуренты отваливаются. Они нестабильны в таком сроке

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

Если в каждом из них еще зашит Java runtime, то это будет дорого.

Белые люди для этого давно изобрели KSM.

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

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

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

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

И как JVM с ним работает? Как оно понимает что общее, а что нет? Откуда у разных JVM получаются same pages если в средине page крутится какой-то дебильный timestamp счетчик, а такой кстати найдется?

Что ж. Благодарю за ответы. Для себя решил, что подтяну сети и еще один язык (скорее всего Java).

Не быстро и не в одну каску, контракт на год, возможно продление, это LLVM. Есть ещё дополнительные проекты, например, socks5 прокси со своими особенностями, но это проприетарщина, подробностей рассказать не могу.

И как JVM с ним работает? Как оно понимает что общее, а что нет? Откуда у разных JVM получаются same pages если в средине page крутится какой-то дебильный timestamp счетчик, а такой кстати найдется?

Как минимум, все загружаемые с диска исполняемые файлы будут общими: сама jvm, классы и т.п.

Научно-технические приложения.

файлы будут общими: сама jvm, классы и т.п.

Ну, exe'шник явы, понятно, что общий, а классы-то как, они же компилироваться будут из байткода в машинный?

JVM сам по себе не большой. Java просто хорошо умеет разгуляться своими пространствами сборки мусора, всякими eden, survivor, tenured, permgen. Там данные колбасятся туда-сюда и вот это будет отличаться и жрать все те пресловутые гигабайты, которые все так любят упоминать

кроме смартфонов, потому они и жрут батарею только в путь

во-первых, под брюхом JVM в Android здоровенный фреймворк на C++; во-вторых, оптимизация энергопотребления выполняется на уровне HAL и там код на С

Эмбедщина, гейдев, разработка баз данных, браузеров, компиляторов

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

Я сам байткод имел ввиду.

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

Ты о JVM изначально говорил, а не о создаваемых ей данных.

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