Comments 90
Да, можно взять нетбинс и книжку. Можно взять вим, плагины к вим и видеолекции. Из точки А ("я не умею в C++") можно разными способами добраться до точки Б ("теперь умею"). Вопрос в том, сколько времени и энергии потратится для получения одного и того же результата. Зачем идти пешком, если можно долететь на самолете? Это и есть вопрос эффективности. Если можно выстроить обучение так, чтобы было и удобно, и полезно, то почему бы этим не воспользоваться.
Собственно я столкнулся с похожими проблемами, когда код на питоне уже не тянул мои задачки (я физик) и надо было осваивать что-то производительное. Выбирал между C++ и Раст. В Раст тебя сразу берут под ручку, мол, вот у нас Rust-book, Rust by example, Rust by Practice, Rust playground, а еще это "модно, хайпово, молодежно" а с си++ такой прямой дорожки нет или отдай двеститыщ за курсы (с зп научного сотрудника, ага) или колупайся как хошь. А еще конечно раст комьюнити очень активное. Ну я, пожал плечами и выбрал раст. Но и хоть глазком взглянуть на плюсы желание осталось.
Дейтел - Как программировать на C++
Вполне прямая дорожка: найти хорошо написанную книгу, прочитать и выполнить все задачи.
Возможно, C++17 еще хорошей книги нет, но C++14 точно есть (см.выше).
Нельзя недооценивать человеческий фактор. Какой процент читателей книги честно выполнит все задачи? А как проверить, что задача решена правильно и не падает на хитрых кейсах?
Во-вторых, зачем начинать погружение в язык с заведомо старых версий? Стандарт C++23 уже принят. Большинство его фичей поддержано вендорами компиляторов. Да, формально C++17 - это Modern C++. Но объективно - это пред-предыдущая версия языка. Даже код на C++17 и C++20 уже может разительно отличаться.
Ну, современный C++ начинается с C++11, и почти всё, внесённое в язык тогда, вполне себе актуально (хотя нередко и расширено). Так что как отправную точку вполне можно рассматривать именно его, а не C++17 -- конечно, с учётом обучения с нуля, а не расширения знаний тех, кто давно уже язык использует. В частности, при первоначальном обучении не обойтись без указателей, а значит, без nullptr вместо NULL -- а это как раз C++11. А вот говоря о типах, включённых в сам язык, нужно говорить и о char8_t -- а это C++20.
Ну а код будет разительно отличаться только при использовании новых крупных вещей, добавленных в C++20, -- скажем, модулей и сопрограмм. Если такое не используется (а при начальном обучении это практически неизбежно), особой разницы не будет.
особой разницы не будет.
Предположу, что вам так кажется, потому что вы привыкли к C++. А с точки зрения разработчика, который впервые видит C++, разница колоссальная.
C++23:
import std;
int main() {
std::println("Hello World");
}Код выглядит простым, не вызывает никакого недоумения.
C++17:
#include <iostream>
int main() {
std::cout << "Hello World" << std::endl;
}Что за #? Почему одна строка закончилась точкой с запятой, а другая - нет? У треугольных скобочек в строке 1 и строке 4 разная семантическая нагрузка? Код выглядит не единообразно. И тут у автора обучающего материала два пути:
Уважаемый читатель, тебе сейчас ничего не понятно, но ты расслабься. Прими эти странные конструкции как данность, и на протяжении десятков глав ты разберешься, что здесь к чему. Мне этот подход не нравится, потому что тебя призывают перестать задавать вопросы. Что при изучении чего-то нового - так себе подход.
Соберись, тряпка. И слушай: сверху - макрос. Cout - это объект-синглтон. Endl - это функция. А треугольные скобочки, ох уж эти треугольные скобочки.. И этот подход мне тоже не нравится. На читателя вываливается тонна информации, которая ему на данном этапе не нужна.
Поэтому если есть такая возможность, то лучше знакомиться с C++ с последних стандартов. А потом - да, при необходимости или при желании заныривать глубже и глубже.
Поэтому если есть такая возможность, то лучше знакомиться с C++ с последних стандартов. А потом - да, при необходимости или при желании заныривать глубже и глубже.
И после курса ты приходишь на проект с легаси времён начала века, который еле еле переполз в 2024 году на С++11 и такой упс, а где import, а где println?
Действительно, есть такой неприятный риск. Но хочу накинуть несколько возражений:
Если человек хорошо разобрался в свежих стандартах языка, то он сможет разобраться и в старых. Для него это будет подмножеством уже знакомого языка.
Мы обещали мотивированность подачи. Это означает, что к необходимости каких-то фичей мы будем подходить издалека: откуда растут ноги у фичи, как жили ДО нее. То есть студенты курса будут знакомы и с кусочками более старых стандартов.
Сейчас конец 2024 года. Пока мы доделаем курс, пока студент его пройдет... С++23 уже не будет восприниматься таким супер-свежим.
Да, многие компании в 2024 году сидят на С++11. А многие - раз в три-четыре года переходят на новый стандарт. Кто-то - быстро, кто-то - с лагом. Но тут мы возвращаемся к моему предыдущему поинту.
Более того, модули, кроме как в современной VS, могут вполне себе не работать или работать плохо. Пробовал относительно недавно с ARMCLANG -- наткнулся на кучу типа ошибок, которых быть не должно (аналогичный код в VS компилировался без проблем). Сопрограммы работают, но IDE (Keil) подглючивает, особенно на отладке. Ну и т.д. и т.п. И, опять-таки, даже обучая современному, надо показывать и древности, объясняя, чем они хуже и почему с ними всё-таки, с приличной вероятностью, придётся встречаться на практике.
Блин а C++23 выглядит даже вполне себе адекватно. Надо бы его опробовать. Он даже стал походить на нормальный язык. Может даже вернусь к C++
Что за #? Почему одна строка закончилась точкой с запятой, а другая - нет? У треугольных скобочек в строке 1 и строке 4 разная семантическая нагрузка?
Если начинать изучать спокойно и все по-порядку, таких вопросов в принципе не может возникнуть. Так как любая книга начинается с разбора препроцессора, заголовочных файлов и т.д.
Какой компилятор и с какими опциями сможет скомпилировать такой код с import std ?
На текущий момент полная поддержка модулей есть только в msvc. В clang ведутся работы, есть продвижение. В gcc всё плохо с модулями. Источник:
https://github.com/royjacobson/modules-report
import std;
int main() {
std::println("Hello World");
return 0;
}
Пример, указанный выше можно собрать с помощью msvc. В настройках проекта нужно указать:
C/C++->Language->Build ISO C++23
C/C++->Language->Enable Experimental C++ Standard Library Modules->/std:c++latest
C/C++->Language->Build ISO C++23 Standard Library Modules->Yes
P.S. Не разбирался как это сделать с помощью CMake. Но вроде как поддержка модулей включена в CMake, начиная с версии 3.28.
Если заменить import std; на import <print>;, то GCC это компилирует (версия 14.2.1, но поддержка появилась еще раньше).
Всё равно мне кажется, что лучше начинать учить плюсы со старых стандартов. Я нашёл книгу С++ Prime, по ней сейчас занимаюсь. Некоторые странные выпады этого языка я воспринимаю как должное. Ну и, потом уже можно смотреть, что изменилось в С++14, 17, 20 и 23. Там изменений не так много, но это отбросит некоторые сложности в начале обучения.
Самый естественный и логичный подход для изучения любого языка - учить его, отталкиваясь от свежих версий. И по необходимости уделять внимание особенностям старых версий.
Следование "историческому развитию" оправдано только на старте изучения программирования. И это относится не к языку программирования, а к стилю программирования. Человечество начало с императивного стиля, потому что так было проще всего. Вот и школьнику проще всего будет писать тупой императивный код. Потом появились функциональщина, ООП и т.д. И после того, как будущий программист освоил императивный подход, он сможет по достоинству оценить что-то более удобное и современное.
Но мы-то делаем курс не для школьников. А для практикующих разрабочтиков, которые хотят выучить C++. И начинать с яйца для них будет странным. Давайте тогда вначале выучим Си. Потом посмотрим на "Си с классами". И далее будем наслаивать стандарты. Да, такой подход может сработать. Но согласитесь, он далек от оптимума по соотношению затраченных сил/времени к результату.
Давайте тогда вначале выучим Си.
Вообще говоря, давайте. Си — на два порядка проще плюсов, и, так или иначе, его всё равно придётся выучить. Зато после полугода интенсивной практики программирования на чистых сях у студента не останется вопросов, зачем нужны шаблоны, RAII, исключения, корутины и модули, потому что он на своей шкуре прочувствует, какого без них.
Такой подход имеет право на жизнь. И он довольно распространенный. Например, у Константина Владимирова есть офигенные лекции, и в них обучение C++ стартует после Си.
Однако Си и C++ на момент 2024 г. - это два разных языка. Мифического C/C++ нет. В этих языках разные подходы к структуризации кода, к тому, что правильно - а что нет. Да вообще угол, с которого разработчик смотрит на решаемую задачу - разный. Если студент привыкнет писать на Си, он так и продолжит применять приемы/практики из Си в С++. Это будет плохой код.
Очень рекомендую доклад Кейт Грегори "Stop teaching C". В нем она говорит, что Си - прекрасный язык. Но если вы погружаетесь именно в C++, не стоит его учить в стиле "сначала Си, а потом мы поверх наворачиваем C++".
Но если вы погружаетесь именно в C++
Вот только C++ отвратителен как первый язык. Погружаться в плюсы, не имея базы приемлемой низкоуровневой базы, как по мне, неудачная идея. Ну не может компетентный C++-разработчик не представлять, во что его структуры выложатся в памяти, как компилятор реализует виртуальные функции, как раскручивается стек при исключениях, и т.д. И тут можно опираться только на ассемблер (в совсем низкоуровневых вещах) да на си без плюсов (в менее низкоуровневых).
Это будет плохой код.
На самом деле нет. Плохой код будет только в том случае, если после курса по C студент решит, что и С++ он уже знает и незачем ещё чему-то учиться. Таких людей обучать можно любым языкам в любой последовательности, с тем же результатом.
Но согласитесь, он далек от оптимума по соотношению затраченных сил/времени к результату.
(В ответ на сообщение уровнем выше)
Это зависит от того, каким вы видите результат. В моём представлении требования к компетентному C++-разработчику включают в себя:
знание отличий C и C++;
умение при необходимости программировать на C в согласии с местными идиомами (привет
goto exit;);умение при необходимости сориентироваться в ассемблерном листинге;
способность при необходимости разобраться, как написать ассемблерную вставку или линкер-скрипт, даже если это нужно всего раз в год.
Вот только C++ отвратителен как первый язык.
Именно это мы и написали в данной статье, практически дословно=) А также о том, что целевая аудитория нашего курса - разработчики, которым требуется выучить C++. То есть люди с ненулевым багажом знаний и опыта.
Ну не может компетентный C++-разработчик не представлять, во что его структуры выложатся в памяти, как компилятор реализует виртуальные функции, как раскручивается стек при исключениях, и т.д.
Да. Обо всем этом мы и собираемся рассказать. Чтобы понимать, как это устроено, нужно копнуть низкоуровневое подмножество С++. Постольку поскольку C++ появился как надстройка над Си, будут затронуты сишные конструкции.
В моём представлении требования к компетентному C++-разработчику включают в себя
Меня смущает, что вы говорите про разработчика на C++, но в 3-х пунктах из 4-х C++ вообще отсутствует (вместо него асм, линкер-скрипты и Си), а в 1-м пункте присутствует, но в связке с Си.
В моем представлении требование к компетентному C++ разработчику в первую очередь такое: хорошо решать задачи бизнеса. А бизнес хочет:
Чтобы код писался относительно быстро.
Чтобы в код было быстро и предсказуемо вносить правки.
Чтоб не крешился.
Чтобы его нельзя было заабьюзить (например переполнениями буфера).
Чтобы новичок мог открыть проект и быстро вкатиться.
Следовательно, компетентный разработчик должен писать безопасный, читабельный, стабильный и масштабируемый код. Уметь его оптимизировать, если на то есть необходимость. Без Modern C++ получить комбинацию всего это трудно. Поэтому начинать изучение C++ логично именно с этого подмножества.
Кстати, скорее всего, у нас с вами очень разный бэкграунд) У меня в основном высоконагруженный бэкенд и сдк для мобилок (например, навигационный движок, который должен исполняться на старых телефонах и не жрать как ни в себя память/батарею). И я ни разу за 10 лет не писала ассемблерных вставок. Несколько раз я их видела. Каждый раз они как-то между делом выпиливались в пользу рефакторинга архитектуры. Который как раз фиксил самые серьезные бутылочные горлышки.
Интересно было бы послушать про ваш бэкграунд и про ситуации, в которых ассемблерным вставкам нет альтернатив.
А также о том, что целевая аудитория нашего курса - разработчики, которым требуется выучить C++. То есть люди с ненулевым багажом знаний и опыта.
Пока дочитал статью до конца, забыл начало.
Даже безотносительно опыта и знаний студентов, я всё же считаю, что C++ относится к тем технологиям, которые нельзя нормально понять и эффективно использовать без изучения внутреннего устройства. Си прям неплохо подходится для этого: вверх по абстракциям идти проще, чем вниз.
Меня смущает, что вы говорите про разработчика на C++, но в 3-х пунктах из 4-х C++ вообще отсутствует
Так мой тезис же был про то, что C++-разработчику нужно знать и то, что не си++.
Интересно было бы послушать про ваш бэкграунд
Я бы назвал свой бэкграунд «R&D без привязки к языку», в последнее время больше с FPGA работаю. Из недавнего на си++ — математика (линейная алгебра, многопараметрическая оптимизация), микроконтроллеры (да, на C++), тестбенчи для FPGA-кода (если добавить к Verilator немного обвязки на корутинах, получает весьма неплохо по производительности и выразительности кода). Периодически пишу что-нибудь с кнопками при помощи Qt.
... ситуации, в которых ассемблерным вставкам нет альтернатив.
Например, когда вам нужно написать свой (или адаптировать вендорный) стартовый файл для нового микроконтроллера. Увести МК в прерывание. На лету переключить потоку стек. Вставить memory fence, CAS, векторную инструкцию. Часть этих кейсов закрывается интринсиками, но например, интринсиков под нужные инструкции RISC-V в компиляторе может просто ещё не быть.
Куда чаще на ассемблер приходится смотреть, чтобы хотя бы поверхностно понять, заинлайнились ли вызовы, догадался ли компилятор развернуть или векторизовать цикл, и тому подобное.
Ну, нельзя же так! Имея очень специфическую сферу деятельности, проецировать свой опыт на весь мир. Это не потому что Ваша сфера деятельности плохая. Напротив, звучит круто: R&D, программирование микрокронтроллеров, глубокое погружение в тему. Очевидно, что Ваша работа требует высокой квалификации.
Но. R&D != разработка ПО. Работа c "железом" всего лишь одно из направлений, где используется C++. Сфера применения C++ гораздо шире. Пока ещё. Нелепо приходить из одной сферы в другую со своим представлением о прекрасном. Вас не поймут.
Из того, что Вы написали мне ничего не близко. Но вот, что мешает жить от проекта к проекту (за редким исключением):
Проблемы с архитектурой:
1.1. слабая декомпозиция — огромные функции и god классы;
1.2. чрезмерная декомпозиция — архитектура вся такая гибкая, вот только не там где нужно, а где нужно — негибкая;
1.3. неудачные архитектурные решения — за время существования проекта, требования к нему могут измениться кардинально, и принятые решения, адекватные прежде, становятся помехой."Велосипеды" — отчасти из-за того, что некоторые проекты старые, отчасти из-за отсутствия стандартного пакетного менеджера и общего хранилища библиотек в экосистеме C++;
Плохая читабельность кода (говнокод).
И как этому поможет знания C или ассемблера? Никак. Пусть лучше будущий C++ разработчик поглубже изучит язык и почитает книги с полезными советами, как стоит делать, а как делать не надо. (Глядишь и говнокодить не станет.) Вместо изучения C и ассемблера.
P.S. Теперь понятно почему Константин Владимиров с твердой уверенностью заявляет, что std::format не нужен. Возмутительно. При всём уважении к Константину. Но возмутительно.
За ассемблерные вставки не скажу, я их делал всегото не больше чем пальцев на одной руке за 20 лет и то наверное все в первые 5. Например я делал реализацию не вытесняющей многопоточности / юзер мод трэды на мобильной платформе чье название я уже и не вспомню, т.к. апи их не предоставлял, а задача была перенести джэй2к игры с одного телефона на другой и как раз на Яве были потоки и самое быстрое простое и надёжное решение было из сделать там где их не было. Второй случай я смутно помню был как то связан с борьбой с оптимизациями компилятора при написании измерений для микробенчмарка. Если и делал ещё какие то вставки то уже и не помню. Т.е. это очень специфично в мире продуктовой разработки.
Но вероятно человек под асм вставками имел ввиду интринсики, которые встречаются намного чаще. Симд интринсики я применяю регулярно раз в 5 лет, уверен кто то и чаще. Число дробилка без симда как водка без пива - деньги на ветер. И если на вашем железе нет мощной видеокарты (да и это не панацея), но цпу поддерживает симд - то альтернативы интринсикам просто нет.
Это зависит от того, каким вы видите результат. В моём представлении требования к компетентному C++-разработчику включают в себя:
знание отличий C и C++;
умение при необходимости программировать на C в согласии с местными идиомами (привет
goto exit;);умение при необходимости сориентироваться в ассемблерном листинге;
способность при необходимости разобраться, как написать ассемблерную вставку или линкер-скрипт, даже если это нужно всего раз в год.
Извините, но у Вас очень специфические представления о том, что должен знать компетентный C++ разработчик. Предположу, что они искажены предметной областью, которой Вы занимаетесь. Компетентный C++ разработчик должен хорошо знать С++ и его стандартную библиотеку. Это основное. Всё остальное зависит от предметной области. Например:
Бэкенд разработчику могут потребоваться знания реляционных/нереляционных баз данных и очередей, умение настраивать CI/CD, знание скриптового языка (очень популярна связка C++ и Python).
Рендеристу потребуется знания графического API (Metal, OpenGL, DirectX, Vulkan) и алгоритмов компьютерной графики, опыт написания шейдерных программ.
Разработчику десктопных приложений потребуется знания Qt, QML и возможно WinAPI, если целевая ОС — Windows.
Почти всегда есть требование знать примитивы синхронизации и уметь разрабатывать многопоточные приложения. Часто требуется знание CMake. В большинстве мест, где используется C++ знание C не требуется. Обычно знание C требуется для работы с железом или с легаси кодом. Знание ассемблера требуется ещё реже.
Когда-то совместимость с C помогла популяризации C++. Сейчас это наследие тянет C++ вниз, мешает языку развиваться. Бьёрн Страуструп в своей книге The Design and Evolution of C++ написал: “Within C++, there is a much smaller and cleaner language struggling to get out.” Мне бы хотелось, чтобы это произошло. Но часть C++ комьюнити предпочитает оставаться в 90-х, как будто не замечая, что мир сильно изменился :(
Зато после полугода интенсивной практики программирования на чистых сях у студента не останется вопросов, зачем нужны шаблоны, RAII, исключения, корутины и модули, потому что он на своей шкуре прочувствует, какого без них.
Вот это отдельно прокомментирую)) Как появился котлин? На момент его создания некоторые вещи в java делались неудобно. Или отсутствовали. Котлин снял эту боль с разработчиков.
А теперь представим программиста, которому по работе нужно вкатиться в котлин. Или он его заинтересовал, и разработчик хочет сделать на нем пет-проект. Или хочет сменить стек. То есть мотивация вполне приземленная, практическая. Это не академик, который изучает ЯП и их историю и имеет в запасе сто лет.
Получается, этот разработчик, чтобы выучить котлин, вначале должен выучить старую java образца 2011 года? Пол года на ней интенсивно прогать, и только после этого позволить себе сесть-таки за котлин?
Получается, этот разработчик, чтобы выучить котлин, вначале должен выучить старую java образца 2011 года?
Возможно, это непопулярная точка зрения, но да, я считаю, что разработчик на котлине так или иначе будет вынужден знать «яву образца 2011 года». Ну просто потому, что жизнь такая. Знать только котлин получится лишь до тех пор, пока всё идёт хорошо. В какой-то момент что-то сломается, что-то начнёт тормозить, потребуется интеграция с какой-нибудь библиотекой, которая вроде как на яве, но, вообще говоря, обёртка вокруг нативного кода — и всё, теперь от разработчика требуется понимать все слои абстракции: и котлин, и яву, и си, и ассемблер.
@okhsunrogАпдейт! Этот код без изменений собирается связкой clang 19 + ninja + cmake 3.31.
mkdir build && cd build && cmake -Wno-dev -GNinja .. &&ninja
Вариант CMakeLists.txt можно посмотреть у нас в плэйграунде. Только вчера выкатили)
Дейтел есть для С++20 уже, более, чем тысячастраничный труд
Не рассматривали Julia? Мне кажется для научной деятельности самое подходящее.
У джулии есть приятные фишки (особенно в системе типов), но если начинать ее использовать там где раньше использовал numpy (многомерные массивы из коробки же!), то одна только индексация с 1 начинает очень бесить, ибо постоянно на этом подрываешься.
А в раст прекрасно завезен ndarray, после numpy заходит абсолютно без сюрпризов.
Пояса от Яндекса вам в помощь в плане структуры изложения
Пояса были отличными открытыми курсами. Их идея структуризации материала во многом совпадает с нашей. Но если сравнивать, то мы более хардкорные (но без фанатизма).
Например, в докладе про Пояса Илья Шишков сказал следующее: какой питонист будет проходить наш курс, если у нас словарь всплывает через 1.5 месяца?
С одной стороны, мы согласны, что чем раньше студент сможет решать на C++ практические задачи - тем лучше. С другой стороны, мы не будем делать все, лишь бы студент не соскочил. Например, мы считаем, что для нормальной разработки нужно знать, как вообще выглядит процесс сборки. Что есть препроцессор, что есть линкер. Поэтому глава про сборку проекта будет идти перед условной "главой про словарь". И мы готовы к тому, что часть народу это отпугнет.
Блин, я на этой наркоте с 2000 года, слова сборка всегда вызывает только одну ассоциацию БОЛЬ. Я кросплатформер и сделать новый пустой проект хотя бы под 4 основных айдэе и 3 платформы без проверенного шаблона это день работы и то если у вас есть доступ ко всем этим платформам и айдэе.
Вы конечно молодцы и все такое, но телега впереди лошади не поможет ехать лучше. Нет никакого смысла популяризировать курс по плюсам каким бы замечательным он ни был если тупо собрать пустой проект это реальная боль.
Какой смысл учит как работать с современным вектором/хэш мапом/флат мапом и не рассказывать про память если любая мутирующая операция инвалидирует чуть менее чем все в этом контейнере и уб делают все вне зависимости от опыта.
Ворнинги, статический анализ и линтеры звучит с галерок - ещё неделя их подключить и настроить, а потом бесконечно страдать от непрекращающихся фолс позитив и ладно хрен с ним если бы оно гарантированно ругалось на инвалидацию состояния контейнеров и прочих классов.
Юнит тесты, ага вот вам с десяток опций, но так что бы просто взять и подключить в проект без боли нету.
Модули - все ещё просто не работают. Подождем.
Корутины - ни в коем случае нельзя учить корутинам - они не предназначены для прямого использования, это фича языка исключительно для библиотеко писателей с серьезным опытом. А в самом стандарте кроме генераторов ничего и нету, нечем пользоваться, так что подождем ещё лят пять. Корутины это точно не то чему нужно учить в начальном курсе с++.
Рэейнджи - та часть что рабатает почти вся нахер не нужна, только сложнее код получается, есть где стало лучше конечно, а там где рэнджи полезны (обработка пары контейнеров) они ещё не работают. Подождем пару лет.
Раст так популярен не из за комьюнити, а имеет такое развитое комьюнити потому что избавляет от огромного количества боли. Сделать проект элементарно, подключить библиотеку очень просто, юнит тесты пожалуйста, линтер нет проблем, анализатор тоже. Проблем с инвалидацией стэйта у вас просто нет (ну если вы не спец и сами пишите свой класс/контейнер) - код не компилируется.
С++ не так сложно понять, как сделать работающий кроссплатформенный проект под несколько айдэе с юнит тестами линтерами анализаторами и сиай. Вот пока эта боль не решена никакие супер пупер классные курсы не помогут привлеч новых юзеров, слишком уж болючая первая доза получается.
Комьюнити у плюсов не менее развитое и куда более влиятельное чем у раста, но с++ получил ссаными тряпками от анб полностью за дело и комитет уже работает в правильном направлении. Без волшебного пендаля от АНБ до сих пор бы никто и не почухался.
Cmake чем не устроил? Большинство своих проектов через симейк собирал без каких либо проблем на win lin mac.
Спасибо за крик души развернутый комментарий)
слова сборка всегда вызывает только одну ассоциацию БОЛЬ.
А Cmake'ом какой версии пользуетесь? Есть так называемый Modern Cmake, и в нем собирать кроссплатформенные проекты, работать с зависимостями, со сложными иерархиямии директорий сильно, сильно легче.
Нет никакого смысла популяризировать курс по плюсам каким бы замечательным он ни был если тупо собрать пустой проект это реальная боль.
У C++ отсутствует стандартный сборщик, да. Но ставить из-за этого жирный крест на языке - слишком радикально) Боль при сборке - это проблема в первую очередь макроязыка CMake, а не C++. И как я писала выше, она должна быть облегчена начиная где-то с CMake 3.15.
Какой смысл учит как работать с современным вектором/хэш мапом/флат мапом и не рассказывать про память если любая мутирующая операция инвалидирует чуть менее чем все в этом контейнере
C++ - это торт-наполеон из абстракций. Не обязательно вдаваться в детали работы сырых указателей и адресной арифметики, чтобы объяснить абстракции итераторов, их инвалидирования и подкапотного устройства контейнеров. Про сырые указатели и все такое у нас тоже будет. Но не сразу.
бесконечно страдать от непрекращающихся фолс позитив
Опять же, ложные срабатывания линтеров - это не недостаток самого C++. Они меня доставали и в проектах на питоне.
Юнит тесты, ага вот вам с десяток опций, но так что бы просто взять и подключить в проект без боли нету.
В каких-то командах приветствуется использование системно установленных пакетов. Тогда просто инклюдится условный гугл тест, и вперед. В каких-то командах предпочитают втаскивать либу для тестов внутрь проекта. Если понимать, как работает CMake, то это тоже делается недолго.
Модули - все ещё просто не работают.
С некоторыми ограничениями они уже поддержаны. Вот только что на GCC сбилдила проект с использованием модуля print.
Корутины - ни в коем случае нельзя учить корутинам - они не предназначены для прямого использования, это фича языка исключительно для библиотеко писателей с серьезным опытом.
Чтобы использовать корутины, студент должен сначала понять, что это такое) Этот рассказ потянет на целую главу. После чего почему бы их не использовать в связке с 3rd party либой? Потому что вы абсолютно правы, в стандарте не корутины, а скорее фреймворк для их разработки)
Рэейнджи - та часть что рабатает почти вся нахер не нужна, только сложнее код получается,
Рейнджи позволяют выстраивать пайплайны обработки данных в функциональном стиле. Соответственно привносят в код плюсы функционального подхода. Но это вкусовщина)
а там где рэнджи полезны (обработка пары контейнеров) они ещё не работают.
А можно пример фичи рейнджей, которая вам кажется полезной, но которая еще не поддержана вендорами?
никакие супер пупер классные курсы не помогут привлеч новых юзеров, слишком уж болючая первая доза получается.
В том-то и фишка, что не обязательно все озвученное принимать первой дозой! Если хорошо продумать порядок тем для погружения в C++, у студента на старте не будет этого болевого шока)
с++ получил ссаными тряпками от анб полностью за дело и комитет уже работает в правильном направлении. Без волшебного пендаля от АНБ до сих пор бы никто и не почухался.
Техники для безопасной работы с памятью активно добавляются еще со времен C++11. Уже тогда в языке можно было пользоваться умными указателями и RAII. А АНБ смешал в одну кучу Си и C++, "не заметил" фичей Modern C++ и сделал вывод, что C++ пора отменять.
Я не пытаюсь вас отговаривать делать этот курс, вы все равно будете делать. Я выразил лишь одну из версий претендующую на объяснение фенонмена, когда вы курс сделаете, а особого толку не ощутите. Не ну кто то конечно скажет спасибо и даже заслужено, но проблемы найти курс по плюсам на английском в Ютубе или бесплатный курс по-моему не стоит сейчас.
Опять же вы делаете упор на самом свежем стандарте с++23, но он просто не работает в крос платформе. С++ 20 уже вполне сносно, с небольшими ограничениями нормально. С+17 де-факто тот самый стандарт где работает почти везде в практически полном объеме. Так вот 23 не будет актуален ещё года 3-4, а вот что вы будете делать со своим курсом когда выйдет с++26? Это реально революция в плюсах, там рефлексия, я на нем смогу написать практически свою версию плюсов, там вероятно будут экзекьюторы и может даже контракты. Но это все будет в очень светлом отдаленном лет на 10 будущем.
Если следовать вашей логике построения курса вам по факту придётся переписать структуру и вероятно много частей. По-моему в таком подходе что то не так если новый стандарт требует пересоздания курса.
Вы же сами делаете упор на практической части, а это значит что без подключения библиотек не обойтись, хоть какой симэйк используйте хоть послезавтряшний у половины либ вообще нет скрипта у другой половины он такой какой есть == радуйтесь что хоть что то есть. Так что бы просто подключил и оно просто работает не бывает никогда. Я к тому что учить плюсам и не учить симэйку это как учить использовать левую руку, но не учить пользоваться правой.
Вот опять же вы зачем разделяете с++, симэйк, библиотеки / экосистему друг от друга и говорите это все не проблема с++, а чья тогда? В расте это не разделяют и результаты на лицо. Почему у симэйка нет команды создать новый проект по всем бест гайдлайнам модерн пупер шмупер шаблонам вот там где мне надо. Что бы и гит репа и мэйн функция и юнит тест и сразу линтер закачать и стат анализ поставить и модули вместо инклудов и пакет менеджер и чтобы в каждой большой айдее этот проект открылся собрался запустился и на основных платформах билдился. Почему этого нету в плюсах, а в расте есть?
Вы же пишите что курс уже для программистов, а не полных нубов. Кокому программисту нужны голые знания плюсов без экосистемы? Что с ними делать?
Я кросплатформер и сделать новый пустой проект хотя бы под 4 основных айдэе и 3 платформы без проверенного шаблона это день работы и то если у вас есть доступ ко всем этим платформам и айдэе.
У Вас очень интересный кейс! Если не секрет зачем требуется поддержка 4 IDE? Вы пишите плагины для них? И какие целевые платформы используете?
Rust — хорош! Мне нравится :) Однако преимуществом C++ является широкий круг задач, который он решает: игры, бэкенд, работа с железом, десктопные приложения и другое. Мало какой язык может похвастаться таким широким обхватом. (Только C может.) Но не бывает достоинств без недостатков, широкий круг задач делает сложным создание универсального инструмента управления проектами.
Rust пытается заходить во все эти ниши, но, AFAIK, сколько-нибудь заметное распространение получил пока только в бэкенд разработке. Вот Ваши задачи можно решать с помощью Rust'а? Не в теории, а на практике? Есть ли необходимые крейты? Наладить инфраструктуру точно будет проще?
Rust — хорош! Мне нравится :) Однако преимуществом C++ является широкий круг задач, который он решает: игры, бэкенд, работа с железом, десктопные приложения и другое. Мало какой язык может похвастаться таким широким обхватом. (Только C может.) Но не бывает достоинств без недостатков, широкий круг задач делает сложным создание универсального инструмента управления проектами.
Широкий круг задач тянет за собой кроссплатформенность, удобные системы сборки и прочий тулинг. С этим на С++ настолько плохо, что на Linux, Windows и Android он отдает свои позиции любым языкам с виртуальной машиной и сборкой мусора.
Остается достаточно узкий круг задач, в которых нужно максимальное быстродействие или близость к железу: игры, HighLoad, embedded.
Rust пытается заходить во все эти ниши, но, AFAIK, сколько-нибудь заметное распространение получил пока только в бэкенд разработке. Вот Ваши задачи можно решать с помощью Rust'а? Не в теории, а на практике? Есть ли необходимые крейты? Наладить инфраструктуру точно будет проще?
Любой язык пытается заходить во все ниши. Например Javascript вышел из браузеров и потеснил Python в разработке оконных приложений. Не вижу в этом ничего плохого.
Rust тоже смог занять некоторые ниши, процитирую:
Очень многие начали. Cloudflare целиком на Rust переписались, в исходниках Android его уже столько же, сколько C, AWS несколько сервисов целиком переписали и не останавливаются (и сделали Firecracker целиком на нем, опенсорс менеджер микровиртуалок, на котором работают Lambda и Fargate), с голенга многие тоже переписываются. Я могу дать полный список известных мне проектов, там от MESA до Figma, Vercel и части бэка npm.js репозитория. И под спутники пишут на нем, и новые проекты от мала до велика (от Tauri, который по сути Electron здорового человека, и Embassy, который embedded просто и быстро, до Western Digital, которые платформу обработки данных на 5 петабайт в день на нем пилят).
В микроконтроллерах, например, количество новых проектов на С++ стремится к 0, Rust уже соотносится с С примерно 30/70%. Сейчас ситуация такова, что найти библиотеку для датчика на Rust проще чем на С (это к вопросу о количестве крейтов).
В других же нишах, например десктопные приложения, Rust вероятно никогда не будет распространен.
Если не секрет зачем требуется поддержка 4 IDE?
Нет, не плагины. На самом деле я бы сказал это дефолтный случай для кроссплатформы. Почему? Ну потому что крос айдее есть, но так что бы быть стандартом на плюсах таких нет, поэтому каждый член команды выбирает что ему нравится. У нас используется:
Студия
Х[рень]Код
Вс[е_подряд_но_так_себе]Код
МорскойКотик
КультяКреатор
И ещё небось то о чем я даже не подозреваю
Периодически то там то сям всплывают проблемы и у нас симэйк имеет айдэе специфичные вставки. Мы билдимся под винду, мак, десктоп и эмбед линукс, раньше ещё и иос был - не пригодился. Компилим 3 компиляторами (шланг, гцц, мсвц) под 3 платформы х64, арм32, кремневое яблоко. Недавно переехали на ц++20, вот как раз половины рэйнджей нет, стд формат нет. Наверное ещё чего то нет, но я не знаю. Причина проста, мы должны поддерживать не самые свежие яблоки (ограничение по рантайму/стд либа) и эмбед где компилятор обновляется не так чтобы часто. Поэтому используется нод от всех платформ/компиляторов т.е. только то что работает везде.
Софт енджин диджей от инмьюзика. Думаю в России вообще не известен, хотя я не диджей понятие не имею чем они в России пользуются.
Спасибо за подробный ответ! Но один момент непонятен. Следующая практика мне казалась общепринятой: разработчик волен выбирать подходящую ему IDE/редактор (VSCode, Vim, CLion, Sublime, QtCreator, Emacs, Eclipse и т.д.), но настройка любимого IDE дело рук самого разработчика. Если нужно поправить cmake, чтобы любимая IDE работала корректно, то делаешь пул реквест с нужными изменениями. А после ревью и апрува мержишь в мастер/рабочую ветку. У Вас не так? Есть какой-то один человек, который занимается поддержкой кучи IDE?
P.S. С std::format у меня однажды подгорело. Обрадовался, что планируют затащить std::format в стандартную библиотеку C++20. До этого где можно использовал fmtlib. Но чаще убедить коллег перейти на fmtlib не удавалось и приходилось использовать велосипеды разной степени убогости. А тут стандартная реализация fmtlib "из коробки". Красота! Настал час X, обновили gcc и clang до 20-х плюсов (типа), ни один std::format не поддерживает. Через некоторое время обновили снова: в gcc появилась неполная поддержка, в clang — по-прежнему никакой. Да, елки-палки... Ах, да, в Rust format!() есть с релиза 1-ой версии.
Есть какой-то один человек, который занимается поддержкой кучи IDE?
Присоединяюсь к вопросу.
Если нужно поправить cmake, чтобы любимая IDE работала корректно, то делаешь пул реквест с нужными изменениями.
В проектах, над которыми я работала и в которых IDE у контрибьютеров отличались, был третий вариант: IDE-специфичные настройки не должны попадать в общий репозиторий. Поэтому каждый разработчик заносил такие файлы в .gitignore. И если требовалось допиливание CMakeLists.txt, подкручивал свое окружение так, чтобы подключать кастомный CMakeLists.txt и довносить в него изменения, если меняется CMakeLists.txt в репе.
Есть какой-то один человек, который занимается поддержкой кучи IDE?
Нет, такого человека нет. Распознать айдее в симэйке строго говоря низя, можно только генератор как самое лучшее приблежение, поэтому костыли с предположениями что вот такое сочетание параметров значит вот эта айдее. Ну и поломать кому то что не так что бы сложно, однако такое редко бывает.
Симэйк он про сборку, а не про айдее, но т.к. в плюсах нету понятий из реального мира таких как исходный файл, проект, сборка, то и нет стандарта на метоиформацию, симэйк как бы кандидат, но нет у него свои задачи.
Как человек, оказавшийся после курса С++ (неоконченного) не в девелоперской команде, а в больничке под капельницей, у меня к вам не столько просьба, сколько мольба : делайте побольше картинок с визуализацией всего того что вы рассказываете, пожалуйста.
Схемы, графики, стрелочки, блоки, диаграммы, все современные инструменты что дают нам компуктеры с цветными мониторами высокого разрешения, которые позволяют нам воспринимать информацию самым эффективным способом - глазами.
Почти все игнорируют этот метод. Надеюсь на вас
Яндекс, верните деньги если не за курс, то хотя бы за лекарства XD
Мы любим картинки. В курсе по питону мы ими немного пренебрегли, но в курсе по C++ развернемся на полную.
Расскажи, пожалуйста, что в том курсе было сделано неудачно? Мы коллекционируем грабли (и чужие, и свои), чтобы на них не наступать.
КМК, основное - мало теории, которая при этом ещё и подавалась скомканно и неструктурированно.
В одном уроке было сразу 3-5 тем, по которым потом пара-тройка больших практических заданий.
Лично мне, удобнее всего учиться мелкими кусочками : один маленький, но целостный кусочек теории, и к нему несколько мелких практических заданий для понимания и закрепления, и можно ещё немного на всякие нюансы.
Естественно, кусочек практики на интеграцию в имеющиеся знания.
Для меня идеалом в этом плане был учебник математики Мордковича, там всё было построено именно на этой схеме, и она мне давалась просто на ура.
Поэтому я и недоумевал, как мне, человеку, вроде как технарю, с умением в математику и вот это вот всё, так тяжко давалась довольно простая, с точки зрения логики, дисциплина как программирование.
Я не великий преподаватель, но мне кажется, будет хорошей практикой сначала ставить простую задачу, решить её максимально топорным кодом "в лоб", после чего, потихонечку заменять топорные конструкции более красивыми.
Типа, сначала вся программа одним большим полотном, пусть даже с повторениями, потом вводим понятие функции, и подменяем повторяющиеся куски, потом классы, отдельные файлы, заголовочники итд итп.
То есть сначала мы ставим понятную для данного уровня ученика задачу,
и пусть ученик решит её теми методами, с которыми он уже знаком.
Затем мы знакомим ученика с новым методом и показываем, как он вписывается в эту же задачу.
Я часто вижу, что много проблем у учеников вызывает концепция указателей.
По моему мнению, это потому что, чаще всего, программирование изучается в отрыве от "железа", что в случае с С++ вообще недопустимо. Понятное дело, что не надо забивать студентам голову схемой работы процессора с регистрами и дешифраторами команд, но, как минимум, они должны понимать, как устроена память и как в ней хранятся данные : переменные, массивы, строки.
Рассказать, что тип переменной интерпретируется как занимаемый ей в памяти объём и, в последующем, алгоритм работы с хранящимися данными, (Типа, что uint8_t и char места в памяти занимают одинаково, но компилятором воспринимаются по-разному), а её имя - это просто понятное человеку слово, которое компилятор преобразует в адрес в ОЗУ (кстати, про ОЗУ ребятам тоже бы рассказать в общих чертах).
Тогда ученики гораздо легче поймут разницу между int var и int* var и для них это уже не будет непонятной абстракцией, а вполне очевидной структурой.
И в последствии им уже будет сильно проще объяснить про массивы, что имя массива - это адрес первого элемента, а int arr[i] это всего лишь прибавить к адресу arr int размер i раз.
Не знаю как у всех, но лично у меня осознание понимания как работает та или иная штука вызывает острый приступ эйфории, а это неплохой буст к дальнейшей мотивации.
Как человек, оказавшийся после курса С++ (неоконченного) не в девелоперской команде, а в больничке под капельницей,
Причина прям сам курс?
ну, естественно, это шутка, курс прошли несколько тыщ человек, а перегорел я один.
скорее совокупность факторов : и сам курс трудноват для перевариваривания человеком моего уровня и моих возможностей, я не привык адово трайхардить и монотонно корпеть ;
я в принципе никогда не умел учиться "с наскока", в двух ВУЗах пытался учиться, в обоих потерпел полное фиаско, ибо вообще не понимал чо и как делать ;
плюс неправильная постановка изначальной задачи : неверно поставленная цель, невнятная мотивация.
Но основное : я не понимал что именно мне надо сделать, кураторы в чатиках давали только подсказки и намёки (что, в принципе и верно), да и то с задержкой в полсуток, что сбивало темп и выдирало из "потока" , на построение картины в голове уходило очень много энергии, которой со временем становилось всё меньше и через полгода я уже выезжал на "волевых", чем себя ушатал.
В итоге бросил.
Через некоторое время устроился на работу, где надо было кое-что подучить, из того что я уже знал, но там система обучения была выстроена настолько криво, что я добил себя окончательно, уволился и полгода восстанавливал кукуху таблетками и капельницами для инсультников и антидепрессантами.
Ясное дело, курсы не виноваты, просто наложились друг на друга разные переменные.
Вы используете gcc в качестве основного компилятора. При этом большинство потенциальных обучающихся сидят на Windows, для которого c gcc существуют два варианта: кривой mingw и сложные виртуализованные WSL / Linux on HyperV/VirtualBox/VmWare. Планируется ли дополнительный материал для подготовки к этим сложностям?
Вообще, если учить современный C++, то программы должны компилироваться любым современным компилятором. Есть, конечно, специфические вещи, завязанные на платформу, но это явно не для учебных целей.
По статистике от jetbrains, на GCC 65% разработчиков, на MSVC - 31%. Понятно, что статистика перекошенная. Она показывает разброс среди пользователей продуктов jetbrains, а не по индустрии в целом. Но хоть что-то.
Среди моих знакомых и коллег на домашних и рабочих компах преобладает Линукс. Но это еще менее репрезентативная выборка)
Вот прямо особенности GCC будут всплывать буквально в паре глав. Чтобы воспроизвести эксперименты под виндой, достаточно будет запустить контейнер с GCC.
Так что пока мы в этом особых сложностей не видим.
Чтобы воспроизвести эксперименты под виндой, достаточно будет запустить /контейнер с GCC.
Можно поставить WSL2, накатить на него Ubuntu и запускать код прямо из MS Visual Studio. Для человека незнакомого с Linux, это наиболее безболезненный способ. ИМХО.
Используйте clang, который работает везде
Мы выбирали между clang и gcc. Нас остановило то, что на данный момент в clang поддержано чуть меньше фичей из последних стандартов.
Потихоньку изучать ВинАпи - докумнтация есть на их сайте, на вин апи можно настроить окно, если мы говорим о играх, но да попробовать позапускать много придётся если в лоб идти от того что вы написали
20 лет назад это утверждение было бы верным. Но за это время Windows сильно сдала позиции в нашей стране. Плюс текущая ситуация не располагает к распостранению Windows и решений от MS.
Как раз недавно поменял работу, активно смотрел вакансии C++ разработчика. По субъективным ощущениям вакансий Linux + кроссплатформа (Linux/Windows/macOS) больше чем просто Windows.
Мой вопрос был, очевидно, не про действующих C++ разработчиков и вакансии для них, а именно про тех, кто в начале пути. И судя по вопросам, например, в ТГ канале https://t.me/supapro, проблемы с настройкой среды под Windows более чем актуальны, в том числе, например, для студентов, которых преподаватели уже учат на gcc, а у них Windows, где MSVS со своей неконформной реализацией плюсов обгоняет все альтернативы по быстроте старта на ней.
Чтобы установить WSL с дефолтной убунтой на борту нужно в PowerShell вставить строчку wsl --install и нажать Entrer. Затем вроде имя пользователя и пароль придумать нужно. Либо воспользоваться способом через гуй - это не сложнее, чем поменять обои на рабочем столе или установить какую-нибудь программу. В интернете полно видео/статей по теме.
Если человек не может это сделать даже по видео-туториалу, то рановато ему садиться за изучение C++ наверное.
А что кривого в MinGW? По мне так это единственный способ что-то кроссплатформенное пилить.
еще надо уметь писать библиотеки на С и уметь добавлять их в свою инфраструктуру проекта)
Не-не-не, так и до ассемблерных вставок пол шашечки))
я написал блок математики на С, в планах переписать вызов окна на С ограничив библиотеку самым необходимым для вызовов окна, на линукс с кастомным вызовом по моему тесту я выигрываю 30фпс, но есть например СДЛ да частично соглашусь, но сдл далеко уже расширяется от просто вызова окна, теряем андроид(думаю можно будет почитать как это делать, и придётся вызовы писать и под винапи , но разница существенная, да и порт 3д игры можно оставить на ВинАпи и Линукс в случае чего), вообще конечно в целом согласен с вами, это дебри просто
извините хочу добавить если организация данных - чанкование и математическая игра аля Кубики - воксели , взять например алгоритмы по организации работы с производительностью кубиков на С прирост тоже ощутимый. но код конечно по-сложнее чем на С++
Просто читать про язык = тратить время.Учить язык = писать код.
Может == или перегружен оператор присваивания?
Отнеситесь как к шутке.
Наша цель – чтобы после прохождения курса разработчик мог:
Это конечно благородная цель, но явно не в том исполнении, что представлен у вас на сайте. У вас в лучшем случае синтаксис разобран. Ни про модель памяти, ни про системы сборки ни в одном не увидел. А в случае С++ это одна из наибольших болевых точек, в том числе и с точки зрения безопасности. Пока что в лучшем случае оно выглядит как некоторый rustlings, но явно недостаточно, чтобы решать задачи полноценно задачи. Да чел сможет написать сортировку, но как написать какой-нибудь микросервис при помощи всего этого вопрос останется открытым. Есть неплохая книга "From Zero to Production" про это на Rust, где выстраивается пайплайн на примере сервиса рассылки мыла и пока для других языков я аналогов не встречал. Если на питоне-хаскеле-го с их стандартной библиотекой такое относительно просто провернуть, то в С++ тут уже надо добавлять curl в зависимости, подключать boost.asio. В главе про сборку про это в принципе не упомянуто как впрочем и про менеджеры пакетов/зависимостей а ля conan, chocolatey/scoop/winget/nuget и прочих.
Отдельно стоит заметить про разницу сборки под разными OS.
но явно не в том исполнении, что представлен у вас на сайте.
У нас на сайте сейчас нет курса по C++. О каком именно исполнении вы говорите?
Ни про модель памяти, ни про системы сборки ни в одном не увидел.
А где вы смотрите? Мы устаканиваем оглавление курса. Там обе темы есть.
Если на питоне-хаскеле-го с их стандартной библиотекой такое относительно просто провернуть, то в С++ тут уже надо добавлять curl в зависимости, подключать boost.asio.
Можно подключить в зависимости условный restinio, и запилить микросервис будет не сложнее, чем на го.
В главе про сборку про это в принципе не упомянуто как впрочем и про менеджеры пакетов/зависимостей а ля conan, chocolatey/scoop/winget/nuget и прочих.
В главе про сборку есть блок про пакетные менеджены. В частности, про conan. Какой процент разработчиков использует chocolatey/scoop/winget/nuget? Кажется, что исчезающе маленький. Если мы будем в курсе по языку C++ уделять много внимания инфраструктурным нишевым тулзам, то курс станет огромным.
Отдельно стоит заметить про разницу сборки под разными OS.
Плюс CMake в том, что он кроссплатформенный. С ним относительно легко добиться кроссплатформенной сборки. Или вы имеете ввиду что-то другое?
У нас на сайте сейчас нет курса по C++.
Да там и по тому же расту информации меньше чем в кукбуке, который в том числе и на русский перевели. Аналогично другие языки, за исключением хаскела.
Кажется, что исчезающе маленький
Ключевое слово - кажется. Либо вы считаете, что программисты под Win не нужны. Сборка и её время - одна из болевых точек при работе с языком, вносимое в том числе и платформами.
Плюс CMake в том, что он кроссплатформенный.
Собственно управление зависимостями и разница компиляторных флагов. Если на каком-нибудь linux find_package заведётся из коробки, то на win надо будет дошаманивать.
Да там и по тому же расту информации меньше чем в кукбуке
Сравнивать кукбук (набор примеров кода) и учебник нельзя. У них разная цель. Если имеется в виду растбук, то он завершен, а наш курс в процессе написания. Но раз уж на то пошло, давайте сравним степень погружения в каждую тему. В растбуке вещественным числам посвящено полтора абзаца с простейшим примером кода в стиле let x = 2.0; // f64.
У нас про числа с плавающей точкой отдельная глава. Потому что это тема, на которой многие спотыкаются. В главе разобрано, как floating point хранятся в памяти, как их сравнивать, какие есть нюансы работы с ними, нечисловые значения констант, методы f32 и f64и далее по списку.
Ключевое слово - кажется. Либо вы считаете, что программисты под Win не нужны.
Ну, скажем так, мое "кажется" подкреплено хоть какой-то статистикой. Если вы ей не доверяете, приведите свою. Или организуйте опрос на хабре и мы посмотрим на результаты. Это интересно.
Сборка и её время - одна из болевых точек при работе с языком, вносимое в том числе и платформами
В курсе по язык C++ рассказывать про нюансы работы с разными пакетными менеджерами под разными платформами = комбинаторный взрыв и неблагодарное дело. Один только CMake тянет на полноценный курс. Вы не согласны?
Самое сложное в C++ - это непосредственно C++. А не Conan. И не настройка плагина для VSCode. В первой главе и в главе про сборку мы накидываем баззворды: названия тулчейнов, систем сборки, автоматизации сборки. У каждого из них есть актуальные мануалы. Если со всем этим багажом студент курса не осилит на своей ОС настроить сборку, то... про это @Serpentine хорошо откомментил)
Чтобы что то освоить, нужно это выстрадать, для того чтобы усвоить.
Даже в книге по C++ Bjarn обозначил, что для того чтобы научиться ходить, для начала нужно научиться бегать.
Конечно есть своя аудитория людей для кого интерактивные элементы с геймефикацией (типо совы из doulingo) будет более понятна, но что будет после прохождения курса, тогда когда совы не будет?
Вообще никогда не понимал для чего заниматься такими науками если тебе сложно освоить базовые понятия типа pointer в C++ или тебя тошнит от математики и цифр или ты не можешь просто найти документацию и прочитать самостоятельно, задавать вопросы, найти ответы и так далее. Так мы и учимся.
Если сидеть с разжованной ложкой где все доступно на подносе - ты только бери, то если чуть плеснуть масла в огонь и все посыпется. На выходе получаем слабака.
Как дальше специалист выращенный на интерактивном дизайне планирует что-либо производить и решать какие либо нетривиальные серьезные проблемы. Да это требует 10 жизней, и да это сложно. Если тебе нравится то зачем считать сколько на это уйдет времени?
Мне кажется что в глубине засела какая то нездоровая идейность, что если я выучу язык и устроюсь на работу, мне будут платить очень много денег и я куплю себе все что захочу - и я счастлив и в безопасности.
Спешу сообщить, счастья это не принесет. Можете верить можете нет, дело ваше.
Я думаю что нужно не упрощать а усложнять, но при этом давать понимание как работает компьютер, память, процессор, и так далее по списку. На выходе мы должны получить человека который видит картину а не кусочек пазла и все это в привычном виде, без облегчающего до уровня copy-paste дизайна.
Так или иначе
Дело вы конечно делаете хорошее, по душе, и возможно с доброй волей, я вас понимаю и поддерживаю, но есть вопрос
а надо ли это?
TLDR; У нас ровно такие же взгляды на процесс обучения. И ничего из сказанного вами не противоречит нашему подходу к подготовке курса.
В этой статье мы ни разу не упомянули геймификацию, разжевывание материала, переупрощение и избегание сложных тем! Кажется, словосочетание "онлайн-курс" уже настолько дискредитировано и опошлено, что эти практики дефолтно приписываются любым интерактивным материалам.
Теперь по пунктам.
если тебе сложно освоить базовые понятия типа pointer в C++
Вы можете заглянуть в оглавление, которое мы сейчас обсуждаем. Вы убедитесь, что в курсе будут и указатели, и адресная арифметика, остальные обязательные атрибуты C++) Мы всего лишь хотим сказать, что начинать изучение современного C++ с них - это устаревший подход. Можно сделать лучше.
или ты не можешь просто найти документацию и прочитать самостоятельно, задавать вопросы, найти ответы и так далее.
В курсе будут практические проекты. У нас задумка реализовать их таким образом, чтобы отпускать пользователя в самостоятельное плавание по cppreference.
Если сидеть с разжованной ложкой где все доступно на подносе - ты только бери, то если чуть плеснуть масла в огонь и все посыпется. На выходе получаем слабака.
У нас есть готовый курс по питону. Мы получили на него много положительных отзывов. Пользователи рассказывали, как после курса успешно устраивались на новую работу со сменой стека (middle+). Так вот. По нашей статистике вайтишники срезались на первых же главах. Поэтому нет, на выходе мы не получаем слабака. Он срезается гораздо раньше. В курсе по C++, я так полагаю, он будет срезан на первых же абзацах первой главы)
Мне кажется что в глубине засела какая то нездоровая идейность, что если я выучу язык и устроюсь на работу, мне будут платить очень много денег
Самое важное: наши курсы - не для вайтишников. Наши курсы - для разработчиков, которые учат данный конкретный язык с нуля.
И я не вижу ничего плохого в том, чтобы учить язык с комфортом. Мы живем в 21 веке! Мы можем позволить себе учиться эффективно! Выполнять проекты и отправлять их на проверку юнит-тестам и статическим анализаторам. А не выполнять задачки из pdf-книжки и уповать, что все сделал правильно без проверки третьей стороной.
Тот интерактив, который предлагаем мы, наоборот позволяет избавиться от иллюзии получения знаний. Ну прочитал ты главу книги Страуструпа. А как ты поймешь, что все запомнил? Что понял все правильно, нигде не осталось белых пятен? Тут как-раз таки помогает интерактив. То есть написание кода, хорошо покрывающего только что прочитанную теорию. И тщательная проверка того, что ты сделал. А не сова из дуалингво)
Я думаю что нужно не упрощать а усложнять, но при этом давать понимание как работает компьютер, память, процессор, и так далее по списку. На выходе мы должны получить человека который видит картину а не кусочек пазла и все это в привычном виде, без облегчающего до уровня copy-paste дизайна.
Мы стараемся составить курс так, чтобы сложилась цельная картина мира C++. А не мозаичная. И там, где будут требоваться низкоуровневые детали - мы их дадим.
Вообще вы в целом правы, я подошел к вам с насторожкой, поскольку увидел у вас интерактив, курсы и прочие ключевые слова которые обычно ведут в вайтишку
Согласен, что знания нужно закреплять, pdf файл не лучшее решение — тоже согласен, но у того же Stroustrap в конце каждой главы есть drill, review и exercices - и каждый блок решает проблему с усваиванием информации, поэтому и тут белые пятна закрываются.
Так или иначе
Дай бог чтобы у вас всё получилось, буду ждать, думаю будет на что поглядеть
Дело конечно хорошее.... (С++17 конечно уже недостаточен, к примеру, нет корутин)
Но как это делать правильно....? Кто-то говорит, что не нужно подрбностей из языка C, иначе не напишешь приемлемый код
Спасибо огромное за ваш труд!
Постараюсь помочь, чем смогу!
На мой взгляд, у вашей статьи (не курса) есть один недостаток - не указано явно, к какой категории должен относиться учащийся, чтобы начать проходить курс. Это помогло бы избавиться от части комментариев с критикой курса, где указывают, с чего следует начинать.
Вы только вскользь указали "Это площадка с курсами от программистов для программистов", но дальше называете их "студентами" (что ассоциируется больше с первокурсниками, которые могут вообще ничего не знать).
Думаю, стоило бы развернуть этот момент и подробнее остановиться на начальном уровне курсанта, как это обычно указывают во введении/предисловии к хорошим книгам.
Возьмем, например, K&R - там в предисловии явно указано:
Цитата
Эта книга не представляет собой элементарное введение в программирование. Предполагается, что читатель знаком с основными понятиями программирования — такими как переменные, операторы присваивания, циклы и функции. Тем не менее даже начинающий программист скорее всего окажется в состоянии читать примеры и извлекать из них уроки языка, хотя помощь более знающего коллеги будет не лишней.
Благодаря этому я, будучи просто продвинутым пользователем ПК, не стал начинать знакомство с Си с этой замечательной книги и перешел к её чтению уже после предварительной подготовки.
Ваш комментарий подтолкнул меня к мысли, что придется проговорить в первой же главе, кто наша целевая аудитория. Примерно как в вашей цитате. Потому что в этом посте мы дважды говорили про ЦА. В первых строках и в пункте про то, каким должен быть курс:
Целевая аудитория курса — программисты. От студентов до синьоров с десятками лет опыта в других языках. Для них не придется раздувать текст объяснениями, что такое функции, массивы, переменные. К тому же, если вы никогда не программировали, начинать с C++ не стоит.
А студентами мы называем наших пользователей, потому что "пользователи курса" звучит как-то странно)
Извините, но не смог не вспомнить и не поделиться этим мемом.
Инициатива отличная, ещё лучше было бы начать с С++20, который уже везде отлично поддерживается. Мы в Organic Maps прошли все стадии переходов, сначала на С++11, потом 14, 17, и недавно на 20, и хорошо прочувствовали все "плюсы" )
Делаем опенсорс курс C++ 17+. Присоединяйтесь