×Закрыть

Советы сеньоров: как прокачать знания junior C++

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

Алексей Цой, Senior Developer в Luxoft Ukraine

14 лет опыта

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

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

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

Естественно, в этом вам помогут книги, ставшие классикой. Это Герб Саттер и его «Exceptional C++», «More Exceptional C++» и «Exceptional C++ Style». Это Андрей Александреску и его «Modern C++ Design: Generic Programming and Design Patterns Applied» и «C++ Coding Standards: 101 Rules, Guidelines, and Best Practices», написанная вместе с Саттером. И, конечно же, книги Скотта Майерса.

А вот чего не следует делать, так это браться за задачи, в которых не понятна их постановка. Это относится не к технической части, каким образом написать код, а именно к требованиям. Задавайте вопросы. Иначе есть риск сделать бессмысленную вещь, потратить проектное время, создать угрозу срыва дедлайнов. Такое не понравится никому.

И напоследок, более философское. Ответственно подходите к поиску места работы. Не стоит тратить свое время и силы на проекты, которые вам не нравятся, не интересны, кажутся неактуальными. Ведь без интереса в работе вероятность профессионального развития очень низка. И не только в IT.

Андрей Каличак, C++ Competence Lead в Perfectial

14 лет опыта

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

Очевидно, что для изучения С++ необходимы крепкие знания его предшественника — языка С. Именно с него и стоит начать знакомство с языком. С/С++ — это вообще неразлучная пара, и они всегда вместе на многих проектах и собеседованиях.

Для начинающего программиста очень важно как можно быстрее расширить свои знания. Как только будет получен критически минимальный порог знаний по стандарту языка, смежным базовым технологиям его использования (XML, DB, basic patterns/idioms), и это закрепится первым опытом, тогда свои знания можно углублять в выбранном направлении.

Не буду оригинальным и посоветую почитать в первую очередь классический труд Б. Страуструпа. И лишь потом, имея за плечами несколько килобайт написанного кода, можно приступать к более специализированным материалам, к примеру книгам Скотта Мэйерса или Герба Саттера. Они написаны в виде отдельных уроков, очень легко усваиваются. При определённом опыте и понимании это будет хорошим подспорьем в дальнейшем становлении профессионала.

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

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

Обязательно паралельно необходимо осваивать последние стандарты и технологии — C++11/14/17, библиотека Boost, Gtest, Git. Обрети уверенность в использовании хотя бы одной IDE (поиск, дебаг, рефакторинг). Это всё значительно повысит твою ценность на рынке труда.

И несколько маленьких советов, которые бы мне помогли в начале карьеры:

  • Выделяй себе время на обучение: понятно, что проект может занять всё свободное время, и на первых порах действительно все мысли лишь об удачном старте, но потом, когда войдешь в спокойное русло, не забывай постоянно увеличивать свои знания.
  • Отдавайся работе чуть больше, чем требуется: изучи часть чужого кода и найди баг, найди не очевидное, а оптимальное решение, углубись в новую библиотеку больше, чем требует этого выполнение задачи.
  • Выпрашивай себе всё более сложные задачи, даже на первый взгляд непосильные для тебя: именно так и развивается разработчик. Плюс это хорошая мотивация для тех, у кого повышено чувство собственного достоинства и амбиции.
  • Разбирай open-source код: там можно подсмотреть и научиться многим вещам.
  • Старайся посещать собрания сообщества разработчиков: тут можно позадавать вопросы на более узкие темы и познакомиться с экспертами в разных сферах.
  • Регулярно (не обязательно часто) проходи онлайн-тренинги или уроки: это разнообразит твою подготовку и позволит взглянуть под новым углом на некоторые вещи.
  • Держи баланс во всём.

Главное — помнить, что никто не стал экспертом сразу. Все прошли через определённые этапы развития, хоть и в индивидуальном русле. И ещё — это всё должно быть в кайф!

Володимир Корнійчук, Senior Software Engineer в Infopulse

12 років досвіду

Чому?
Перш за все я б порадив новачку відповісти для себе на запитання: «Чому я хочу писати на С++?». Є ціла купа причин обрати інші мови програмування — багато з них легші у вивченні та щоденному використанні. Але в С++ є те, що тримає його серед лідерів. С++ обирають за його швидкодію, ефективність, контроль апаратних ресурсів, кросплатформеність, поширеність. Якщо ці речі відповідають вашим ідеалам — ідіть у бій. Якщо хочеться, щоб «раз-раз і в продакшн» — можливо, варто обрати щось простіше?

Хто і коли?
Для розуміння філософії С++ варто трохи почитати про історію його створення та бачення мови програмування її авторами. Ще не читали книг Страуструпа? Саме час. Банальна порада, але без цього справді ніяк. Тільки беріть останні видання, а не перші.

Чи варто читати стандарт?
Стандарт мови програмування С++ в одній з останніх редакцій, що траплялася мені на очі, налічує 1622 сторінки. Як це все прочитати (з урахуванням стилю документу) і залишитися при здоровому глузді, я особисто не уявляю. Вивчення С++ по стандарту — найгірша ідея у світі. Є багато книжок, що пояснюють С++ простіше і з теоретичної, і з прикладної точки зору. Можна почати зі списку на Isocpp. А стандарт залиште розробникам компіляторів.

IDE
Підберіть зручне середовище розробки. Я використовую Visual Studio з додатково встановленим плагіном Visual Assist X. Ця зв’язка знає про мову С++ більше за все інше, що я перебирав. Знаю людей, що користуються VS + ReSharper, CLion, Qt Creator, Vim. Мені не підійшло, але ви спробуйте і матимете власну думку.

Debugger
Навчіться користуватися дебаггером (як вбудованим у вашу IDE, так і зовнішнім, типу GDB чи WinDbg). Це, на диво, потужні інструменти, що іноді дозволяють робити неймовірні речі. Більшість розробників використовують їх доволі примітивно, у режимі «поставили точку зупинки — зупинилися на ній», навіть не знаючи про можливості віддаленої роботи, time-travel debugging, підтягування зовнішніх символьних файлів та коду, зупинки по модифікації адреси пам’яті тощо.

Профайлер
Ефективність та швидкість — одні з головних причин використання С++ в сучасних проектах. Без профайлера ви ніколи не здогадаєтесь, де саме «вузьке місце» у вашому коді. Для простих випадків підійде та ж Visual Studio, для складніших — Windows Performance Analyzer або інструменти від Intel. Не пробуйте вгадати, що саме у вас працює повільно. Я бачив, як на це марнувалися тижні. Просто зробіть замір профайлером і усвідомте факти. В більшості випадків проблема буде зовсім не там, де ви її очікуєте.

Інструменти статичного аналізу
Зараз є багато інструментів, що дозволяють вказати програмісту на можливу помилку в коді на С++. Є попередження стандартного компілятора, є нові можливості Visual Studio по аналізу С++ коду на відповідність рекомендаціям C++ Core Guidelines, є аналіз коду в Visual Assist X, є Cppcheck та Clang. Багато чого є, он одна тільки Вікіпедія скільки всього знає. Обов’язково оберіть собі щось і використовуйте. Особливо добре ці інструменти працюють у комбінації з системами неперервної інтеграції.

Спеціалізовані інструменти розробки
Яку б галузь програмування ви не обрали — швидше за все ви не будете першим, хто почав e ній працювати. Ваші попередники написали багато корисних утиліт — спробуйте знайти їх та використати. Є гарні програми для допомоги системному програмісту, є корисні утиліти для графіки та геймдеву, є купа бібліотек з алгоритмами. Не пишіть свого велосипеду? доки не витратите принаймні кілька годин на пошуки вже того, що вже існує.

Тримайтеся на вістрі прогресу
Знайдіть собі якесь джерело новин про С++. Мова розвивається, виходять нові стандарти та компілятори, що їх підтримують. Особисто я читаю новини на Isocpp, обговорення — на Reddit, дивлюся відео з конференцій C++Now та CppCon. Це вимагає не так багато часу, як може здатися, але дає можливість планувати як розвиток вашого проекту, так і ваш особистий.

Николай Родин, С++ Developer в Dev-Pro

8 лет опыта

Зачем нужен С++ сегодня

Мой выбор, когда я заканчивал институт 18 лет назад, был невелик. Web-направление только набирало обороты, и у меня фактически был выбор только между Visual C++ и Delphi. Сегодня же вариантов очень много, а применение С++ найти не так легко. В стремительно развивающейся Web-индустрии ему по-прежнему нет места. Вытесняется он и из кроссплатформенного программирования. Если вам интересен этот язык — осталось всего несколько направлений, в которых С++ (и С) еще удерживают позиции (подробнее об этом можно прочитать здесь):

  1. Поддержка легаси проектов под Windows — речь о проектах, которым не один год, а может быть и не один десяток лет. Возможно, некоторым не по душе это направление, но саппорт важен и нужен. Новые проекты появляются редко, в них GUI пишется в основном с использованием библиотеки Qt.
  2. Game Development — здесь C++ актуален, ибо важно быстродействие в сочетании с определенной безопасностью.
  3. С++ под Linux — здесь С++ по-прежнему востребован ввиду развитости экосистемы. GUI вполне можно писать на Qt, драйвера и некоторые сетевые приложения пишутся даже на С.
  4. А. Embedded — здесь С и С++ удерживают твердые позиции, особенно если речь заходит о системах, работающих в реальном времени и на ограниченных мощностях.
    Б. Internet of Things все быстрее набирает популярность, активно использует C++, здесь можно добиться больших успехов.

Важно отметить, что язык C++ продолжает развиваться: от версий C++98, C++03, C++11 (C++0x), C++14 (C++1y), C++17 (C++1z) двигается к C++20 в 2020 году.

Кому стоит его изучать

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

Я бы порекомендовал этот язык тем, кто имеет тягу к написанию программ на Linux, стремится в GameDev или хочет стать Embedded Engineer и работать в перспективном IoT. Язык подойдет тем новичкам в IT-индустрии, которые считают себя перфекционистами и ищут как можно большего контроля над тем, что они делают.

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

Как изучить С++

Осваивать C++ я предлагаю от простого к сложному, начав с С. С считается низкоуровневым и поддерживает в основном процедурную парадигму. Но на его примере можно получить представление об указателях и прямой работе с памятью. Вы также научитесь мыслить битами и тактами, а не только абстракциями языка программирования и шагами алгоритмов. Помимо того, операционные системы до сих пор имеют API, написанный на С, и с ним нужно учиться взаимодействовать.
С++ поддерживает и процедурную, и объектно-ориентированную парадигму (ООП).

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

Полезная литература

Базовой книгой для изучения С считается книга Брайана Кернигана и Денниса Ритчи «Язык программирования С». Из нее можно почерпнуть информацию о стиле написания кода, основных контейнерах и обработке ошибок. Книга также приучит к ясности изложения мысли, потому что авторы всегда предлагают сначала писать комментарии, а потом уже под ними блоки кода. Это достаточно полезный навык независимо от языка.

Для изучения С++ желательно прочитать больше литературы. С++ я изучал по следующим книгам:

Советы новичкам

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

Помните, что когда попадаете в IT, как бы не готовились заранее — начинаете чувствовать пробелы в знаниях и опыте, которые даже не касаются технической квалификации. Soft skills действительно играют роль, и многие из них вы освоите, только присоединившись к реальному проекту. Здесь есть процессы, тестирование, проджект-менеджер, который держит руку на пульсе, следит за сроками и приоритетами. Иногда это тяжело принять, но окончательное решение не за тем, кто пишет код, а за тем, кто несет за него ответственность.

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

Михайло Рудий, Senior Software Developer в Vakoms

6 років досвіду

Оскільки ти вже став на цей шлях, то, мабуть, розумієш, що обрав одну з кращих мов, на якій можна писати все, починаючи від hardware, закінчуючи web.

Я б хотів поділитися кількома порадами.

Вказівник — твій найкращий друг. Вказівники, вказівники, вказівники і ще раз вказівники, бо це наше все і вони повсюди. Чим більше ти знаєш про них, тим краще.

Memory management. Навчись правильно працювати з пам’яттю. В C++ за пам’ять відповідаєш ти сам. Поки ти не скажеш «видалити» — ніхто за тебе це не зробить. Не хочеш сам керувати пам’яттю — тоді вчи smart pointers.

Класи і три страшні букви (ООП). Робота з класами — це дуже круто, тому старайся знати і вміти використовувати всі можливості класів і ООП.

Не вигадуй велосипед. У стандартній бібліотеці є вже багато готових алгоритмів, особливо для роботи з контейнерами. Тому перед тим, як писати свій метод, спочатку перевір, — можливо, він вже готовий.

В ногу з часом. C++, як і всі інші мови, розвивається, тому не забувай слідкувати за змінами в нових стандартах. Там з’являється багато цікавого і потрібного.

Design patterns. Це мегакрута річ. Почни своє знайомство з ними із простого і рухайся до складніших, закінчуй архітектурними. Головне, навчись їх правильно застосовувати.

Просто, як двері. Реалізуй задачі якомога простіше. Це буде зручно для всіх: і для тебе, і для твої колег по проекту, і для тих, хто продовжуватиме після тебе.

Запозичуй. Хочеш покращити свій код, спробуй знайти хоча б 2 рішення схожої задачі. Можливо, ти знайдеш там щось корисне для себе.

Команда. Навчися працювати в команді. Без гарних відносин робота менш якісна. Вчись розуміти інших членів команди, незалежно від їх досвіду.

Ментор. Це твій помічник, який підкаже, дасть пораду або насварить, якщо ти робиш щось дуже неправильно. Він потрібен.

Не бійся. Не бійся важких тасків (інколи вони тільки здаються важкими). Не бійся спитати поради. Не бійся сказати: «Я вже все спробував і не знаю, як це зробити. Підкажіть, куди рухатись».

Будь упевнений. Вмій відстоювати свою точку зору. Інколи твоя ідея чи варіант реалізації може бути кращий, ніж в інших, але потрібно це довести і пояснити.

Критика — це не зло. Вчися сприймати критику, якщо вона доречна. Будь стіким до неї. Вмій взяти з неї якомога більше корисного для себе.

І наостанок головне. Практика — запорука успіху. Чим більше практики — тим краще, тим більший досвід, тим швидше твої пальці самі «знатимуть», що писати. Практикуйся якомога більше. Прочитав щось цікаве в книжці або статті чи почув від когось — спробуй реалізувати, поекспериментувати. Так ти швидше все запам’ятаєш.

І знай, C++ неможливо вивчити повністю :) Завжди буде щось нове, що ти не знатимеш, тому не лякайся. Просто читай і постійно практикуйся.

Ресурси, які допоможуть:

LinkedIn

60 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

В свій час знайомився із плюсами гортаючи немодного Шилдта, якого ледь не до «C++ за 21 день» прирівнюють, «Мова C++» Страуструпа здалася занадто складною для новачка. Та й зараз як на мене вона просто нудна. А потім вже: Мейерс і Саттер, якісь довідники по STL. Александреску якось «не пішов»: для шаблонів простіше було дивитись теорію у Вандервуда й Джосатіса, а приклади — в коді Boost’а. Одна з найважливіших книг — «Дизайн та еволюція C++» Страуструпа, яка розповість чому плюси саме такі, які вони є, де там прихована якась ідея, а де — «історично склалося».

Знання C для професійного C++ розробника обов’язкові, але навіть не знаю, по чому його можна порадити вивчати. Р-К нудний і застарілий. Сучасній розробці на C воно не навчить.

Дивлюся, там радять дивитися алгоритми й структури даних, на рівні погортати довідник STL воно обов’язкове, але отой п’ятитомник, яким всі марять, на практиці майже не використовується. Я б краще порадив подивитись інші мови на базовому рівні, щоб краще розуміти особливості саме плюсів. От, наприклад, Objective-C для розуміння того, як ще можна було зробити надбудову над C, або Java як приклад іншого підходу до класів і наслідування.

А я начинал с K&R и Страуструпа. Да нудно написано, но это же техническая литература, а не художественная. Ну а после Майерс и Вандервуд с Джосатисом.

Знання C для професійного C++ розробника обов’язкові, але навіть не знаю, по чому його можна порадити вивчати. Р-К нудний і застарілий. Сучасній розробці на C воно не навчить.

* Modern C: icube-icps.unistra.fr/...​auth.php/d/db/ModernC.pdf
* 21st century C: shop.oreilly.com/product/0636920025108.do

Очевидно, что для изучения С++ необходимы крепкие знания его предшественника — языка С. Именно с него и стоит начать знакомство с языком. С/С++ — это вообще неразлучная пара, и они всегда вместе на многих проектах и собеседованиях.

Как на меня, не очевидно, и вааще очень спорная мысль про «неразлучную пару». Подход выглядит логичным и естественным, если вспомнить, например, что сам начинал учиться си с Кернигана-Ритчи в 85 году (1985, если чо :) как только книжку напечатали), когда плюсы были еще в памперсах. Но усвоив например сишные принципы работы с памятью и пересев за плюсы, может показаться м-м-м необязательным следовать подходам RAII, если рядом все прекрасно работает и так. На сегодня, если программировать надо только на С++ и учиться с нуля, то знакомство именно с сишкой я бы ограничил указателями. Ессно, если уже есть знания С или других языков программирования, то м-м-м делать им аборт поздно :) , важно указать на особенности плюсов.

С++ поддерживает и процедурную, и объектно-ориентированную парадигму (ООП).

Если бы :(. Поддерживал. А с середины 90-х он, нехароший такой, еще обобщённое программирование поддерживает (и чем дальше, тем больше и больше), чему аналогов в сишке нема :(. Соответственно и знакомство с С не поможет иногда даже прочитать код, написанный с использованием шаблонов.

Чи варто читати стандарт?
Стандарт мови програмування С++ в одній з останніх редакцій, що траплялася мені на очі, налічує 1622 сторінки. Як це все прочитати (з урахуванням стилю документу) і залишитися при здоровому глузді, я особисто не уявляю. Вивчення С++ по стандарту — найгірша ідея у світі. Є багато книжок, що пояснюють С++ простіше і з теоретичної, і з прикладної точки зору. Можна почати зі списку на Isocpp. А стандарт залиште розробникам компіляторів.

...золотые слова

Стандарты не надо читать. Их надо знать :8)

...если ты разработчик компилятора :) Иначе это бессмысленно.
Во-первых, слишком много лишних деталей, которые в жизни не пригодятся, плюс слишком сухие наукообразные формулировки, тяжёлые для понимания.
Во-вторых, после изучения различных деталей стандарта, включая «тёмные закоулки» языка, человека в жизни ждёт разочарование, когда он увидит, что практически ни один компилятор на 100% стандарту не следует. Хоть где-то, но встречаются несоответствия. Которые на практике в большинстве случаев мало кого волнуют.
Так что сомнительная тема.

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

Щас набегут александрескухейтеры, будет весело :)
Вообще, его почитать стоит, но сильно позже всего остального.
Ни в коем случае нельзя ставить в один ряд его сольную работу «Modern C++ Design» с 101 советиками, написанными совместно с Саттером. Последнее можно читать сразу после освоения азов и получения некоторого практического опыта написания кода. Вместе с книгами Майерса и сольными работами Саттера.
А всякую шаблонную магию — уже потом, если будет интерес.

читать стоит, но не для новичков. еще толковая книга по шаблонам C++ Templates: The Complete Guide (Jossutis/Vandervoode)

Для тех кто м-м-м начинает жить с С++ и Linux-ом, посоветовал бы почитать это:
Advanced Linux Programming,
Mark Mitchell, Jeffrey Oldham, and Alex Samuel

Где сейчас хорошие задачи для C++? (не ембеддед и не легаси написанное 20 лет назад). Когда-то любил с++ но свалил с него в джаву, т.к. стало мало работы :-(

Где сейчас хорошие задачи для C++

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

Всё связанное с ML. Питоны хороши до тех пор, пока не упираешься в железо и потом нужна глубо4кая оптимизация на плюсах или С.
Кроме того, С++ и С нужны везде, где упираешься в ресурсы железа на высокоуровневых языках.

QuantLib — мое всё. Впрочем, сложность плюсов (а там попадаются навороты типа наследования от template-класса, в результате чего иерархия наследования выстраивается только в runtime и doxygen ее не видит) — мелочь в сравнении со сложностью предметной области (финансовой математики).

Вот плюсую. Практически на любом реальном проекте, за который платят деньги, сложность предметной области будет в разы выше сложности C++. Тем более, что про C++ есть масса хороших книжек, статей, докладов и всего остального — подтянуть знания проблемы не составит, было бы желание. Чего зачастую не скажешь о прокачке своих знаний предметной области, для которой кроме кода перед глазами и объяснений коллег может ничего и не быть.

Ну, по предметной области обычно тоже материалов достаточно. Другой вопрос — что выбрать курс в этом море информации — тоже задача не из тривиальных. Да и базовое образование нужно — я ведь тоже с уеб-девелопмента начинал, и для того что перейти в quantitative finance мне понадобилось два года в немецком универе проучиться.
При этом интересно, что программисты часто не хотят вникать в предметную область — мол мое дело лишь технологии и код. Но рынок все расставляет на свои места: в той же Германии чисто программер получает брутто ну порядка €60K, программер же со знанием предметной области может рассчитывать на €80K и более.

Ну так этих предметных областей 100500 и не известно в какой ты затра окажеся. Учить и знать их нужно, даже обязательно, но если ты С++ разработчик, то С++ дял тебя — first thing.

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

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

В основном всякие «биржедрочеры» с их «low latency» ну и просто потому что модно биржедроческий софт на сишечке писать даже если «роботы» у них там на питоне и их «переводить» приходится ))

трейдерские платформы на с++ были популярны лет наверное 10-15 назад, не знаю их нынешнее состояние, возможно уже переписали на чем-то другом. еще были системы для операторов мобильных сетей, но сейчас там тоже много джавы и прочего. есть еще область для с++ — всякие CAD-системы с 3д-визуализацией, не гуй а их ядро , где вычисления производится

У нас цікаві задачі: секюріті, віртуалізація, драйвера. Все це на С++11 і вище.

какая предметная область? защита и антивирусы?

Пасивний моніторінг, активний захист (контроль процесів, файлів, реестра, захист від інжекта кода і тд), секюрні сендбокси, захист від витоку інформації, цифрова криміналистика, вітруальні девайси (звук, відео, прінтер, сканер, вебкамера), віддалений доступ, тощо.

И драйвера на си++11?

Так, під Windows та macOs пишемо драйвера на ядерному С++ (без STL та ексепшенів).

на ядерному С++

Є якийсь стандарт що до цього?

А для

macOs

?

без STL

Використовуєте (можливо, самописні) аналоги?
Чи взагалі обходитесь без шаблонних контейнерів та алгоритмів?

Є свої самописні бібліотеки з драйверними контейнерами, примітивами сінхронізації, стрінгами і т.д.

На кой ляд С++ тем, кто с ним никогда не столкнется?

да ... ньюанс только в том, что если не дай’Бо столкнеЦЦа, то учить будет поздно :) ибо як казав Лесь, «одразу видно шо до.уя» :))

Навчись правильно працювати з пам’яттю. В C++ за пам’ять відповідаєш ти сам. Поки ти не скажеш «видалити» — ніхто за тебе це не зробить. Не хочеш сам керувати пам’яттю — тоді вчи smart pointers.

Ну така собі порада. В С++ немає бути naked new/delete і всюди треба використовувати розумні показчики. Робити в С++ це руцями — поганий стиль.

А использовать умные указатели где ни попадя — хороший стиль?
Если не умеешь работать с памятью, то всё равно выстрелишь себе в ногу: циклические ссылки и прочие ошибки использования никто не отменял.

циклические ссылки

Как будто их так легко получить. Для этого нужно не просто плохо кодить, а придумать архитектуру, допускающую это явление.
Что, к счастью, не так часто встречается

это на уровне задач для собеседования для продвинутых. из той же серии «как создать deadlock» или «как создать memory leak в языке со сборщиком мусора»

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

Зачем тогда их придумали и добавили в язык, если не использовать?
Понятно, что есть направления, требующее максимальной производительности, то там прийдется использовать «голые» указатели, но в остальных случаях shared_ptr/unique_ptr и вперед.

Понятно, что есть направления, требующее максимальной производительности, то там прийдется использовать «голые» указатели, но в остальных случаях shared_ptr/unique_ptr и вперед

При понимании этих «умных указателей» и корректном их юзании накладные микроскопические или нулевые нынче.

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

shared_ptr уже не бесплатный и там есть нюансы.

Из С++17 тоже все обязательно использовать в каждом проекте?

Он разве говорил про «каждый проект»?

Если использование фичи имеет смысл — использовать. Не имеет — не использовать. Всё просто.
Но знать о нововведениях нужно, дабы не усложнять себе жизнь там, где новая фича её может упростить.

Например, в шаблонном коде constexpr if должен стать первым, о чём думает программист, желающий вызвать одну или другую реализацию в зависимости от каких-нибудь известных в компайл-тайме свойств типа. Вместо старых костылей под названием tag dispatch или SFINAE.

все обязательно использовать

Здесь вопрос интересный в уточнениях что значит «всё» и что значит «использовать».

Вот из новейшей истории прилетает свежий патч оп-па собирается только под 17-м стандартом и место же ж такое замысловатое непонятно чего хотят шаблоны вот это всё ну я то его ещё с появления буста помню лечить попоболь не проблема смотрю значит «стандарт» оп-па оказывается shared_ptr до 17-го не поддерживает «шаред поинтер массива» решение правда есть но оно ну так уже просто по виду «красиво но через попу сразу видно» и потом это решение уже не собирается в 17-м ок смотрю дальше зачем там вообще этот «шаред поинтер» ищу куда он это сказал оказывается никуда он это не сказал это вообще scope guard чтобы этот массив динамически выделить и затем соотв. не париться об его удалении ну ок разумный подход но если мы его никуда не шарим то зачем shared_ptr? ставлю просто набоум unique_ptr (вот что опыт животворящий делает!) и о чудо всё работает всё везде собирается вообще вот это всё вообще без запинки оказывается unique_ptr ещё с 11-го стандарта эту фишку «смарт поинтер массива» в себе поддерживает ну и славно! но зачем там вообще собственно смарт поинтер понадобился? смотрю что вообще делается ну явно чисто буфер выделяется что-то там на 1 килобайт не больше и ни в каких суперциклах и глубоких алгоритмах это место никак не участвует и вообще обычное десктоп приложение как раньше жили!?

ОК смотрю «как раньше жили» нахожу ещё +100500 совершенно аналогичных мест в которых как я и задумал этот буфер на 1 килобайт выделяется прямо по стеку...

... и стало всем хорошо!

А морали не будет. ))

ЗЫ: и не спрашивайте меня зачем буффер понадобилось динамически выделять именно как массив ну а и в самом деле как ещё в «плюсах» кусок памяти «нестатической» длины динамически выделить? ))

кусок памяти «нестатической» длины динамически выделить?

Эмм...) std::vector?)
Хотя да, он сожрёт дополнительно ещё две ячейки памяти по 8 байт (на 64-битной архитектуре): под хранение своих size и capacity.
Так что если важно их не аллоцировать, то, действительно, разумное решение — это std::unique_ptr.

Неясно, зачем там вообще std::shared_ptr лепили изначально, раз не хотели ни с кем шарить.
Это ж помимо всего прочего ещё и лишние накладные расходы на хранение контрольного блока (который выделяется отдельной аллокацией, т.к. make_shared для массива планируют добавлять только в C++20)...

Короче, проблема не в фичах, а в их бездумном использовании.

Эмм...) std::vector?)

(бъёт себе ладонью по лбу) йопта а ведь и точно классика же ж! )) Сам их +100500 раз использовал именно в таком виде.

т.к. make_shared для массива планируют добавлять только в C++20)...

Нет там именно выделение под буфер инициализация уже потом «путём использования чистого куска памяти» читай там просто char[1000] только кому-то решилось «выделить его динамически».

Короче, проблема не в фичах, а в их бездумном использовании.

Именно! Вот же ж жизненный пример на лицо.

Вот из новейшей истории прилетает свежий патч оп-па собирается только под 17-м стандартом

Гораздо хуже, когда никто не стоит над этим процессом. Особенно ударенные ради никому не нужных «удобств» и «фичей» ставят бета компиляторы и задают общую конву для проекта. Майкрософт заявляет, что поддерживается только xx% фичей свежего стандарта в новом компиляторе, а проект уже вовсю зависит от этих фичей. И если потом появляются грабли в других местах, то это уже твои проблемы и даунгрейдить компилер не получится. Вот только из-за этой «особенности» С++ разработчиков я всегда с ужасом открещиваюсь от больших С++ проектов. Первый вопрос на какой стандарт ориентируемся? На самый последний! Пройдите в сад!

Первый вопрос на какой стандарт ориентируемся? На самый последний! Пройдите в сад!

+100500.

никому не нужных «удобств» и «фичей»

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

На самый последний!

А вы много встречали компаний, которые ориентируются на самый последний стандарт?
Я не особо ходок по собеседованиям, но ни разу не сталкивался с такой крайностью.
Зато встречал «особенно ударенных» в обратную сторону: полный консерватизм, C++98/03 и всё тут. Почему не апгрейдитесь — «а мы так привыкли, нинужны нам ети ваши новые стандарты, чортзнаетшо там понапридумывали, лень разбираться, и так ведь всё работает».

По-моему, обе крайности одинаково плохи.
Естественно, в 2018 году ориентироваться на C++17 рановато. А вот на C++14 — самое оно, компиляторы с поддержкой этого стандарта давно вышли из состояния беты.

На 11. Потому что есть куча других завязок: например, кому-то требуется RHEL/CentOS stable, а там на борту GCC 4.8 как основной (про rh/devtoolset в курсе, но кого-то может пугать просто отдельность источника).
Разница между 11 и 14 для большинства задач, по-моему, не настолько критична, чтобы бегать за 14-м (а вот между 11 и 98 или даже 03 — пропасть).

Про консерватизм факт — когда я только пришёл на последнюю работу, там 11-й был ещё недопустим. В результате в проекте куча хвостов типа «а тут можно делать только в стиле C с классами» или «применим boost там, где 11 давно дал встроенные средства».

На 11. Потому что есть куча других завязок

Где-то есть, где-то нет. Конечно, там, где они есть, стоит быть поконсервативнее в плане стандартов.
Я сейчас работаю с кодом, который должен компилиться 2015 вижуал студией и последним клангом — там большая часть C++14 уже доступна. Мы знаем, что на более старые компиляторы нам это переносить не придётся, так что проблем нет.

С остальным согласен.
Ещё видел, как люди упорно продолжали использовать shared_ptr везде, где на самом деле достаточно unique_ptr. И поддержка C++11 у них уже была. Просто кому-то было лень разбираться с move-семантиками :)
Стоит ли нежелание разбираться с чем-то новым лишнего оверхеда по памяти на хранение контрольного блока и по времени — на атомик инкременты/декременты реф каунта? Я не уверен.

Мазги в принципе для того и дадены программеру, чтобы разобраться в многообразии хрени, с которой можно работать в плюсах, и выбрать в перспективе наименее глючный вариант :8) Но если основная задача — это минимизация «стрельбы по ногам», то я бы предпочел «умные» указатели.

Робити в С++ це руцями — поганий стиль.

Поганий стиль це не знати свій тулчейн і не знати коли щось доцільно зробити руцями, а коли покладатись на автоматичні механізми.

І згоден, і не дуже.
Використання смарт поінтерів повинно стати дефолтним варіантом. Приблизно так само, як і використання std::vector має стати першим, що приходить в голову, коли тобі потрібен контейнер.

Якщо немає причин робити по-іншому — використовуй смарт поінтери.
Але в специфічних сценаріях такі причини можуть бути. І тоді можна попрацювати з ресурсами вручну.

Тому я згоден з твердженням, що будь-який С++ програміст повинен вміти працювати з пам’яттю. Так само, як і вміти працювати зі стандартними смарт поінтерами.

Але далі, звісно, з фразою

В C++ за пам’ять відповідаєш ти сам. Поки ти не скажеш «видалити» — ніхто за тебе це не зробить.

автор трохи перегнув.
Зробить, ще й як. Якщо ти пишеш саме на С++, а не на «C з класами», чи знаходишся в якомусь дуже обмеженому середовищі, використовуючи невелику підмножину C++.
Для цього навіть не обов’язково використовувати смарт поінтери, достатньо звичайного класу з деструктором.

Плюсую Николая.

Порада новачку читати Страуструпа це не ок, як на мене.
Але дуже великий + йому за пораду вивчати класичні алгоритми та структури даних.

Порада новачку читати Страуструпа це не ок, як на мене.

Ок, якщо говорити про іншу книжку. Та, яка «Principles and Practice» :)
А от навіщо новачкам радити «The C++ Programming Language», я теж не розумію. Це скоріше настільна книга для програмістів, які вже знайомі з мовою і бажають освіжити свої знання по окремих темах.

Особисто мені, при всій повазі до пана Б’ярне, його книги якось дуже важко читаються, той же Майерс набагато простіше, хоча теж його книги сприймаю виключно як довідники по конкретним питанням.
Саме для початківців я б порадив книжку Ліпмана: www.amazon.com/...​-B-Lippman/dp/0321714113
Хоча й об’ємна, але не дуже важко читається і охоплює все, що потрібно.

Ну не знаю. «Принципи і практику» я взяв в руки надто пізно, вже коли не був новачком, так що з цієї позиції не оціню. Але здалося, що як підручник для навчання з нуля вона доволі непогана.
А Маєрса я читав від початку до кінця, не відриваючись, зовсім не як довідник :)

Приятно видеть знакомые лица :)

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