Есть какой-то один человек, который занимается поддержкой кучи IDE?
Присоединяюсь к вопросу.
Если нужно поправить cmake, чтобы любимая IDE работала корректно, то делаешь пул реквест с нужными изменениями.
В проектах, над которыми я работала и в которых IDE у контрибьютеров отличались, был третий вариант: IDE-специфичные настройки не должны попадать в общий репозиторий. Поэтому каждый разработчик заносил такие файлы в .gitignore. И если требовалось допиливание CMakeLists.txt, подкручивал свое окружение так, чтобы подключать кастомный CMakeLists.txt и довносить в него изменения, если меняется CMakeLists.txt в репе.
Именно это мы и написали в данной статье, практически дословно=) А также о том, что целевая аудитория нашего курса - разработчики, которым требуется выучить C++. То есть люди с ненулевым багажом знаний и опыта.
Ну не может компетентный C++-разработчик не представлять, во что его структуры выложатся в памяти, как компилятор реализует виртуальные функции, как раскручивается стек при исключениях, и т.д.
Да. Обо всем этом мы и собираемся рассказать. Чтобы понимать, как это устроено, нужно копнуть низкоуровневое подмножество С++. Постольку поскольку C++ появился как надстройка над Си, будут затронуты сишные конструкции.
В моём представлении требования к компетентному C++-разработчику включают в себя
Меня смущает, что вы говорите про разработчика на C++, но в 3-х пунктах из 4-х C++ вообще отсутствует (вместо него асм, линкер-скрипты и Си), а в 1-м пункте присутствует, но в связке с Си.
В моем представлении требование к компетентному C++ разработчику в первую очередь такое: хорошо решать задачи бизнеса. А бизнес хочет:
Чтобы код писался относительно быстро.
Чтобы в код было быстро и предсказуемо вносить правки.
Чтоб не крешился.
Чтобы его нельзя было заабьюзить (например переполнениями буфера).
Чтобы новичок мог открыть проект и быстро вкатиться.
Следовательно, компетентный разработчик должен писать безопасный, читабельный, стабильный и масштабируемый код. Уметь его оптимизировать, если на то есть необходимость. Без Modern C++ получить комбинацию всего это трудно. Поэтому начинать изучение C++ логично именно с этого подмножества.
Кстати, скорее всего, у нас с вами очень разный бэкграунд) У меня в основном высоконагруженный бэкенд и сдк для мобилок (например, навигационный движок, который должен исполняться на старых телефонах и не жрать как ни в себя память/батарею). И я ни разу за 10 лет не писала ассемблерных вставок. Несколько раз я их видела. Каждый раз они как-то между делом выпиливались в пользу рефакторинга архитектуры. Который как раз фиксил самые серьезные бутылочные горлышки.
Интересно было бы послушать про ваш бэкграунд и про ситуации, в которых ассемблерным вставкам нет альтернатив.
Ваш комментарий подтолкнул меня к мысли, что придется проговорить в первой же главе, кто наша целевая аудитория. Примерно как в вашей цитате. Потому что в этом посте мы дважды говорили про ЦА. В первых строках и в пункте про то, каким должен быть курс:
Целевая аудитория курса — программисты. От студентов до синьоров с десятками лет опыта в других языках. Для них не придется раздувать текст объяснениями, что такое функции, массивы, переменные. К тому же, если вы никогда не программировали, начинать с C++ не стоит.
А студентами мы называем наших пользователей, потому что "пользователи курса" звучит как-то странно)
Зато после полугода интенсивной практики программирования на чистых сях у студента не останется вопросов, зачем нужны шаблоны, RAII, исключения, корутины и модули, потому что он на своей шкуре прочувствует, какого без них.
Вот это отдельно прокомментирую)) Как появился котлин? На момент его создания некоторые вещи в java делались неудобно. Или отсутствовали. Котлин снял эту боль с разработчиков.
А теперь представим программиста, которому по работе нужно вкатиться в котлин. Или он его заинтересовал, и разработчик хочет сделать на нем пет-проект. Или хочет сменить стек. То есть мотивация вполне приземленная, практическая. Это не академик, который изучает ЯП и их историю и имеет в запасе сто лет.
Получается, этот разработчик, чтобы выучить котлин, вначале должен выучить старую java образца 2011 года? Пол года на ней интенсивно прогать, и только после этого позволить себе сесть-таки за котлин?
Такой подход имеет право на жизнь. И он довольно распространенный. Например, у Константина Владимирова есть офигенные лекции, и в них обучение C++ стартует после Си.
Однако Си и C++ на момент 2024 г. - это два разных языка. Мифического C/C++ нет. В этих языках разные подходы к структуризации кода, к тому, что правильно - а что нет. Да вообще угол, с которого разработчик смотрит на решаемую задачу - разный. Если студент привыкнет писать на Си, он так и продолжит применять приемы/практики из Си в С++. Это будет плохой код.
Очень рекомендую доклад Кейт Грегори "Stop teaching C". В нем она говорит, что Си - прекрасный язык. Но если вы погружаетесь именно в C++, не стоит его учить в стиле "сначала Си, а потом мы поверх наворачиваем C++".
Да там и по тому же расту информации меньше чем в кукбуке
Сравнивать кукбук (набор примеров кода) и учебник нельзя. У них разная цель. Если имеется в виду растбук, то он завершен, а наш курс в процессе написания. Но раз уж на то пошло, давайте сравним степень погружения в каждую тему. В растбуке вещественным числам посвящено полтора абзаца с простейшим примером кода в стиле let x = 2.0; // f64.
У нас про числа с плавающей точкой отдельная глава. Потому что это тема, на которой многие спотыкаются. В главе разобрано, как floating point хранятся в памяти, как их сравнивать, какие есть нюансы работы с ними, нечисловые значения констант, методы f32 и f64и далее по списку.
Ключевое слово - кажется. Либо вы считаете, что программисты под Win не нужны.
Ну, скажем так, мое "кажется" подкреплено хоть какой-то статистикой. Если вы ей не доверяете, приведите свою. Или организуйте опрос на хабре и мы посмотрим на результаты. Это интересно.
Сборка и её время - одна из болевых точек при работе с языком, вносимое в том числе и платформами
В курсе по язык C++ рассказывать про нюансы работы с разными пакетными менеджерами под разными платформами = комбинаторный взрыв и неблагодарное дело. Один только CMake тянет на полноценный курс. Вы не согласны?
Самое сложное в C++ - это непосредственно C++. А не Conan. И не настройка плагина для VSCode. В первой главе и в главе про сборку мы накидываем баззворды: названия тулчейнов, систем сборки, автоматизации сборки. У каждого из них есть актуальные мануалы. Если со всем этим багажом студент курса не осилит на своей ОС настроить сборку, то... про это @Serpentine хорошо откомментил)
Самый естественный и логичный подход для изучения любого языка - учить его, отталкиваясь от свежих версий. И по необходимости уделять внимание особенностям старых версий.
Следование "историческому развитию" оправдано только на старте изучения программирования. И это относится не к языку программирования, а к стилю программирования. Человечество начало с императивного стиля, потому что так было проще всего. Вот и школьнику проще всего будет писать тупой императивный код. Потом появились функциональщина, ООП и т.д. И после того, как будущий программист освоил императивный подход, он сможет по достоинству оценить что-то более удобное и современное.
Но мы-то делаем курс не для школьников. А для практикующих разрабочтиков, которые хотят выучить C++. И начинать с яйца для них будет странным. Давайте тогда вначале выучим Си. Потом посмотрим на "Си с классами". И далее будем наслаивать стандарты. Да, такой подход может сработать. Но согласитесь, он далек от оптимума по соотношению затраченных сил/времени к результату.
TLDR; У нас ровно такие же взгляды на процесс обучения. И ничего из сказанного вами не противоречит нашему подходу к подготовке курса.
В этой статье мы ни разу не упомянули геймификацию, разжевывание материала, переупрощение и избегание сложных тем! Кажется, словосочетание "онлайн-курс" уже настолько дискредитировано и опошлено, что эти практики дефолтно приписываются любым интерактивным материалам.
Теперь по пунктам.
если тебе сложно освоить базовые понятия типа pointer в C++
Вы можете заглянуть в оглавление, которое мы сейчас обсуждаем. Вы убедитесь, что в курсе будут и указатели, и адресная арифметика, остальные обязательные атрибуты C++) Мы всего лишь хотим сказать, что начинать изучение современного C++ с них - это устаревший подход. Можно сделать лучше.
или ты не можешь просто найти документацию и прочитать самостоятельно, задавать вопросы, найти ответы и так далее.
В курсе будут практические проекты. У нас задумка реализовать их таким образом, чтобы отпускать пользователя в самостоятельное плавание по cppreference.
Если сидеть с разжованной ложкой где все доступно на подносе - ты только бери, то если чуть плеснуть масла в огонь и все посыпется. На выходе получаем слабака.
У нас есть готовый курс по питону. Мы получили на него много положительных отзывов. Пользователи рассказывали, как после курса успешно устраивались на новую работу со сменой стека (middle+). Так вот. По нашей статистике вайтишники срезались на первых же главах. Поэтому нет, на выходе мы не получаем слабака. Он срезается гораздо раньше. В курсе по C++, я так полагаю, он будет срезан на первых же абзацах первой главы)
Мне кажется что в глубине засела какая то нездоровая идейность, что если я выучу язык и устроюсь на работу, мне будут платить очень много денег
Самое важное: наши курсы - не для вайтишников. Наши курсы - для разработчиков, которые учат данный конкретный язык с нуля.
И я не вижу ничего плохого в том, чтобы учить язык с комфортом. Мы живем в 21 веке! Мы можем позволить себе учиться эффективно! Выполнять проекты и отправлять их на проверку юнит-тестам и статическим анализаторам. А не выполнять задачки из pdf-книжки и уповать, что все сделал правильно без проверки третьей стороной.
Тот интерактив, который предлагаем мы, наоборот позволяет избавиться от иллюзии получения знаний. Ну прочитал ты главу книги Страуструпа. А как ты поймешь, что все запомнил? Что понял все правильно, нигде не осталось белых пятен? Тут как-раз таки помогает интерактив. То есть написание кода, хорошо покрывающего только что прочитанную теорию. И тщательная проверка того, что ты сделал. А не сова из дуалингво)
Я думаю что нужно не упрощать а усложнять, но при этом давать понимание как работает компьютер, память, процессор, и так далее по списку. На выходе мы должны получить человека который видит картину а не кусочек пазла и все это в привычном виде, без облегчающего до уровня copy-paste дизайна.
Мы стараемся составить курс так, чтобы сложилась цельная картина мира C++. А не мозаичная. И там, где будут требоваться низкоуровневые детали - мы их дадим.
но явно не в том исполнении, что представлен у вас на сайте.
У нас на сайте сейчас нет курса по C++. О каком именно исполнении вы говорите?
Ни про модель памяти, ни про системы сборки ни в одном не увидел.
А где вы смотрите? Мы устаканиваем оглавление курса. Там обе темы есть.
Если на питоне-хаскеле-го с их стандартной библиотекой такое относительно просто провернуть, то в С++ тут уже надо добавлять curl в зависимости, подключать boost.asio.
Можно подключить в зависимости условный restinio, и запилить микросервис будет не сложнее, чем на го.
В главе про сборку про это в принципе не упомянуто как впрочем и про менеджеры пакетов/зависимостей а ля conan, chocolatey/scoop/winget/nuget и прочих.
В главе про сборку есть блок про пакетные менеджены. В частности, про conan. Какой процент разработчиков использует chocolatey/scoop/winget/nuget? Кажется, что исчезающе маленький. Если мы будем в курсе по языку C++ уделять много внимания инфраструктурным нишевым тулзам, то курс станет огромным.
Отдельно стоит заметить про разницу сборки под разными OS.
Плюс CMake в том, что он кроссплатформенный. С ним относительно легко добиться кроссплатформенной сборки. Или вы имеете ввиду что-то другое?
слова сборка всегда вызывает только одну ассоциацию БОЛЬ.
А Cmake'ом какой версии пользуетесь? Есть так называемый Modern Cmake, и в нем собирать кроссплатформенные проекты, работать с зависимостями, со сложными иерархиямии директорий сильно, сильно легче.
Нет никакого смысла популяризировать курс по плюсам каким бы замечательным он ни был если тупо собрать пустой проект это реальная боль.
У C++ отсутствует стандартный сборщик, да. Но ставить из-за этого жирный крест на языке - слишком радикально) Боль при сборке - это проблема в первую очередь макроязыка CMake, а не C++. И как я писала выше, она должна быть облегчена начиная где-то с CMake 3.15.
Какой смысл учит как работать с современным вектором/хэш мапом/флат мапом и не рассказывать про память если любая мутирующая операция инвалидирует чуть менее чем все в этом контейнере
C++ - это торт-наполеон из абстракций. Не обязательно вдаваться в детали работы сырых указателей и адресной арифметики, чтобы объяснить абстракции итераторов, их инвалидирования и подкапотного устройства контейнеров. Про сырые указатели и все такое у нас тоже будет. Но не сразу.
бесконечно страдать от непрекращающихся фолс позитив
Опять же, ложные срабатывания линтеров - это не недостаток самого C++. Они меня доставали и в проектах на питоне.
Юнит тесты, ага вот вам с десяток опций, но так что бы просто взять и подключить в проект без боли нету.
В каких-то командах приветствуется использование системно установленных пакетов. Тогда просто инклюдится условный гугл тест, и вперед. В каких-то командах предпочитают втаскивать либу для тестов внутрь проекта. Если понимать, как работает CMake, то это тоже делается недолго.
Модули - все ещё просто не работают.
С некоторыми ограничениями они уже поддержаны. Вот только что на GCC сбилдила проект с использованием модуля print.
Корутины - ни в коем случае нельзя учить корутинам - они не предназначены для прямого использования, это фича языка исключительно для библиотеко писателей с серьезным опытом.
Чтобы использовать корутины, студент должен сначала понять, что это такое) Этот рассказ потянет на целую главу. После чего почему бы их не использовать в связке с 3rd party либой? Потому что вы абсолютно правы, в стандарте не корутины, а скорее фреймворк для их разработки)
Рэейнджи - та часть что рабатает почти вся нахер не нужна, только сложнее код получается,
Рейнджи позволяют выстраивать пайплайны обработки данных в функциональном стиле. Соответственно привносят в код плюсы функционального подхода. Но это вкусовщина)
а там где рэнджи полезны (обработка пары контейнеров) они ещё не работают.
А можно пример фичи рейнджей, которая вам кажется полезной, но которая еще не поддержана вендорами?
никакие супер пупер классные курсы не помогут привлеч новых юзеров, слишком уж болючая первая доза получается.
В том-то и фишка, что не обязательно все озвученное принимать первой дозой! Если хорошо продумать порядок тем для погружения в C++, у студента на старте не будет этого болевого шока)
с++ получил ссаными тряпками от анб полностью за дело и комитет уже работает в правильном направлении. Без волшебного пендаля от АНБ до сих пор бы никто и не почухался.
Техники для безопасной работы с памятью активно добавляются еще со времен C++11. Уже тогда в языке можно было пользоваться умными указателями и RAII. А АНБ смешал в одну кучу Си и C++, "не заметил" фичей Modern C++ и сделал вывод, что C++ пора отменять.
По статистике от jetbrains, на GCC 65% разработчиков, на MSVC - 31%. Понятно, что статистика перекошенная. Она показывает разброс среди пользователей продуктов jetbrains, а не по индустрии в целом. Но хоть что-то.
Среди моих знакомых и коллег на домашних и рабочих компах преобладает Линукс. Но это еще менее репрезентативная выборка)
Вот прямо особенности GCC будут всплывать буквально в паре глав. Чтобы воспроизвести эксперименты под виндой, достаточно будет запустить контейнер с GCC.
Так что пока мы в этом особых сложностей не видим.
Пояса были отличными открытыми курсами. Их идея структуризации материала во многом совпадает с нашей. Но если сравнивать, то мы более хардкорные (но без фанатизма).
Например, в докладе про Пояса Илья Шишков сказал следующее: какой питонист будет проходить наш курс, если у нас словарь всплывает через 1.5 месяца?
С одной стороны, мы согласны, что чем раньше студент сможет решать на C++ практические задачи - тем лучше. С другой стороны, мы не будем делать все, лишь бы студент не соскочил. Например, мы считаем, что для нормальной разработки нужно знать, как вообще выглядит процесс сборки. Что есть препроцессор, что есть линкер. Поэтому глава про сборку проекта будет идти перед условной "главой про словарь". И мы готовы к тому, что часть народу это отпугнет.
@okhsunrogАпдейт! Этот код без изменений собирается связкой clang 19 + ninja + cmake 3.31.
mkdir build && cd build && cmake -Wno-dev -GNinja .. &&ninjaВариант CMakeLists.txt можно посмотреть у нас в плэйграунде. Только вчера выкатили)
Интересно. Это наблюдение из вашего личного опыта или можно где-то посмотреть статистику?
Он есть в нашем виш-листе ;) Но на данный момент в приоритете курс по C++.
Присоединяюсь к вопросу.
В проектах, над которыми я работала и в которых IDE у контрибьютеров отличались, был третий вариант: IDE-специфичные настройки не должны попадать в общий репозиторий. Поэтому каждый разработчик заносил такие файлы в .gitignore. И если требовалось допиливание CMakeLists.txt, подкручивал свое окружение так, чтобы подключать кастомный CMakeLists.txt и довносить в него изменения, если меняется CMakeLists.txt в репе.
Именно это мы и написали в данной статье, практически дословно=) А также о том, что целевая аудитория нашего курса - разработчики, которым требуется выучить C++. То есть люди с ненулевым багажом знаний и опыта.
Да. Обо всем этом мы и собираемся рассказать. Чтобы понимать, как это устроено, нужно копнуть низкоуровневое подмножество С++. Постольку поскольку C++ появился как надстройка над Си, будут затронуты сишные конструкции.
Меня смущает, что вы говорите про разработчика на C++, но в 3-х пунктах из 4-х C++ вообще отсутствует (вместо него асм, линкер-скрипты и Си), а в 1-м пункте присутствует, но в связке с Си.
В моем представлении требование к компетентному C++ разработчику в первую очередь такое: хорошо решать задачи бизнеса. А бизнес хочет:
Чтобы код писался относительно быстро.
Чтобы в код было быстро и предсказуемо вносить правки.
Чтоб не крешился.
Чтобы его нельзя было заабьюзить (например переполнениями буфера).
Чтобы новичок мог открыть проект и быстро вкатиться.
Следовательно, компетентный разработчик должен писать безопасный, читабельный, стабильный и масштабируемый код. Уметь его оптимизировать, если на то есть необходимость. Без Modern C++ получить комбинацию всего это трудно. Поэтому начинать изучение C++ логично именно с этого подмножества.
Кстати, скорее всего, у нас с вами очень разный бэкграунд) У меня в основном высоконагруженный бэкенд и сдк для мобилок (например, навигационный движок, который должен исполняться на старых телефонах и не жрать как ни в себя память/батарею). И я ни разу за 10 лет не писала ассемблерных вставок. Несколько раз я их видела. Каждый раз они как-то между делом выпиливались в пользу рефакторинга архитектуры. Который как раз фиксил самые серьезные бутылочные горлышки.
Интересно было бы послушать про ваш бэкграунд и про ситуации, в которых ассемблерным вставкам нет альтернатив.
Ваш комментарий подтолкнул меня к мысли, что придется проговорить в первой же главе, кто наша целевая аудитория. Примерно как в вашей цитате. Потому что в этом посте мы дважды говорили про ЦА. В первых строках и в пункте про то, каким должен быть курс:
А студентами мы называем наших пользователей, потому что "пользователи курса" звучит как-то странно)
Вот это отдельно прокомментирую)) Как появился котлин? На момент его создания некоторые вещи в java делались неудобно. Или отсутствовали. Котлин снял эту боль с разработчиков.
А теперь представим программиста, которому по работе нужно вкатиться в котлин. Или он его заинтересовал, и разработчик хочет сделать на нем пет-проект. Или хочет сменить стек. То есть мотивация вполне приземленная, практическая. Это не академик, который изучает ЯП и их историю и имеет в запасе сто лет.
Получается, этот разработчик, чтобы выучить котлин, вначале должен выучить старую java образца 2011 года? Пол года на ней интенсивно прогать, и только после этого позволить себе сесть-таки за котлин?
Такой подход имеет право на жизнь. И он довольно распространенный. Например, у Константина Владимирова есть офигенные лекции, и в них обучение C++ стартует после Си.
Однако Си и C++ на момент 2024 г. - это два разных языка. Мифического C/C++ нет. В этих языках разные подходы к структуризации кода, к тому, что правильно - а что нет. Да вообще угол, с которого разработчик смотрит на решаемую задачу - разный. Если студент привыкнет писать на Си, он так и продолжит применять приемы/практики из Си в С++. Это будет плохой код.
Очень рекомендую доклад Кейт Грегори "Stop teaching C". В нем она говорит, что Си - прекрасный язык. Но если вы погружаетесь именно в C++, не стоит его учить в стиле "сначала Си, а потом мы поверх наворачиваем C++".
Сравнивать кукбук (набор примеров кода) и учебник нельзя. У них разная цель. Если имеется в виду растбук, то он завершен, а наш курс в процессе написания. Но раз уж на то пошло, давайте сравним степень погружения в каждую тему. В растбуке вещественным числам посвящено полтора абзаца с простейшим примером кода в стиле
let x = 2.0; // f64.У нас про числа с плавающей точкой отдельная глава. Потому что это тема, на которой многие спотыкаются. В главе разобрано, как floating point хранятся в памяти, как их сравнивать, какие есть нюансы работы с ними, нечисловые значения констант, методы
f32иf64и далее по списку.Ну, скажем так, мое "кажется" подкреплено хоть какой-то статистикой. Если вы ей не доверяете, приведите свою. Или организуйте опрос на хабре и мы посмотрим на результаты. Это интересно.
В курсе по язык C++ рассказывать про нюансы работы с разными пакетными менеджерами под разными платформами = комбинаторный взрыв и неблагодарное дело. Один только CMake тянет на полноценный курс. Вы не согласны?
Самое сложное в C++ - это непосредственно C++. А не Conan. И не настройка плагина для VSCode. В первой главе и в главе про сборку мы накидываем баззворды: названия тулчейнов, систем сборки, автоматизации сборки. У каждого из них есть актуальные мануалы. Если со всем этим багажом студент курса не осилит на своей ОС настроить сборку, то... про это @Serpentine хорошо откомментил)
Самый естественный и логичный подход для изучения любого языка - учить его, отталкиваясь от свежих версий. И по необходимости уделять внимание особенностям старых версий.
Следование "историческому развитию" оправдано только на старте изучения программирования. И это относится не к языку программирования, а к стилю программирования. Человечество начало с императивного стиля, потому что так было проще всего. Вот и школьнику проще всего будет писать тупой императивный код. Потом появились функциональщина, ООП и т.д. И после того, как будущий программист освоил императивный подход, он сможет по достоинству оценить что-то более удобное и современное.
Но мы-то делаем курс не для школьников. А для практикующих разрабочтиков, которые хотят выучить C++. И начинать с яйца для них будет странным. Давайте тогда вначале выучим Си. Потом посмотрим на "Си с классами". И далее будем наслаивать стандарты. Да, такой подход может сработать. Но согласитесь, он далек от оптимума по соотношению затраченных сил/времени к результату.
TLDR; У нас ровно такие же взгляды на процесс обучения. И ничего из сказанного вами не противоречит нашему подходу к подготовке курса.
В этой статье мы ни разу не упомянули геймификацию, разжевывание материала, переупрощение и избегание сложных тем! Кажется, словосочетание "онлайн-курс" уже настолько дискредитировано и опошлено, что эти практики дефолтно приписываются любым интерактивным материалам.
Теперь по пунктам.
Вы можете заглянуть в оглавление, которое мы сейчас обсуждаем. Вы убедитесь, что в курсе будут и указатели, и адресная арифметика, остальные обязательные атрибуты C++) Мы всего лишь хотим сказать, что начинать изучение современного C++ с них - это устаревший подход. Можно сделать лучше.
В курсе будут практические проекты. У нас задумка реализовать их таким образом, чтобы отпускать пользователя в самостоятельное плавание по cppreference.
У нас есть готовый курс по питону. Мы получили на него много положительных отзывов. Пользователи рассказывали, как после курса успешно устраивались на новую работу со сменой стека (middle+). Так вот. По нашей статистике вайтишники срезались на первых же главах. Поэтому нет, на выходе мы не получаем слабака. Он срезается гораздо раньше. В курсе по C++, я так полагаю, он будет срезан на первых же абзацах первой главы)
Самое важное: наши курсы - не для вайтишников. Наши курсы - для разработчиков, которые учат данный конкретный язык с нуля.
И я не вижу ничего плохого в том, чтобы учить язык с комфортом. Мы живем в 21 веке! Мы можем позволить себе учиться эффективно! Выполнять проекты и отправлять их на проверку юнит-тестам и статическим анализаторам. А не выполнять задачки из pdf-книжки и уповать, что все сделал правильно без проверки третьей стороной.
Тот интерактив, который предлагаем мы, наоборот позволяет избавиться от иллюзии получения знаний. Ну прочитал ты главу книги Страуструпа. А как ты поймешь, что все запомнил? Что понял все правильно, нигде не осталось белых пятен? Тут как-раз таки помогает интерактив. То есть написание кода, хорошо покрывающего только что прочитанную теорию. И тщательная проверка того, что ты сделал. А не сова из дуалингво)
Мы стараемся составить курс так, чтобы сложилась цельная картина мира C++. А не мозаичная. И там, где будут требоваться низкоуровневые детали - мы их дадим.
У нас на сайте сейчас нет курса по C++. О каком именно исполнении вы говорите?
А где вы смотрите? Мы устаканиваем оглавление курса. Там обе темы есть.
Можно подключить в зависимости условный restinio, и запилить микросервис будет не сложнее, чем на го.
В главе про сборку есть блок про пакетные менеджены. В частности, про conan. Какой процент разработчиков использует chocolatey/scoop/winget/nuget? Кажется, что исчезающе маленький. Если мы будем в курсе по языку C++ уделять много внимания инфраструктурным нишевым тулзам, то курс станет огромным.
Плюс CMake в том, что он кроссплатформенный. С ним относительно легко добиться кроссплатформенной сборки. Или вы имеете ввиду что-то другое?
Мы выбирали между clang и gcc. Нас остановило то, что на данный момент в clang поддержано чуть меньше фичей из последних стандартов.
Спасибо за
крик душиразвернутый комментарий)А Cmake'ом какой версии пользуетесь? Есть так называемый Modern Cmake, и в нем собирать кроссплатформенные проекты, работать с зависимостями, со сложными иерархиямии директорий сильно, сильно легче.
У C++ отсутствует стандартный сборщик, да. Но ставить из-за этого жирный крест на языке - слишком радикально) Боль при сборке - это проблема в первую очередь макроязыка CMake, а не C++. И как я писала выше, она должна быть облегчена начиная где-то с CMake 3.15.
C++ - это торт-наполеон из абстракций. Не обязательно вдаваться в детали работы сырых указателей и адресной арифметики, чтобы объяснить абстракции итераторов, их инвалидирования и подкапотного устройства контейнеров. Про сырые указатели и все такое у нас тоже будет. Но не сразу.
Опять же, ложные срабатывания линтеров - это не недостаток самого C++. Они меня доставали и в проектах на питоне.
В каких-то командах приветствуется использование системно установленных пакетов. Тогда просто инклюдится условный гугл тест, и вперед. В каких-то командах предпочитают втаскивать либу для тестов внутрь проекта. Если понимать, как работает CMake, то это тоже делается недолго.
С некоторыми ограничениями они уже поддержаны. Вот только что на GCC сбилдила проект с использованием модуля print.
Чтобы использовать корутины, студент должен сначала понять, что это такое) Этот рассказ потянет на целую главу. После чего почему бы их не использовать в связке с 3rd party либой? Потому что вы абсолютно правы, в стандарте не корутины, а скорее фреймворк для их разработки)
Рейнджи позволяют выстраивать пайплайны обработки данных в функциональном стиле. Соответственно привносят в код плюсы функционального подхода. Но это вкусовщина)
А можно пример фичи рейнджей, которая вам кажется полезной, но которая еще не поддержана вендорами?
В том-то и фишка, что не обязательно все озвученное принимать первой дозой! Если хорошо продумать порядок тем для погружения в C++, у студента на старте не будет этого болевого шока)
Техники для безопасной работы с памятью активно добавляются еще со времен C++11. Уже тогда в языке можно было пользоваться умными указателями и RAII. А АНБ смешал в одну кучу Си и C++, "не заметил" фичей Modern C++ и сделал вывод, что C++ пора отменять.
Если заменить
import std;наimport <print>;, то GCC это компилирует (версия 14.2.1, но поддержка появилась еще раньше).Спасибо за развернутный ответ!
Не-не-не, так и до ассемблерных вставок пол шашечки))
По статистике от jetbrains, на GCC 65% разработчиков, на MSVC - 31%. Понятно, что статистика перекошенная. Она показывает разброс среди пользователей продуктов jetbrains, а не по индустрии в целом. Но хоть что-то.
Среди моих знакомых и коллег на домашних и рабочих компах преобладает Линукс. Но это еще менее репрезентативная выборка)
Вот прямо особенности GCC будут всплывать буквально в паре глав. Чтобы воспроизвести эксперименты под виндой, достаточно будет запустить контейнер с GCC.
Так что пока мы в этом особых сложностей не видим.
Пояса были отличными открытыми курсами. Их идея структуризации материала во многом совпадает с нашей. Но если сравнивать, то мы более хардкорные (но без фанатизма).
Например, в докладе про Пояса Илья Шишков сказал следующее: какой питонист будет проходить наш курс, если у нас словарь всплывает через 1.5 месяца?
С одной стороны, мы согласны, что чем раньше студент сможет решать на C++ практические задачи - тем лучше. С другой стороны, мы не будем делать все, лишь бы студент не соскочил. Например, мы считаем, что для нормальной разработки нужно знать, как вообще выглядит процесс сборки. Что есть препроцессор, что есть линкер. Поэтому глава про сборку проекта будет идти перед условной "главой про словарь". И мы готовы к тому, что часть народу это отпугнет.