Просто задать ключ -fno-exceptions при сборке своего проекта - мало. Потому что тогда проект слинкуется с libstdc++ или libc++, в которой оператор new кидает исключения. Чтобы стандартная либа тоже не кидала исключения, ее нужно предварительно собрать с этим же флагом. И линковать проект уже с ней. Тогда да, вызовется abort().
Еще дока GCC предлагает альтернативу: вместо -fno-exceptions для C++ кода добавить -fexceptions для сишного кода, который дергает плюсовый. Результат, правда, тот же: abort(), если исключение пролезет в сишный код:
This will make debugging a C language function called as part of C++-induced stack unwinding possible. In particular, unwinding into a frame with no exception handling data will cause a runtime abort. If the unwinder runs out of unwind info before it finds a handler, std::terminate() is called.
Еще стандартный new можно переопределить глобально для проекта. Фактически сделать его прослойкой для вызова malloc(). Правда тогда нельзя будет использовать стандартные контейнеры, они-то расчитывают на исключения при неудачной аллокации)
Но с другой стороны, наилучший ли это выбор - затаскивать стандртные контейнеры в Панголин? Они подходят для общего случая, а для специфики СУБД лучше подобрать что-то более эффективное.
Есть какой-то один человек, который занимается поддержкой кучи 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++ пора отменять.
Просто задать ключ
-fno-exceptionsпри сборке своего проекта - мало. Потому что тогда проект слинкуется с libstdc++ или libc++, в которой операторnewкидает исключения. Чтобы стандартная либа тоже не кидала исключения, ее нужно предварительно собрать с этим же флагом. И линковать проект уже с ней. Тогда да, вызоветсяabort().Еще дока GCC предлагает альтернативу: вместо
-fno-exceptionsдля C++ кода добавить-fexceptionsдля сишного кода, который дергает плюсовый. Результат, правда, тот же:abort(), если исключение пролезет в сишный код:Еще стандартный
newможно переопределить глобально для проекта. Фактически сделать его прослойкой для вызоваmalloc(). Правда тогда нельзя будет использовать стандартные контейнеры, они-то расчитывают на исключения при неудачной аллокации)Но с другой стороны, наилучший ли это выбор - затаскивать стандртные контейнеры в Панголин? Они подходят для общего случая, а для специфики СУБД лучше подобрать что-то более эффективное.
Очень показательно и характерно, что единственный ответ вб сводится к "напишите в чат поддержки на Wildberries" ;)
@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, но поддержка появилась еще раньше).Спасибо за развернутный ответ!
Не-не-не, так и до ассемблерных вставок пол шашечки))