C++, замыкания

// Тут я ожидаю «Hello!!!»

Неправильно ожидаешь.

но как сделать что бы все же выдавалось «Hello!!!»?

Никак. Ты должен отвязать время жизни объекта от скоупа, будь то скоуп do_save/лямбды.

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

Мань, ну ты разожралась! Скоро ни в один тред не пролезешь!

Ну я думаю тут мне может помочь какой нибудь хитрый указатель (который умный)

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

В общем случае тебе нужно поддерживать время жизни объекта в контексте 2х(и более) ссылок на него. Этот функционал предоставляет std::shared_ptr.

Вот все таки какие умные люди - эти сишники! Этож надо вот так вот хитро схелловордить. Между сишником и жабоскриптером расстояние в вечность.

static std::string text = "Hello World!";

Но это довольно уродливо, как по мне.

С threads беда будет тогда.

Про это в условии не было.

Да, работает, спасиба. Все ли правильно? Можно ли что то улучшить?

#include <functional>
#include <iostream>
#include <memory>
#include <string>

std::function<std::string()> func;

void do_save() {
	auto text = std::make_shared<std::string>("Hello World!");
	func = [=]() {
		return *text.get() + std::string("!!!");
	};
	*text.get() = std::string("Hello");
}

int main() {
	do_save();
	std::cout << func() << std::endl;
}

Напрягает использование .get() хотелось бы как то напрямую общаться!

Чем не устраивает просто *text? Опять что-то не так с потоками?

Если что, я не знаю C++, просто интересно.

В JavaScript кстати нормально работает.

let func;

(() => {
	let text = "Hello World!";
  func = () => {
  	return text + "!!";
  };
  text = "Hello!";
})();

console.log(func()); // Hello!!!

А вот в Python что то не очень.

Чем не устраивает просто *text?

Отлично, полностью устраивает! То что нужно. Звездочку поставить мне не лень.

ну или как то так:

#include <string>
#include <iostream>
#include <functional>
#include <memory>
std::function<std::string()> func;

void do_save(std::shared_ptr<std::string> text){
  func = [text]() {
	   std::string new_text(*text);
	   new_text+="!!";
	   return new_text;
	};
  text->assign("Hello!");
}

int main(int  argc,char **argv){
  auto text =std::make_shared<std::string>("Hello World!");
  do_save(text);
  std::cout << func() << std::endl;
}

А чем assign отличается от «*p =»?
Вот кстати тоже самое на Common Lisp!

(defvar func)

(defun do-save ()
	(let ((text "Hello World!"))
		(setf func (lambda () (concatenate 'string text "!!")))
		(setf text "Hello")))

(do-save)
(format t "~A~%" (funcall func))

он еще умеет делать часть функций (таких как fill substring)

string (1)	

string& assign (const string& str);

substring (2)	

string& assign (const string& str, size_t subpos, size_t sublen = npos);

c-string (3)	

string& assign (const char* s);

buffer (4)	

string& assign (const char* s, size_t n);

fill (5)	

string& assign (size_t n, char c);

range (6)	

template <class InputIterator>
   string& assign (InputIterator first, InputIterator last);

initializer list(7)	

string& assign (initializer_list<char> il);

move (8)	

string& assign (string&& str) noexcept;

Assign content to string

И так

Замкнись.

Вот кстати тоже самое на Common Lisp!

Это не тоже самое - это просто скриптуха, к которой предъявляются совершенно другие требования, нежели к С++ и его stdlib.

Это компилируемый язык, даже SBCL не сильно от плюсов отстает.

Это компилируемый язык

Неверно. Любой компилируемый язык может существовать без внешнего(относительно логики написанной в рамках конкретной программы) рантайма. Этому правилу не соответствует ни лисп, ни любая другая скриптуха.

даже SBCL не сильно от плюсов отстает.

Во влажных фантазиях адептов SBCL.

Этому правилу не соответствует ни лисп, ни любая другая скриптуха.

Ну в этой теме ты не разбираешься явно.

Во влажных фантазиях адептов SBCL.

Адептов SBCL? Ну может и такие есть, пока не видел.

Ну в этой теме ты не разбираешься явно.

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

Адептов SBCL? Ну может и такие есть, пока не видел.

Ну дак что, пруфы будут по поводу «не отстаёт»? Покажешь не отстающий аналог любому требовательному к производительности/сложности софту? Или опять лужа?

Привет царь, ну давай объясню, Common Lisp довольно таки продуман, он позволяет делать практически все так, что бы потом это работало без оверхеда. Тут как в Forth примерно, ему нужна среда что бы адекватно откомпилироваться, и потом еще интерпретируемым кодом настроиться, а потом уже можно выкидывать интерпретатор с компилятором, если конечно не используется какой нибудь eval.

Ну дак что, пруфы будут по поводу «не отстаёт»

По тредам лисперов вспоминаю, можешь провести свои тесты. Пруфов у меня тут нету, но мне все равно, мне лень их искать, пропустим.

Ты вот сам жаловался что криво сделан constexpr, но если бы в плюсах была система по типу forth'a, или lisp'a, там можно было бы реализовать крутейший constexpr, вообще никаких ограничений, и это не просто интерпретируемые скрипты во время компиляции!

Привет царь, ну давай объясню, Common Lisp довольно таки продуман, он позволяет делать практически все так, что бы потом это работало без оверхеда.

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

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

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

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

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

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

Свойство «Быстро работает» - это именно свойство реально, т.е. сишной компиляции. Именно И ТОЛЬКО в этом контексте из неё следует быстро. Во всех остальных случая не следует.

По тредам лисперов вспоминаю, можешь провести свои тесты. Пруфов у меня тут нету, но мне все равно, мне лень их искать, пропустим.

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

По поводу твоих лисперов. Уже наверное 10лет(а может и больше) существует данный ресурс: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/lisp.html и никто не показал там никаких результатов. Где же все твои лисперы? Не могут написать 10строчек кода?

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

В решениях запощенных там оптимизация даже не начиналась.

Ты вот сам жаловался что криво сделан constexpr,

Ну да, он говно. Да и С++ в целом говно, но это мало что меняет. То, что это хуже чем могло бы быть не отменяет того факта, что относительного того, что уже есть - это лучшее.

но если бы в плюсах была система по типу forth'a, или lisp'a,

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

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

там можно было бы реализовать крутейший constexpr

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

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

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/lisp.html

Ты, кажется, занимался оптимизацией этих бенчмарков на C/C++. Ты отправлял им код?

Алсо, дай ссылку на свои версии, если не сложно.

Ты явно выше показал, что не можешь мыслить вне ГЦ.

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

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

Можно это реализовать и без GC, он там не каждой переменной нужен, в принципе можно и без него.

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

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

Уже наверное 10лет(а может и больше) существует данный ресурс

Ну вон плюсцы обгоняет в каком то из тестов, ты пойми еще что SBCL это как Portable C Compiler, а для плюсцов там один из лучших компиляторов, еще и задачи на вычисления, лисп для другого больше.

И я тебе даже больше скажу - крестовый/сишный код там говно.

Да я знаю, там вообще весь код такой, лол.

Ну ты про рефлексию какую то опять, перечитай что я тебе писал, потом перепишешь свой ответ.

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

Правильно, мыслить в рамках ГЦ - это может и делает любая уборщица.

Можно это реализовать и без GC, он там не каждой переменной нужен, в принципе можно и без него.

Неможно.

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

Это ты перечитай. С vm был пример. К тому же vm у тебя есть. Критерий я тебе назвал. Если у тебя нет vm, то коду ненужен рантайм. Любой рантайм - это по-сути vm.

Ну вон плюсцы обгоняет в каком то из тестов, ты пойми еще что SBCL это как Portable C Compiler, а для плюсцов там один из лучших компиляторов, еще и задачи на вычисления, лисп для другого больше.

Я тебе сообщу новость - это просто баг и там это говно попросту не дало результатов: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/revco...

TIMED OUT after 300s

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

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

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

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

это как Portable C Compiler,

Это мало что изменит. Да и это лучший «компилятор» лиспа.

Правильно, мыслить в рамках ГЦ - это может и делает любая уборщица.

Кому как.

Неможно.

Можно но это слишком криво будет, на Forth можно %)

Это ты перечитай. С vm был пример. К тому же vm у тебя есть. Критерий я тебе назвал. Если у тебя нет vm, то коду ненужен рантайм. Любой рантайм - это по-сути vm.

Сишка тоже не может без libc. О чем разговор вообще?

задачи говно

Да, лисп он больше про абстракции различные.

Да и это лучший «компилятор» лиспа.

Ахах, ну ты даешь конешн. Я хз какой лучший, наверное LispWorks, спроси у лисперов лучше. Но я знаю что LispWorks НАМНОГО лучше SBCL.

Кому как.

Всем. Это аксиома. Ты никак и никогда ничего с этим не сделаешь.

Можно но это слишком криво будет, на Forth можно %)

Ты уже съехал с лиспа. Контекстом был лисп. Но в любом случае forth в таком же говна и такое же говно.

Сишка тоже не может без libc. О чем разговор вообще?

Ещё раз, ведь ты вообще нулёвый - зачем ты пишешь херню нелепую? Ты действительно это вскукарекнул? На лоре, где l - это линукс, где линукс - это софт на си без libc. Да ты гений, нахрен. Иди что-то погугли, для общего развития.

Давай попроще - си вообще никак от libc не зависит. Как и С++. Правда у С++ есть кое-какой рантайм, от которого уже С++ зависит, но это убогие крохи. Да и работает спокойно без него и в основном он связан с исключениями.

Да, лисп он больше про абстракции различные.

Ну т.е. про твой дивный фентезийный мир? Ну дак с этим никто не спорит. Вот и оставайся в своём мире фантазий.

Ахах, ну ты даешь конешн. Я хз какой лучший, наверное LispWorks, спроси у лисперов лучше. Но я знаю что LispWorks НАМНОГО лучше SBCL.

Где этот LispWorks? Как я могу на него посмотреть, либо посмотреть на код сгенерированный им? Или это опять выходит на связь маня-мирок адептов лиспа с помойки?

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

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

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

Я тут для понимания набросал. https://pastebin.com/2EEHi0Bn

Ты уже съехал с лиспа. Контекстом был лисп. Но в любом случае forth в таком же говна и такое же говно.

Я сразу про два языка, ну съехал и съехал, игнорируй если не нравится.

Давай попроще - си вообще никак от libc не зависит.

А, окей, я думал ты наркоманишь, а ты просто тупишь, Common Lisp - компилируемый, SBCL его не может скомпилировать, вот так.

Как и С++. Правда у С++ есть кое-какой рантайм, от которого уже С++ зависит, но это убогие крохи. Да и работает спокойно без него и в основном он связан с исключениями.

Ну так же и у SBCL, там eval, всякое такое.

Где этот LispWorks?

Лишпворкс точка ком, первый результат в гугле. Покупай и смотри.

Ну так же и у SBCL, там eval, всякое такое.

Туплю, вместо SBCL должен быть Common Lisp.

Дак вот, я тебе сообщаю - наличие ГЦ и/или другой подобной автоматики - уже множит на ноль любые разговоры о производительности. Это уже оверхед, определяющий.

Не согласен, с ГЦ можно жить и писать производительный код, скорее отсутсвие нормаьлных value типов, наподобие структур в C множат производительность на ноль, к примеру, Майк Актон не плохо оптимизирует на C# (https://youtu.be/p65Yt20pw0g) при этом просто напросто свел использование ГЦ к минимуму + кастомные аллокаторы памяти ну и в принципе хорошая организация данных.

Тссс.. не спорь с Царём! Он лучше тебя знает!

Не согласен, с ГЦ можно жить и писать производительный код

Нельзя.

скорее отсутсвие нормаьлных value типов

Это напрямую связано с ГЦ.

Майк Актон не плохо оптимизирует на C# (https://youtu.be/p65Yt20pw0g)

Попытка подлога. Абсолютно неважно что там оптимизирует, когда основная логика производится в С/С++-рантайме.

при этом просто напросто свел использование ГЦ к минимуму

Дак можно с ГЦ писать или нет? Если ты сводишь использование ГЦ к минимуму - это равносильно признанию «используя ГЦ получить производительность нельзя».

В любом случае - всё это неважно. Во-первых это скриптуха, где основную логику делает С/С++-рантайм. Что в рамках самого юнити, что в рамках сишарп-vm, что в рамках структур данных на том же шарпе и прочее.

Во-вторых, разговор был не об этом. Это всё попытка манипулировать с твоей(и не только) стороны. Контекстом является «может ли скриптуха заменить С/С++?» - этот тезис предполагает «полностью».

Что же делаешь ты? Ты говоришь «в каких-то редких кейсах, используя тонны С/С++-рантайма, используя совершенно непопулярные и недоступные для 99.999% адептов скриптухи подходы - можно чего-то там добиться». Очевидно, что из этого ничего не следует. И тебе даже больше скажу - вся эта «производительность», которую тебе показывают - на самом деле пыль нелепая.

И я тебе объясню почему. Что значит «быстро» в контексте всех этих рассуждений, в частности в скинутом тобою видосике? Правильно - быстро относительно скриптухи. Но, нам абсолютно неважно быстро ли оно относительно пхп - мы говорим не об этом. Мы сравниваем то, что можно получить на С/С++ и то, что можно получить на скриптухе(в данном случае шарпе) - и тут все эти рассуждения автоматически умножаются на ноль.

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

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

Дак можно с ГЦ писать или нет? Если ты сводишь использование ГЦ к минимуму - это равносильно признанию «используя ГЦ получить производительность нельзя».

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

Во-вторых, разговор был не об этом. Это всё попытка манипулировать с твоей(и не только) стороны. Контекстом является «может ли скриптуха заменить С/С++?» - этот тезис предполагает «полностью».

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

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

Вот другое видео с CppConf от того же автора: https://youtu.be/rX0ItVEVjHc автор рассказывает как писать C++ код, который будет работать быстрее относительно C++ и ни о какой скриптухе речь не идет.

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

Ну в большинстве случаев нету возможностей, но скажем в том же D есть возможность и писать свои аллокаторы памяти и работать с value типами, в любом случае можно попытаться все же реорганизовать работу с памятью, выделать через тот же ГЦ большой непрервыный кусок памяти и создать своего рода пулл, получится не аллокатор конечно, но тем не менее, можно свести к минимуму выделение через ГЦ и переиспользовать уже выделенну память.

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

Нет, ты не можешь писать без ГЦ. Это аксиома. Ты можешь пытаться как-то уменьшить его влияние, но это не значит убрать.

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

Нельзя.

Вот другое видео с CppConf от того же автора: https://youtu.be/rX0ItVEVjHc автор рассказывает как писать C++ код, который будет работать быстрее относительно C++ и ни о какой скриптухе речь не идет.

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

С++ можно свести к скриптухи, а скриптуху к С++ нет. Всё просто.

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

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

Это ещё одна стена, которую скриптуха никогда не покорит.

Ну в большинстве случаев нету возможностей, но скажем в том же D есть возможность и писать свои аллокаторы памяти и работать с value типами, в любом случае можно попытаться все же реорганизовать работу с памятью, выделать через тот же ГЦ большой непрервыный кусок памяти и создать своего рода пулл, получится не аллокатор конечно, но тем не менее, можно свести к минимуму выделение через ГЦ и переиспользовать уже выделенну память.

Ещё раз. Это абсолютно неважно. Да, ты можешь писать лучше на скриптухи и обходить её проблемы, но зачем тебе тогда нужна скриптуха? Ты будешь заниматься борьбой с ГЦ, вместо использования ГЦ.

Этим занимаются и будут заниматься только те, кто занимается рантаймом скриптухи. Но это ничего не меняет - это капля в море и уровня С/С++ там никогда не будет, даже близко.

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

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

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

Если я сперва буду учить JS, то С++ потом не зайдет?

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

Я если что не C# разработчик, просто привел как пример C#, т.к. вроде бы там есть value типы.

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

Я работаю на Java и Rust, на Java у нас большая часть бекенда, на Rust у нас микросервис, для которого критична производительность. В общем-то есть смысл в твоих словах, никогда особо то и не беспокоишься о вычислительной производительности именно, когда пишешь на Java, больше стараешься оптимизировать IO, запросы к БД итд. Не давно писал не большой рендеринг на Java и больше всего доставляло проблемы именно отсутствие value типов, ежели наличие ГЦ, т.к. в основном цикле нельзя просто создать Rect или Vertex, т.к. - это классы и создание новых экземпляров задействует ГЦ, а в бесконечном цикел - это самоубийство.

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

Шпасиба за развернутый и обстоятельный ответ! У меня возникло много вопросов. Скажите пожалуйста, а если я потом захочу писать драйвера, мне будет легко перейти на С, или можно прямо С++? Что плохого в галерах? И наконец, что вот сейчас молодому человеку, который не ростит бороду,не пьет смуззи, не мечтает о маке, учить первым языком, что вырасти реальным пацаном?!

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

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

С С++ сложнее. С++ - это надстройка над си. Правда над достаточно старым си и с некоторыми ограничениями. Но в целом на них в какой-то мере можно писать в парадигме си.

Некий прикладной С++ уже далеко ушел от от си-парадигмы и находится ближе к жаве/шарпу и т.п. Если привыкнуть к этому - будет сложно перестроиться.

Но С++ можно использовать и как си с множеством дополнительных возможностей, которые в какой-то мере покрывают отсутствие многих фишек из си, но и позволяют строить «красивые»/обобщённые интерфейсы. Пример с тем же std::chrono я показывал.

Что плохого в галерах?

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

И наконец, что вот сейчас молодому человеку, который не ростит бороду,не пьет смуззи, не мечтает о маке, учить первым языком, что вырасти реальным пацаном?!

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

С/С++ для успешной реализации требует множество знаний и умений. Для чего-то интересного - всего того же, но х10 и много удачи.

И наконец, что вот сейчас молодому человеку, который не ростит бороду,не пьет смуззи, не мечтает о маке, учить первым языком, что вырасти реальным пацаном?!

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

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

Душой я тяготею к С/С++. Но все вокруг заваливают меня линками на headhunter с дорогими вакансиями js/nodejs. Как мне вежливо послать их? Мне безразличны галеры. Я готов на жертвы, пусть даже работать за еду. Скажите, раз С++ надстройка, может начать с базиса? Добавляя классы в последствии?

Nodejs мне тоже симпатичен своей асинхронностью. мои старшие товарищи говорят, что даже прогрессивный энтерпрайз (так это слово пишется вроде) сейчас переходит на web-app. Вот такая дилемма.

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

Но в целом и то и то подойдёт. В целом организовать обучение можно так:

Взять жс(лучше ТС)/дарт и научиться писать что-то более-менее сложное.

Далее, пойти писать тоже самое на си. Именно на голом си, лучше вообще без libc(только printf). Далее в какой-то степени придёт понимание - в чём заключается удобство тс/дарта.

Далее придёт желание сделать то же. И тут на помощь придёт С++, которые добавит в си возможностей сделать похожие на скриптухи интерфейсы.

В вебсервисах обычно есть некая общая(для сервера/броузера) логика - она пишется на жс/дарте. Есть какая-то сложная логика - она пишется уже на крестах. Всё это можно объединить через ноду/дартвм.

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

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

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

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

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