Victor Bomberow

А как вообще определяется лучшесть и быстрость..
А если один язык посчитал быстрее, значит он лучше?

Язык - это набор грамматик для парсера; набор правил для описания последовательности действий с данными, описания данных, работы со строками и т.д.
Язык ничего считает, и сам по себе либо хорош для какого-то класса задач, либо совсем не хорош. Например, писать кросс-платформенный три в ряд на php идея так себе. Вся магия заключается в том, для чего этот язык служит ручкой управления - для игровой приставки, телевизора, виртуальной машины, веб-сервера, специального ПО или ПК.

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

Почему новички гуглят самый быстрый язык, а не самый медленный?

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

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

Количество строк в решении задачи на языке А по сравнению с языком Б может позволить неточно оценить отношение цикломатических сложностей для решений. Но это имеет смысл только для языков из одной категории. Например, для ПО для работы с геоданными и картами может потребоваться встроить какой-нибудь существующий язык, либо навелосипедить DSL. К примеру, в качестве встраиваемых кандидатов можно взять lua, js, python. Если в аналитической модели большинство операций связано с операциями над множествами, то на тестовой задаче станет видно, что решения на python самые лаконичные. Если в модели много работы с данными разных типов, то возможно тут выиграет js. Если все модели данных уже предопределены, или в числодробилках задействованы распараллеливание вычислений, то скорее всего обвязка на lua даст самый лаконичный результат. Да, все дело в том, какие именно паттерны и модели изначально встроены в синтаксис языка. По факту, именно специализация языка на классе задач позволяет сделать решение лаконичным.

Но лаконичность и скорость исполнения более важны для языков с JIT компиляцией. В AoT основная ценность это производительность программы и минимальное потребление ресурсов, в C++ лаконичность в решении это результат введения чего-то хорошего в стандарт. В целом, нужно исходить от класса задач, а не просто из количества строк.

Я начинал организовывать свои фрагментированные знания по записям лекций Computer Science Center Валерия Лесина и лекций Алексея Петрова "Углубленное программирование C/C++". Они хостятся на youtube. Охват очень хороший. Практические задания я придумывал сам и что-то брал из сборника каталогов awesome awesomeness в разделе C++ (github).

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

UPDATED:

Кажется либа еще не доработана, т.к. в доках не указана явно сборка под Win.

1) В подобных случаях в первую очередь нужно искать и просмотреть в архиве все текстовые файлы, которые названы без расширения. В данном случае, в архиве уже есть проектные файлы для сборки через visual studio. Для сборки потребуется сделать только solution.
2) Создаете новый solution c запуском без кода или через открытие в проводнике на одном из проектов. В ПКМ контекстном меню solution в Solution Explorer добавляете второй проект в solution.
3) Собираете проект htmlcxx.vcxproj в двух конфигурациях. Если ничего не менять при импорте - это проект статической библиотеки.
4) Чтобы собрать проект простым CLI (htmlcxxapp.vcxproj) нужно добавить папки, куда собиралась либа - свойства проекта - Linker - Additional include directories. Если создался sln через импорт проекта, то sln создастся в той же папке, что и проекты, и по умолчанию путь для сборки можно задать так $(ProjectDir)$(Configuration)
5) Linker - Additional Dependencies перед %(AdditionalDependencies) можно просто добавить htmlcxx.lib; для всех конфигураций, т.к. в дебаге либа собирается под тем же именем.
6) после этого все соберется. Но работать под Win css парсинг не будет.
Потому что

#ifdef WIN32
		if(parse_css)
		{
			cerr << "Css parsing not supported in win32" << endl;
			return 1;
		}
		return 0;
#else

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

В конце список онлайн книг

https://github.com/jubalh/awesome-os

Андре Ламот программирование игр для windows

lodev.org/cgtutor/raycasting.html

https://www.youtube.com/watch?v=kmECa4Gcckc&list=P...

Потом смотри статьи, курсы, туториалы, доки, книги, посвященные OpenGL, OpenAL, разработки многопоточных приложений, открытые репозитории движков на Github, вот здесь хороший по компьютерной графике https://www.scratchapixel.com, про ai книга Ian Mullington, вообще, списку конца нет, движок - это программная система из ряда программных продуктов, поэтому либо строишь свой в основном из открытых библиотек, либо умираешь от старости не доделав до конца.

Я отвечу для случая работы с простым форматом ввода:
12345 + 6789

1) вы не модифицируете входную строку, поэтому, если имеем дело со стандартом от c++17, то лучше в функцию принимать явно string_view или const string_view&, если ниже, то принимать надо const string&.

2) если уж принимаем что-то строкоподобное, то смело пользуемся функцией-членом ::find, которая есть и в строке и в вью. С её помощью можно найти сразу позицию арифметического символа. Для простого случая, даже не нужен обход от найденной позиции к началу строки и к концу строки для проверок std::isspace, является ли символ пробелом, поскольку мы можем сразу слать в atoi для левого числа например string_view::substr(0, opPos - 1). И, получится, только один if/switch, который будет сопоставлять символ операции, например, с указателем на функцию.

...
int plus(int left, int right) { return left + right; }

using CalculatorFunction = int (*)(int, int);
...
CalculatorFunction operation;
...
switch (opChar):
case '+': operation = plus;
...

3) настоятельно рекомендую после этого реализовать нормальный простой калькулятор, а потом третьим заходом добавить поддержку скобок, hex oct бинарную и с мантиссой нотации записи чисел, операцию степени и корня.
Нормальный - имеется ввиду, что в калькулятор входит строка, которая является корректным арифметическим выражением. В этом случае нужно ещё иметь дело с разделителями. По-хорошему, решение состоит из нескольких этапов:

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

- как вариант, токены могут быть структурами с членом string_view на строковые представления и членом на тип токена (число, операция).

- на втором логическом этапе мы считываем последовательность токенов и делаем какое-то действие:

• считали число - ожидаем за ним токен операции
  
• если оказался не токен операции - бросаем исключение о некорректном арифметическом выражении, иначе - подготавливаем аргументы и кормим функцию evaluate<T>( Token::kOperation op, T arg1, T arg2) , для случая, если операции нужно два аргумента, то первый уже считан, а второй будет в последовательности токенов за операцией. Результат evalaute записываем в переменную результата, которая, кстати говоря, типа double.
  
• продолжаем движение по последовательности токенов до конца, контейнером может быть std::list, когда добрались до конца, возвращаем результат.
  

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

C++ - свободный язык, если вы хотите произвести на свет новую платформу, и при этом хотите, чтобы уже написанные 100500 программных продуктов на нем работали, вы просто производите свой компилятор для C++. С Ide ситуация схожая.

Что-то уровня десятков тысяч строк, комфортно можно написать в любой IDE. Но когда размер становится больше, или нужно использовать какой-то специфический пайплан разработки, только тогда становится понятно, зачем yet another IDE.

На самом деле, все зависит от количества составляющих программного проекта, и как это все дело собирается.

Qt Creator создана для удобства работы с Qt, особенно с точки зрения скрытия сложности сборки. Например, для VS лишь относительно недавно они родили на свет приемлемый плагин, который не заставляет добавлять файлы meta object compiler для каждой сборки проекта вручную. Но всё ещё осталось, мягко говоря, все остальное: WYSIWYG редакторы для файлов ресурсов, которые не всегда корректно работают, редактор для быстрого формошлёпства, удобная работа со старыми версиями qt, производительности плагина, и прочее и прочее. С qt работать из других qt стоит лишь тогда, если ваша система сборки не будет меняться чаще раза в N лет, иначе лишние траты на перенастройку сборки.

Если что-то коммерческое собирается для Windows не на MSBuild + VC++, то могу пожелать счастливой отладки и напомнить, что спасение утопающих - дело рук самих утопающих.

Eclipse нужен в случаях когда нельзя применять коммерческое ПО в ходе разработки. Или, если вы пишете про специфичную или открытую платформу, потому что как правило, в таких случаях владельцы платформы IDE не предоставляют по ряду причин. Тут на помощь приходит всемирно известный конструктор для IDE - Eclipse. Ещё его можно рассматривать в случаях, когда вы оптимизируете процесс разработки для себя. Хотя, этим заниматься лучше всего на Vim, Emacs. Насчёт последних - если кодовая база за миллионы строк, что выбора может не быть, но скорее всего, большинства а разработчиков эта проблема не касается.

CLion нужен для тех, кто привык к другим IDEшкам от jetbrains. Хорошие, удобные, потому что коммерческие, постоянное развитие. На stepik можно решить тяжёлые задачи и получить лицензию на несколько месяцев, персональную. Хотя многие рефакторинги ещё не работают.

Из ide ещё упоминают netbeans, а также многие редакторы, типа gedit, vs cide, geany и прочие.

Если опыта разработки нет, то нужно начинать с geany. Потом переходить, например, на vs code. А уже потом пытаться что-то делать в IDE и делать проекты для сборки на разных платформах, например, с помощью cmake. Дело в том, что нужно знать, что делает при каждом чихе IDE, и самый органичный способ это сделать - наращивать сложность пайплацна разработки постепенно: сначала проекты на сотни строк, потом добавляем статический анализ, автоформатирование, тесты, git, управление сборкой и CI/CD. К тому же, это коррелирует с основным принципом C++ - "я не плачу, за то, что не использую", т.е. время на лишнюю возню из-за узкой специализации IDE, либо недостаточной специализации - оно не тратится. Именно исходя из этого, Евгений Шатунов вас спросил о вашей задаче, чтобы посоветовать что-то дельное.

Можно! Для этого нужно всего лишь вступить в трудовые отношения. Для того, чтобы это сделать, нужно соответствовать ожиданиям работодателя.
Опыт можно получить во время стажировки, во время ковыряния в опенсорсе, во время рефакторинга своих пет проектов. Если только сейчас начали, то через год можете начинать искать. Джуна никто учить не будет, устраиваясь на работу надо уметь выполнять задачи, код должен быть чистым и правильным вне зависимости от должности и иерархии в команде.
Вакансий относительно не так много может быть, поэтому однозначно стоит откликаться на вакансии уровня мидл, вероятность, что ищут так же и джунов не нулевая.

Если не делать движок, то после добавления третьего-пятого игрового объекта (уровня геймдизайна) и рефакторинга у вас появится свой игровой движок все равно.

Мало инфы по библиотекам потому что там просто биндинги функций OpenGl. Все мясо в Кронос Вики, туториалов по opengl много.

Если собираетесь устраиватьс на позицию C++ developer в фирму, у которой есть свой движок, то свой кривой игрушечный движок делать нужно в обязательном порядке. Если в фирму, которая работает на UE - нужно мастерить и знать UE вдоль и поперек и твердо владеть C++. Если на C# - нужно знать вдоль и поперек C#, устройство Net, желательно - уметь работать с unmanaged кодом + Unity, вдоль и поперек.

Если вы не целитесь на работу C++ разработчика графики и tools в фирму со своим движком, то свой движок писать конечно стоит, но далеко не в первую очередь.

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

Касательно вашего вопроса буквальный ответ: для игрушечного/некоммерческого движка/игры без разницы на каком языке дергать DirectX/OpenGl/Metal. Но если писать игровой движок, то лучше всего на C++ и биндинги на любом встраиваемом языке или компилируемом можно предоставить конечному пользователю без особых проблем (времени много конечно уйдет). Если чисто игру - тут нужно завязываться на библиотеку или игровой движок, который уже предоставляет какой-то пайплайн для производства игр.

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

По большому счету есть две дороги: дорога самурая и дорога сёгуна.

У самурая нет цели и есть только путь. Этот путь может вести вглубь технологии, к истокам её проектирования, к особенностям её устройства. Но путь может быть извилистым. Так же этот путь может вести в смежные вопросы, где технология имеет несколько иное воплощение. Всегда есть несколько способов и инструментов решения одной проблемы, пускай же идущий путем самурая изучит их все. Пишите в стеке Node.js+Typescript, но не было случая, когда нужно было узкие места оптимизировать на C++ - и вот вам ещё один непройденный путь. Но ведь модно было бы и на Rust. И на C. Или заменить целый модуль с узким местом, которое переписывалось на Net core. Может быть ещё и заменить часть фронта с Blazor? А какие проблемы в процессе могу возникнуть?

Если самурай не смотрит вперёд, то он скоро ослепнет и начнет думать, что он "знает всё". Но не стоит путать иллюзию наличия знаний с количеством пройденных километров. Каким бы ни было число, путешествие ещё не окончено и не будет окончено никогда.

Чтобы идти дорогой сёгуна, нужно отринуть рамки привычного мира самурая и обрести цель. Эта цель должна быть перевоплощением в новое существование. Идущий путем сёгуна должен идти в гору до самого солнца, и с каждой новой вершиной будет открываться перспектива и сотни путей, но сегун по ним не будет ходить. Его путь состоит в том, что сегун видит перспективу, с высоты ему видна иная сторона горизонта и весь рисунок путей. Ему видно, как пути, словно реки, сливаются в дороги, многие из которых ведут к обрывам и тупикам. Дорога сёгуна должна привести его в к смыслу. Возможно, это открытие своего коммерческого предприятия, или же это (F)OSS, или же должность сёгуна-тимлида, или же менеджера, имеющего цели стать часть руководства текущей компании.

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