Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Освоение С++ — посоветуйте книги и материалы

О себе: 19 лет, 0 опыта, 2 года свободного времени +, огромное желание постигать.

Нужен совет: выбрал C++(VS2015) как первый и основной язык для дальнейшего перехода в геймдев
1) Какие книги и материалы изучать с полного нуля, ибо везде пишут разные вещи и разные книги

2) Реально ли выйти хотя-бы на уровень джуна в цпп за пару лет

3) Какие доп материалы кроме книг компа и обучалок нужны

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Огромное спасибо все кто отписывается и будет писать, узнал кучу материала для освоения
начал читать и кодить,кодить,кодить «hello,world :D»

Я когда 10 лет назад начинал учить плюсы, внимательно читал Herb Schildt — C++ from ground up.

много материалов по этой теме есть на сайте Центра робототехники Boteon в разделе «домашнее задание» (доступно для зарегистрированных пользователей)

boteon.com/…​alnih-centr-v-boteon.html

Чистый С++можно выучить так:
1) архитектура / общие принципы программирования: C++ in Action: Industrial Strength Programming. Эта штука расскажет на примере калькулятора, как с нуля написать свой проект, как его апгрейдить, и что зачем в языке нужно. Сам язык излагается очень сумбурно.
2) собственно язык: Teach yourself C++ in 21 Days (какие-нибудь старые версии в нете). Дает хорошую базу по собственно С++. Детали и извращения можно потом почитать в C++ FAQ Lite в нете (тоже где-то лежат зеркала старой версии). Для прохождения собеседования надо прочесть Страуструпа и, вероятно, что-то про С++ 11/14.
3) практика: написать что-нибудь свое. Если хочется в игрушки — значит, какой-нибудь арканоид, например. Только вот что: на С++ писать очень долго. Рекомендую вначале выучить Питон, и первую игрушку писать на нем. По окончании процесса собирания граблей (1-2 месяца и полурабочая версия игрушки на Питоне) можно возвращаться к С++ (написать еще одну игрушку).
4) Питон: учится по туториалу, который входит в доки (инсталляция). Но чтобы что-то с этим самым питоном сделать, смотри пункт 1.
5) IDE: Eclipse (Linux) или VS (Windows) для С++, PyCharm или PyScripter для Питона.
6) Почитать на Википедии про: структуры данных, алгоритмы, многопоточность, design patterns, antipatterns. От джунов серьезно требовать не должны, но желательно понимать, о чем тебя спрашивают на собеседовании.
7) Библиотеки: Я использовал PyGame для игрушки на Питоне и WinApi для С++. Вероятно, сейчас стоило бы юзать QT.

Если тратить 100% времени на чтение и программирование, можно это все успеть за 9 месяцев. Потом — походить по собеседованиям, после 10 неудачных попыток уже примерно знаешь вопросы, дочитываешь то, на чем завалили, и на 11 собеседовании проходишь.
После этого еще года 3 надо будет читать умные книжки.

Доп материалы никакие не нужны. Если комп слабый — можно найти старые тулзы, которые на нем летать будут.

Я вот больше года учу уже. Прошел кучу всяких уроков. Основные принципи OOP и самого языка знаю вроде бы. Начал недавно учить Qt, написал элементарную игру с его помощью. Это задание такое тестовое было. Немного удивился, что на Qt дали пилить игру. Сейчас вот сижу и думаю, что дальше-то. По собесам хожу, но среди них половина неадекватных. В основном несколько вопросов из разряда «Женаты? Дети есть?» и тестовое на дом. Не понятно зачем ради этого звать на собеседование. Итого — фидбека годного пока что нет. На одном из собесов вальнули логической задачей. Разволновался, не смог решить и меня послали не задав ни одного тех.вопроса :D Сейчас начал читать Страуструпа в оригинале. C++ Programming language. Надеюсь это даст мне то, чего не хватает для работы. Хотя страниц там немеренно, читать буду долго, походу)
p.s. спасибо за развернутый ответ топик стартеру. мне он тоже был полезен.

А я вот что-то не уверен, что «The C++ Programming Language» Страуструпа так уж прям необходимо читать. Да, можно почитать — лишним не будет, конечно. Но если ты хочешь поскорее выучить язык и понять, как на нём программировать, не отстреливая себе конечности, то найдутся варианты получше. Причём на любом из этапов твоего обучения.

Если ты новичок, то учи основы по чему-то более лёгкому для восприятия. Книг для новичков море — выбирай любую. Из того, что я сам читал, могу порекомендовать Стивена Прату («C++ Primer Plus»). Есть пара кривоватых мест (например, в разделе про placement new он не упоминает про выравнивание), но в целом книга очень подробно и доступно объясняет основы. Начиная с шестого издания есть вставки а ля «а вот в C++11 можно ещё воооот таааак зафигачить», что тоже плюс, ибо знания плюшек из новых стандартов сейчас много где спрашивают.

Для новичков же «The C++ Programming Language» Страуструпа будет тяжёлой книгой. Она скорее этакий «справочник» для тех, кто уже знает основы. Я знаю многих людей, которые рано брались за эту книгу и бросали. Так что советовать её новичку не могу.

Для новичков у Страуструпа есть другая книга: «Programming: Principles and Practice Using C++». Но она предлагает учить C++ с несколько другого конца. Например, начинать динамические массивы сразу с векторов, минуя сырые указатели и прочую «сишную» муть. Это с одной стороны хорошо, с другой плохо — дискутировать на эту тему можно очень долго. Тема для очередного холивара :)
Но по факту я не знаю ни одного человека, который бы выучился на программиста C++ по такой методике, несмотря на то, что сейчас её активно продвигают. Может, она ещё себя оправдает. Но пока рекомендовать этот подход я тоже не стану.
В конце концов, все эти низкоуровневые «сишные» штуки, работу с указателями и т.д. программист на C++ также должен знать. Нельзя пользоваться вектором и не понимать, как он устроен.

Если ты уже знаешь основы, то лучше шлифуй свои знания не Страуструпом, а книгами по «хорошим практикам». Это в первую очередь совместная книга Саттера и Александреску «C++ Coding Standards» и все книги Скотта Майерса: «Effective C++», «More Effective C++», «Effective STL», «Effective Modern C++».
Они тебе расскажут, как пользоваться C++ так, чтоб не прострелить себе ногу (ожидая, что с основами языка ты уже достаточно хорошо ознакомлен).
Если затянет, то туда же можешь добавить и «сольные» работы Саттера (серия «Exceptional C++»). Он рассматривает несколько более специализированные проблемы, преимущественно касающиеся безопасности относительно исключений. Но это уже опционально. Главное Майерса осиль.
Если по ходу чтения будешь встречаться с незнакомыми классами или функциями из std (книги для новичков всё-таки рассматривают не 100% стандартной библиотеки) — не стесняйся заглядывать на cppreference.com и cplusplus.com/reference. На первом сайте формулировки более наукообразные, но более полные и точные. На втором — более лёгкие для понимания.

И не забывай про многопоточность. Конкретно по многопоточности в C++ есть книга Энтони Уильямса «C++ Concurrency In Action». Можешь почитать её, но более сложные главы пропускай или читай по диагонали. Знать о потоках, мьютексах, условных переменных, атомиках (которые по умолчанию sequentially consistent) тебе в любом случае стоит. А вот атомики с не-дефолтными memory ordering’ами, дизайн lock-free структур данных и прочий матан пусть подождёт — с джуниора такое спрашивать не будут.

Надо просто ходить на все собесы и не бояться сразу после окончания технических вопросов спросить у того, кто их задавал, что почитать на эту тему, или чего тебе не хватает. Технари часто менее злые, чем рекрутеры, и относятся к тебе не как к пачке денег, а как к потенциальному сотруднику (сложившемуся или несложившемуся). Поэтому на вопросы могут поотвечать.
Обычно на то, чтобы найти первую работу, уходит не меньше 10 собеседований. Между ними надо почитывать то, что рекомендуют, и дотягивать непонятые области, хотя бы с Википедии.
Можно не брезговать вакансиями embedded C — зарплата в тех же рамках, но будет возможность на практике увидеть, как работает все то, что в С++ «под капотом». Часто эмбедеры прыгают между С и С++ проектами, даже в рамках одной конторы. И может быть, что С в результате больше понравится, чем С++.

Еще одно: тот, кто спрашивает, ошибается. Мне на первом собеседовании сказали «пошел на, работать не будет». Пришел домой, скомпилил, запустил — работает. Оказывается, собеседующий не знал приоритеты применения операторов. Еще есть куча спорных моментов, в частности — во всем, что касается архитектуры (шаблонов, ...), оптимизаций и подхода к проекту (например, юнит/автотесты против ручного тестирования с кучей ассертов). Если на тебя кричат или улыбаются, и говорят, что ты не прав, даже аргументируя какими-то гипотетическими случаями, лучше от такой команды держаться подальше. Очень часто на практике все по-другому.
(Это не касается явно нерабочего кода, который свалится при запуске. Но если ты сделал 1-2 ошибки, но в общем написал задачку правильно — это вполне нормальный результат.)

Если контора дает задачки на дом — это уже плохой знак. Они не уважают твое время.

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

Не надо трогать С++ в 2017-м. Дайте ему спокойно умереть. Умоляю.

HRESULT __stdcall WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
  switch (message)
  {
  case WM_PAINT:
    return 0;
  case WM_DESTROY:
    return 0;
  }
}

Винда шо, до сих пор такая?

ну да, legacy ж код залишився

Как вспомню getpaint releasePaint или как там его, до сих пор страшно.

X-Windows без лишних либ не лучше

Так когда писалось оно? Когда-то под PalmPilot писал, так вот там очень похоже как на винде сделано. Вот только помниться не вызывал отвращения он. А на винде рисовать нужно и в ON_PAINT и в WM_PAINT кажись. Но делать это нужно было по разному.

То неважно. Низкоуровневые потроха везде примерно ужас. Уже на это навешивают модные библиотеки

ON_PAINT
 — такого евента нету

Помню только что их два было. По которым рисовать.
Про ужас, так уже писал: писал на PalmPilot. Там ужоса не было. Хотя сделано очень и очень похоже.
Это стиль майкрософта — все за что берется, все ужос.
Берем DirectX и OpenGL. (давно было дело) Самый простой пример что-то нарисовать — 49 килобайт. В OpenGL по моему самый большой пример что-то нарисовать весил 20.

Я вот не помню, всегда был один

Это стиль майкрософта — все за что берется, все ужос.
Это уже стиль LOR, хотя их православный Gnome — тот еще уродец
Берем DirectX и OpenGL. (давно было дело) Самый простой пример что-то нарисовать — 49 килобайт. В OpenGL по моему самый большой пример что-то нарисовать весил 20.
Видимо это было очень давно, во времена DirectX3 походу. Только с тех пор с Direct3D становилось проще работать, а OpenGL из компактного API превратился в тонну спагетти.

А я помню что два было. И рисовать в них надо было по разному. Короче давно было.

Да не важно при наличии QT, дотнета и прочих

Да конечно. Так сказать, дела давно минувших дней.

У меня товарищ, бывший игродел, до сих пор вспоминает — поменяли версию DirectX — все упало. После долгого секса нашли причину — в одна из функций не меняя ни названия ни имен аргументов поменяла порядок их переадчи и смысл. Т.е. компилятор это пропускал, а на рантайме в переменные писался какой-то бред.

Это то чего сильно не хватает в сях, и в Го тоже не сделано. Я о named parameters. В verilog это афигенно помогает.

Не надо трогать Python в 2017-м. Дайте ему спокойно умереть. Умоляю.
Не надо трогать C# в 2017-м. Дайте ему спокойно умереть. Умоляю.
Не надо трогать JavaScript в 2017-м. Дайте ему спокойно умереть. Умоляю.

К — конструктивность.

Чему тогда дать жить?
Я уже боюсь браться за изучение С++, потому что часто встречаю подобные выражения. Что тогда учить? ХД

Ничему. Всё мертво, кроме <вставить название любимого языка автора комментария>.

А если серьёзно, то плюсы живы и умирать не собираются. Каждый год по ним проводится куча конференций, каждые три года выпускается новый стандарт, и в своей нише плюсы пока незаменимы.
Так что если Вы хотите работать в какой-то области, где основным языком является C++ (например, ΑΑΑ-геймдев), то учите смело.

Можно параллельно с CUDA и OpenCL играться, если эта тема интересна в принципе

OpenCL как раз мертворожденный, а CUDA — да, полезна в определенных нишах.
Я ее использовал для монте-карло симуляции, где ОЧЕНЬ много paths надо было
papers.ssrn.com/…​s.cfm?abstract_id=2259133

Ещё один «то, что я не использую, мертво» :(

Я-то как раз OpenCL использовал (правда, только готовое решение).
А вот что, например, в весьма авторитетном журнале еще несколько лет назад писали: «no GPU vendor wants to implement OpenCL optimally because they have their own proprietary languages» (C. Davidson, «Chip and win: Banks expand use of GPUs». Risk magazine, Mar. 2013)

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

А чтоб не возникало подозрений что я, будучи лауреатом nVIDIA Academic Partnership Program, грант тут отрабатываю — вот статья, где я пишу про переоцененность акции nVIDIA (кстати, пока она по-прежнему прет как на дрожжах, но экспоненциальный рост бесконечным не бывает :))
letyourmoneygrow.com/…​perfect-trading-decision

Ну вот, Вы использовали. И я тоже использовал: на прошлой работе была задача, которую нужно было реализовать так, чтоб она работала не только на Нвидиевских карточках, но и на АМДшных тоже. Поэтому взяли OpenCL.
И, думаю, кроме нас двоих, OpenCL ещё кто-то использовал и продолжает использовать сегодня.
Поэтому, как мне кажется, называть OpenCL «мертворождённым» не очень правильно.

Впрочем, особо перспективным я его тоже не называл. Но если автор хочет пощупать GPGPU — по-моему, не столь принципиально, с чего именно начинать. Разобравшись с чем-то одним, он без труда перейдёт на что-то другое, если захочет.

По своему опыту скажу, что «щупать» КУДУ было гораздо проще (и при этом результативнее), чем OpenCL. Не будем забывать, что автор — новичок, и порог вхождения тут особенно важен.
Для наглядности — пример из другой оперы — желающиему вайти-в-ай-ти вебдевелопером что будете рекомендовать для начала — PHP или скажем server side java?

Возможно, Вы правы, спорить не буду. Я первым «щупал» именно OpenCL, но на тот момент я уже неплохо знал как плюсы, так и чистую сишку, поэтому больших трудностей не испытывал. Представить себя на месте новичка в такой ситуации мне сейчас сложновато.

Вообще, новичкам я бы вряд ли вообще стал рекомендовать GPGPU. По-моему, сначала стоит хорошо разобраться с «обычным» программированием на C или C++, а потом уже пробовать КУДУ или ОпенЦЛь.

А начинающим веб-девелоперам я посоветую обратиться за советом к кому-то, кто шарит в вебе. Я в нём, увы, слишком мало понимаю, чтобы давать какие-либо советы :(

Вообще, новичкам я бы вряд ли вообще стал рекомендовать GPGPU. По-моему, сначала стоит хорошо разобраться с «обычным» программированием на C или C++, а потом уже пробовать КУДУ или ОпенЦЛь.

Это точно!
Другое дело, что могут быть проблемы с мотивацией.
Я, по иронии судьбы, начинал (ну если не считать Assembler for Z80 на ZX Spectrum :)) именно с веба, но при этом хотел изучить и Яву, и плюсы.
С Явой более-менее получилось, потому что была потребность писать апплеты (да, было такое время :)).
А с плюсами — бросил, т.к. ну накой было писать на них, когда на перле или ПХП мой круг задач решался в 10 раз быстрее (в смысле написания когда, а не скорости его исполнения, конечно).
А CUDA как раз дает хорошую мотивацию ... впрочем, только если под нее есть задача, причем достаточно простая (то, что она у такая была, скорее нетипичный случай)...
Так что, пожалуй, да — не будем пудрить топикстартеру мозги, пусть выучит C++ для начала :)

Оно хотя бы как-то на встроенном интеловском видео работает)

А много ли задач для GPU, где оно должно ХОТЬ КАК-ТО работать?
По-моему, если уж берутся за GPU, то как раз хотят выжать максимум.
Если это какая-нибудь ad hoc задача (как у меня в статье), тогда берут наиболее подходящую технологию — тогда, да пожалуй и сейчас, это nVIDIA / CUDA.
Если же, допустим как в Adobe Premier — продукт массовый и нужно чтоб он хорошо работал везде, тогда, надо полагать, под каждого hardware vendor дорабатывают напильником — но это уже тема экспертов, а не новичков.

В процессе написания/отладки c обрезанным набором данных — почему нет.
Реализаций всяких алгоритмов на OpenCL тоже дофига, фермы с АМД тоже имеются.

Холиварить на эту тему неохота.

С той разницей, что ни Python, ни C# , ни JavaScript не изподвыдавливают новый стандарт каждые 3 года.
— Больной перед смертью потел?
— Потел.
— Очень хорошо.

У шарпа, джавы и прочих современных языков тоже выходят новые версии раз в какое-то время. Какое отношение имеют новые стандарты/версии языка к его «смерти»?

У шарпа, джавы и прочих современных языков тоже выходят новые версии

Версии, а не стандарты. В основном синтаксический сахарок и оптимизации.

какое отношение имеют новые стандарты/версии языка к его «смерти»?

Очень простое. Если стадарт меняю у молодого языкаэто говорит о его бурном развитии.
Когда у старого — о том, что он перестал удовлетворять потребности разработчиков, а бросить дохлую лошадь не позволяет гонор.
Повторюсь — все эти 11-14-17 это впихивание кондиционера и круизконтроля в ржавый жигуль.

В чём такое принципиальное различие между «версиями» и «стандартами»?
По мне, так

все эти 11-14-17

это как раз и есть

В основном синтаксический сахарок и оптимизации.

В C++ есть недостатки, и их потихоньку исправляют. И это не

впихивание кондиционера и круизконтроля в ржавый жигуль

— это модернизация того самого «жигуля» до такого состояния, чтобы он ездил не хуже современных машин, чтоб им было удобнее рулить и педалить, но чтобы он при этом по-прежнему расходовал меньше топлива, по сравнению с навороченными иномарками ;)

Чем больше меняют, тем страшнее он становится.

Для некоторых да. Но лично меня пока что это не коснулось. И людей, с которыми я работал последние пару лет, тоже.
Я не считаю себя каким-то особо умными и сообразительным, «схватывает на лету» это вряд ли про меня, но мне хватило пару вечеров почитать статейки и послушать некоторые доклады на ютубе, чтобы разобраться в основных нововведениях C++11. Потом зашлифовал это книгой «Effective Modern C++» Скотта Майерса, и с тех пор чувствую себя уверенно в вопросах C++11/14.

Мне кажется, что для программистов, которые решают реальные задачи на больших проектах, которые разбираются в предметной области этих проектов и понимают их (наверняка непростую) архитектуру, подобные проблемы технологического плана не должны быть особо страшными. Разобраться с технологией, по-моему, всяко проще, чем разобраться с большим проектом. Во всяком случае если у этой технологии есть внятная документация (для языка C++ это в первую очередь сайт cppreference.com).

Да. Всегда рекомендую его книги людям, которые учат C++, сразу после освоения азов этого языка. На ряду с «C++ Coding Standards» Саттера и Александреску. Даже самая старая его книга «Effective C++» до сих пор почти не устарела, за исключением парочки пунктов (возврат объектов по значению начиная с C++11 таки не очень полезный совет).

Кстати, лекции у Майерса тоже замечательные. Я долго не мог понять, как работает perfect forwarding, правила коллапсинга ссылок, «универсальные» (a.k.a. «forwarding») ссылки и прочую муть. Послушал «Type Deduction and Why You Care» — сразу всё стало ясно. У человека огромный талант внятно и простым языком объяснять сложные вещи.

Таки да, но когда работаешь на проекте без 11/14, или вообще на С, забывается за пару недель. Ну и большинство фич выглядят как «у нас есть хороший танк. давайте к нему прикрутим крылья, реактивный двигатель, ковш и зонтик.» По сути почти все это раньше спокойно делалось руками, если нужно было.

Конечно, если работать на проекте без 11/14 или на C — не спорю. Лично я себе искал проекты с хотя бы частичным C++11. Мне комфортнее летать на танке с уже прикрученными крыльями, чем прикручивать эти крылья каждый раз, когда хочется полетать :)

И не всё раньше делалось руками.
Например, std::unique_ptr был в принципе невозможен без move-семантик. Да, были разные ref-counted смарт поинтеры, но платить за хранение атомик счётчика ссылок и его постоянные инкременты-декременты, когда он на самом деле не нужен, как-то нецелесообразно. Про std::auto_ptr лучше не вспоминать.
И спецификатора override в языке раньше не было — а его использование действительно делает код намного более читабельным и менее подверженным ошибкам.
Это так, первое, что вспомнилось. Чего бы мне в первую очередь не хватало, если бы мне дали проект без C++11.

Лично я себе искал проекты с хотя бы частичным C++11. Мне комфортнее летать на танке с уже прикрученными крыльями,

Это порочная практика «поиск задачи под инструмент», вместо нормальной «поиск инструмента под задачу».
Для С++ мирка очень типично.

Задач — полный рынок. Каждый выбирает то, что ему лично нравится.

порочная практика

вместо нормальной

Мнение из Вашего мирка очень важно для нас, оставайтесь на линии.

Когда я уже работаю в конкретной компании на конкретном проекте над конкретными задачами, то я ищу инструмент под задачу, а не наоборот, как ни странно. Кто Вам сказал, что я пишу только на C++11/14 и не признаю ничего другого?
Я использовал как минимум Python, C# и «чистый» C, если говорить о той работе, за которую мне платили деньги. «Для себя» смотрел куда больше всего.

Но основным языком для меня является C++ (включая C++11). На нём я бы хотел работать большую часть времени.
Если что, «большую часть» — это ещё не значит «всё время».

И прежде, чем устроиться в компанию на некий проект, я просматриваю вакансию и заявленный в ней список технологий. И если там написано не то, с чем я хочу работать, — я не отзываюсь на эту вакансию и не иду на собеседование. Если написано «C++» без уточнения стандартов, то спрашиваю об этом при первой возможности. Потому что для меня важно писать на том, что я знаю и что мне нравится.

Удивляет такое отношение? Вызывает возмущение?
Что ж, не берите меня к себе на работу :)

Увы, но я встречал людей, которым 16-м кеглем было написано в coding rules — no templates, no exceptions, no boost, но они вместо того, чтобы гордо взмахнуть крыльями старались ну хоть маааленькое исключение протянуть через код ревью.

А причина у этих правил была?

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

Лично я к этой категории «бунтарей» не отношусь.

А на каком этапе эти люди ознакомились с сoding rules? На этапе собеседования, после принятого предложения о сотрудничестве, но до начала испытательного срока, или уже в процессе работы? Согласитесь, ответ на этот вопрос может кое-что прояснить.

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

Все равно старые серьезные проекты сидят на классике. Ну, переболеет молодежь лямбдами и фьютексами. От этого Гугл Хром на Питон не перейдет.

Кобол, Делфи и С++ :)
Кстати я уже нарвался на легаси код, который отказался собираться последним gcc с 11 версией по умолчанию. Дали буде.

А что там было такого? Если не очень трудно, можно какие-то подробности?

Если дойдут руки — исследую и выложу отдельной темой. Траблы с многопоточностью. Я просто быстро понял, что поставил сборку на локальной Убунте, а не билд-сервере, исправил и побежал дальше. Но осадочек остался.

Спасибо за ответ. Буду очень благодарным, если узнаете и выложите.

Не все старые серьёзные проекты «сидят на классике». Ясно, что переписывать старый код под новые стандарты никто уже не будет — но вот писать новый код с использованием новых фич там, где это уместно, чем-то плохим в общем случае не является. Но тут уже как команда между собой договорится.
Лично я бы испытывал определённый дискомфорт, если бы мне даже override в переопределяемой виртуальной функции написать не разрешали.

Кому в работе были нужны мьютексы — тот их использовал и до прихода C++11. Просто обходясь при этом платформозависимыми средствами, ограждаясь ифдефами (если нужно компилить под несколько платформ). Или брали соответствующие реализации из буста.
Кому были нужны всякие shared_ptr, variant, optional и т.д. — опять же, использовал соответствующие шаблоны из буста. Для таких программистов с приходом новых стандартов мало что поменяется, только вместо «boost::» они будут писать «std::».
А лямбды — просто синтаксический сахар, позволяющий быстрее и меньшим количеством кода определить функциональный объект.

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

Писали OS Abstraction Layer. Все равно, со всеми обновлениями, библиотека С++ не дотягивает до нормальных языков.

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

Частично положение спасает boost, но не для всех проектов он подходит. Зачастую от него отказываются из-за долгого времени сборки проектов — проблемы, которую призваны решить модули. Которые были обещаны к C++17, но, к сожалению, в этом году их не будет :( Самое важное не стандартизировали, тролли нехорошие.

А на чём вы в конечном счёте написали этот OS Abstraction Layer?

Я не писал, но видел в радиотелефоне на С поддержку uCOS2, Windows и Linux. По сути, just another abstraction layer — надо написать свои функции/классы для работы с мютексами, сокетами, потоками, таймерами (что еще нужно). Потом этот интерфейс имплементится для каждой поддерживаемой ОС в отдельной папке. И в компиляцию затягивается нужная папка в зависимости от ОСи. Никаких #ifdef, чистый код.
Вероятно, есть такие либы (на последнем проекте для быстрого старта заюзали code.google.com/archive/p/ting )

Коментар порушує правила спільноти і видалений модераторами.

Вот тут по геймдеву неплохие уроки: www.youtube.com/…​/UCC7qpnId5RIQruKDJOt2exw
По самому C++ советую тут посмотреть: www.youtube.com/…​/UCTGS5FRyz564wwiyNs8J54A

Из книг — Стивена Прату рекомендую: www.bookzone.com.ua/…​ogue/catalogue_20589.html

Юнити и написать свой игровой прототип какой-нить бродилки с минимальным функционалом — этого хватит на позицию Джуна ну и паралельно выучишь всё что +/- надо :)

И да с++ для входа — плохой выбор.

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

И если плюсы плохи
Какие варианты есть еще ? Ведь со временем прийдеться на них переходить или как?

Плюсы не плохи, проблема в другом — ты будешь их учить года 1,5 для того что бы написать хоть что-то похожее на игру. Что мягко говоря сильно роняет моральных дух :) Юнити позволяет сразу и учить язык который пригодится потом, а что ещё важно — очень похож на С++ во многих вещах, что позволит потом доучить пробелы в с++ когда это реально будет нужно. Ну и требования к Юнити джунам чуть ниже чем к с++ разработчикам, что позволит найти работу.

ААА тайты это конечно хорошо и интересно, но это довольно долгий путь, а Юнити позволит сразу пощупать твоё/не твоё.

Большое спасибо
Прислушаюсь к советам
И небольшой последний вопрос
Что приветствуется или обязательно знать кроме самого языка кода (не берем в расчет иностранные языки ,математику и физику)

Умение с людьми ладить :)

Обратите внимание на алгоритмы и стд.

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

Блин, я не понимаю нафига создавать такие темы?!
Буквально пару дней тому назад статья была по топ книг по ІТ!
ВОТ: dou.ua/…​/articles/top-books-2017

Дмитрий, почитайте комменты к опросу, на который вы даёте ссылку. Резюмирую — список книг для голосования выбран очень субъективно. В него не вошли многие хорошие (если не лучшие) и это справедливо для многих направлений

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

2) Реально ли выйти хотя-бы на уровень джуна в цпп за пару лет

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

Роботи вистачає jobs.dou.ua/vacancies/?category=C+
Але дуже мало для початківців.

Мені сподобалось ця книга:
Robert Lafore „Object-Oriented Programming in C++”:
(„є з російським перекладом: Объектно-ориентированное программирование в С++”)
www.amazon.com/…​bert-Lafore/dp/0672323087

бачив ще таку, наскільки якісна не знаю.
Michael Dawson „Beginning C++ Through Game Programming”
(є з російським перекладом „Изучаем C++ через программирование игр”)
www.amazon.com/…​Programming/dp/1305109910

Game Programming in C and C++:
www.cprogramming.com/game-programming.html

для дальнейшего перехода в геймдев
Вот тут чувак советует книги по геймдеву — www.youtube.com/watch?v=mSjjDcuW208

www.amazon.com/…​-Jan-Haller/dp/1849696845 — одна книженция по библиотеке SFML (прикольная библиотечка кстати — по крайней мере ее порт под .NET)

1) dou.ua/…​ev-books-for-programmers
2) Да, реально.
3) Курсы по English. Знание Git (или Mercurial) тоже поможет.

И лучше вместо Visual Studio попробуй сначала clang, gcc, который можно спокойно запустить и на Windows.

есть же фотка зачетная, что нужно прочесть для c++ gamedev, в тему будет, найти не могу к сожалению

если найдете очень хотелось бы увидеть такой материал

даю гарантию — испугаетесь)

Стоит начать с математики и физики.

1.Неплохо пишет Брюс Эккель.
Не загружает терминологией, а поэтапно объясняет что зачем.
2.Не начинай со Студии — для учебных целей лучше взять какой-нибудь программерский блокнот и компилятор командной строки.
3. Не связывайся с С++. У Python, Ruby, Go порог входа ниже, а перспективы лучше.

Visual Studio — оболочка над компилятором cl.exe. Можно запускать и cl.exe с коммандной строки)

Да хоть и так, главное, чтобы был нагляден процесс сборки, много нервов сбережет потом, когда серьные проекты будут падать с «непонятными» ошибками.

3. Не связывайся с С++. У Python, Ruby, Go порог входа ниже, а перспективы лучше.
если чел хочет в геймдев, то лучше (если не плюсы, которые являются основным языком для гемдева, насколько знаю), то си-шарп (хотя можно и питон) — руби и го в геймдеве вроде практически не юзаются.
руби и го в геймдеве вроде практически не юзаются
Нужно это исправлять. Начало положено:

— github.com/EngoEngine/engo
— github.com/tanema/amore
— github.com/tbogdala/fizzle
— github.com/vulkan-go/vulkan

Серверную часть сетевых игр уже давно пора писать на go, т.к. он идеально приспособлен для всяких там MMORPG с сотнями тысяч online-игроков.

Еще где-то был полностью софтовый рендер. Зачем, правда, не понятно

Серверную часть сетевых игр ... с сотнями тысяч online-игроков.
да, до Го выбор был либо Эрланг, либо серьезная(=дорогая) разработка на джаве, сишарпе
Нужно это исправлять. Начало положено
дай бог) будем надеятся, что эти движки таки будут (а может уже) конкурентноспособны)
И да, насчет мморпг — это таки вариант)

Potom s zasranymi mozgami slojnee

Ну ладно еще про перспективы Python можно согласиться. Но Ruby и Go?
На двоих у них вакансий ровно в два раза меньше, чем по плюсах на DOU.

Мне нравится этот подход — судить о трендах в ИТ по текущим вакансиям ДОУ.
Во-первых самые вкусные вакансии, как обычно расходятся среди своих, а на сайте висят вечно незакрываемые галерные. Как постоянный читатель рубрики С++ наблюдаю некоторые от полугода и больше.
А во-вторых, к тому времени к молодняк выучится — сегодняшняя экзотика как раз выйдет на пик тренда.

Ну так самые вкусные вакансии расходятся среди своих не только в го и руби) А то у вас взгляд однобокий получается.
По поводу экзотики — я так понимаю разговор идет о Golang. Так вот — ИМХО конечно, но у языка, который по сути так и не прижился даже в свой материнской компании (на главной недавно была статья про программера из гугла), перспективы не очень радужные.
Для примера кстати — кол-во тех же вакансий в Штатах (indeed.com)
Golang — 64 вакансии
Golang
C++ — 1452 вакансии
С++

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

Там все можно глянуть — найти резюме
C++
527 штук. Т.е. по сути отношение вакансий к резюме 3 к 1 — не все так плохо)
Но резюме по ГО там действительно меньше — 4 штуки.
А вот по вакансиям на ДОУ по соотношению вакансия/резюме Го и С++ практически одинаковы
jobs.dou.ua/…​rends/categories/2017-03
По джаве согласен, конкуренция гигантская

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

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

По факту Вам нечем подтвердить свою мысль о том, что ликвидность вакансий по го выше, чем ликвидность по плюсам, и что вакансии первых закрываются быстрее.
На самом деле это досаточно просто. Вы идете и смотрите на время показа какой-нибудь совершенно ординарной вакансии — например бекенда на Го или Питоне и какого-нибудь С++/Qt.
Я не видел вакансий первого типа висящих больше месяца.
Так вот — ИМХО конечно, но у языка, который по сути так и не прижился даже в свой материнской компании (на главной недавно была статья про программера из гугла), перспективы не очень радужные.

Go давно обогнал C++ по количеству популярных репозиториев на github, а в этом месяце обогнал и PHP:

5,315 JavaScript
2,615 Java
1,922 Python
1,387 Objective-C
1,165 Ruby
884 Go
877 PHP
788 C
776 C++
715 Swift

Так что перспективы не очень радужные у C++, а не у Go.

Когда догонит по кол-ву вакансий — приходите)

Насчёт пункта 3: смотря о каком конкретно «геймдеве» идёт речь. Если писать игрушки для мобилок, то, наверное, Вы правы. Но в ААА-сегменте у C++ конкурентов вообще нет и в ближайшие годы вряд ли появятся.

Особливо б не переймався цим. Набери в Гуглі «best c++ books». Прочитати треба всі, але від простого (C++ Primer) до складного, і паралельно кодити. Змусь себе читати англійською. Для загального розвитку прочитай також «The C Programming Language» Кернігана і Річі, щоб зрозуміти витоки C++.

Я б уточнила и первой книгой посоветовала Primer, который Липпмана. А то ещё есть Праймер Праты, а он неоч

Спасибо , заставлять себя читать на англ не нужно ибо заодно учу параллельно его .
и вопрос про

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

Студія імовірно відволікатиме тільки напочатку. Ніхто не забороняє її тобі встановити )

ИМХО Нормально со студии начинать, она вмеру удобная.
Но под какой-нибудь GCC — clang с мейфайлами ручками для разнообразия и расширения кругозора тоже пописать можно было бы, и даже было бы не плохо... но все это можно и потом.

За 2 года до трейни-джуна — вполне реально.
Как изучать, вообще зависит от того, чего именно ты хочешь, что именно в гемдеве тебя привлекает:
1. новичковскую книгу по с++ тебе уже посоветовали
2. Алгоритмы и структуры данных, можно какой-нибудь Algorithms in C++ Robert Sedgewick
3. OpenGL, он же врожде игроделам нужен?
4. Смотри на игровые движки. Unreal Engine, Unity
5. Линух, сеть и многопоточность по вкусу.

насчет пунктов 3-5 порядок зависит от того чем хочется заниматься, смотри на интересующие тебя объявления о работе, на компании — кто чем занимается и кого им надо, общайся с людьми и в зависмости от этого расставляй приоритеты.

Ну и уже сказали — писать писать и ещё раз писать.

ХЗ. У меня уже 2 года она как основной инструмент — полет нормальный. На не виндовсах любил нетбинс(кстати про неповоротливых). Писал в свое время код и в Виме.... но за пол-года надоело. Стал ценить идешки пуще пержнего.

все-же останусь на vs15 а дальше посмотрим
пока вроде все нормально

Мне cmake пригодился через 5 лет работы. В реале обычно все проекты старые, и достаточно овладеть копипастом, чтобы добавить исходник в сборку.
+ студия, кажись, слегка улучшает знаменитые маты компилятора на темплейтах.
Когда-то к ней нужен был Visual Assist для нормальной работы. Как сейчас — не знаю.

Підписатись на коментарі