Pull to refresh

Comments 30

окончательно закрепляют в сознании правильную структуру приложения и файлов

если с приложением более-менее понятно, то про файлы не понятно совсем. Где про это можно хоть в каком-то виде почитать? Максимум, что в этом случае всплывает в памяти — разброс на include и src для библиотек.

Не уверен, что Visual Studio — это подходящая среда для обучения структуризации исходных текстов. Например, после работы с ОС Linux структурирование файлов в пакетах NuGet у меня вызывает жуткое отвращение.

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

Из вариантов можно устроиться на работу туда, где есть большие сложные проекты, желательно молодые и быстро развивающиеся, поскольку, главное — не попасть на legacy-проект.

А по поводу маленьких проектов, — структурирование каталогов в основном зависит от языка программирования и будет отличаться от языка к языку.
Собственно я о том же. Тут даже разные проекты с одинаковыми языками и системами сборки разный лейаут используют, о какой правильности речь в статье идет мне совершенно непонятно. Оно практически целиком и полностью зависит от использующей системы: nuget, launchpad/ppa, luarocks, chrome extensions или ещё какие — все имеют определенные ограничения на структуру, но никто не может быть «правильным». Поэтому и задал автору вопрос в тему. Мало ли я чего мог упустить.
Мне кажется хороший и небанальный подход к обучению с++ изложен в курсах серии «Основы разработки на С++: Белый пояс» на курсере, а здесь перечисление банальностей вперемешку со вредностями.
И зачем в курсе о С++ блок-схемы, паскаль и бейсик?

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

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

Также ООП является ключевой разницей между C и C++

А это вообще неправда.
Сложно представить более вредный подход, чем заучивать код и переписывать его в новом синтаксисе. Или чем учить С++ начиная с Си.
Мне всегда казалось, что это единственный правильный путь. В C++ не принято открыто работать с сырыми указателями, «вручную» управлять памятью и еще много всего, но оно есть под капотом в STL и всех остальных библиотеках. Должен же человек понимать как написать свой аллокатор.
Должен же человек понимать как написать свой аллокатор.

Может программист уровня мидла или крепкого джуна и должен, но вот новичек в С++ — вряд ли.
в этом плане современные плюсы — палка о двух концах: их изучение можно начать и с ооп, и с жонглирования битами/байтами/адресами. Лично мне подход «давайте сделаем вот это просто а потом я вам объясню как это работает внутри» кажется весьма логичным.
Из этого можно целых несколько уроков состряпать после — рефакторинг, оптимизация и всякий байтовый тюнинг, а там уже и детальная организация памяти, выравнивание и нюансы компилятора и заверте…
Всегда начинают обучение с «делай как я» и потом разбирают что происходит. Наглядные примеры лучше доходят чем до неокрепшего мозга чем абстрактные конструкции и слова которые они впервые слышат и им их еще надо с чем-то ассоциировать. Так что лучше обучать на простых задачах постепенно показывая функционал C++ способный упростить их решение. Лучше что бы задачи опирались на то с чем студенты часто имеют дело. Но без абстракций тоже далеко не уехать. Да и начинать с ооп тоже надо предварительно объяснив зачем оно появилось и что это не панацея.
Скорость и объём новых знаний которые пытаются засунуть за ограниченное время упираются в ограничения мозга и тех знаний и ассоциаций которые уже есть у студента.

Еще меня всегда удивляло что в курсах, что в книгах никто не освещает вопрос как организовывать код, когда его реально много, и куча внешних зависимостей. Что бы в нём быстро ориентироваться, не переусложняя структуру при этом работать с кодом не увеличивая сложность. Одно дело когда у вас изделие из 100 деталей и другое дело когда из 100тыс деталей, которые еще и меняются со временем и работают не совсем так как задумывалось.
Кстати, а есть годные источники где аспект организации когда нормально объясняют? Потому что тоже столкнуляся с такой проблемой. А еще было бы интересно про покадровое исполнение кода (с заданой переодичностью как в микроконтроллерах).
Скорость и объём новых знаний которые пытаются засунуть за ограниченное время упираются в ограничения мозга и тех знаний и ассоциаций которые уже есть у студента.

когда курс интересный, студенты запихивают себе в голову в три раза больше этих «ограничений мозга»

Еще меня всегда удивляло что в курсах, что в книгах никто не освещает вопрос как организовывать код, когда его реально много, и куча внешних зависимостей

у меня товарищей учили так: в течение семестра проект по ООП в несколько этапов, после каждого этапа кодобазы случайно перемешиваются между студентами. В итоге такие вещи как простота и расширяемость кода, личная ответственность за него, как читать чужой код, что и почему делать не стоит — всему этому они научились в рамках курса на собственном примере.
UFO just landed and posted this here

Я прошёл схему Pascal -> C -> WinApi (имхо, паскаль лишний в этой цепочке, но он был полезен более слабым ученикам). Плюсы изучал самостоятельно и первые года 2-3 реальной работы писал на си с классами, пока не познакомился с Qt. Не могу сказать, что это было плохо, но и не сказать что было хорошо. Минусы в таком подходе очевидны — мне было очень сложно приучиться к ООП мышлению и было сложно понять назначение паттернов проектирования. Много времени я был где-то между сильным джуном и слабым мидлом.
Считаю, что в этой цепочке просто не хватило следующего звена — а именно хорошего жёсткого курса по ООП с изобилием практики. Да, в универе у нас читали ООП (на примере консольных приложений в Делфи, никаких формочек) и читали хорошо. Но на лабах это не закреплялось. К тому же на тот момент я уже работал и мне было не до универа.

а здесь перечисление банальностей вперемешку со вредностями.
И зачем в курсе о С++ блок-схемы, паскаль и бейсик?
На счет паскаля и бейсика согласен — это смешно и грустно одновременно. Один мой знакомый недавно пошел на курсы по вэбу, говорит, крутые, хорошую сумму отстегнул. Я говорю — красавец! И что вы там учите? А он — ну вот флэш начали… Дело в том, что всегда есть фактор выпавшего из струи преподователя, как правило, предпенсионного возраста, который всю жизнь пользовался тем, что уже нахер никому не надо, но что он знает досконально, а новое уже не тянет. Ну и впихивает это наивным нюбасам под тем или иным соусом. В ИТ сейчас реально столько технологий, которые маст кноу, что забирать у людей драгоценное время, забивая их головы непотребом — это просто, чисто по человечески, некрасиво.
Захотите работать в гейм-дизайне — путь лежит в Unity и схожие программы.
Вот я, например, к своему стыду, только сейчас узнал, что С++ каким-то боком имеет отношение к Unity. Иди ты?! А в википедии написано, что только C#, JavaScript и раньше Boo.
Из статьи выходит, что C++ — это страшный монстр, к которому надо подступаться в несколько подходов. Но это же неправда. Начать с примитивов, затем наращивать «жирок» поэтапно — очевидный и простой подход. Во всяком случае не будет вызывать дрожи в коленях, когда человек приступит к написанию первых строк кода.
Так и подмывает меня скинуть ссылку на видео Kate Gregory «stop teaching C» в таких случаях)

Шутки шутками, но я встречал людей со страхом писать код практически на уровне фобии. И это был Python, а с С++ и я иногда фигею...

Помню на первой работе когда только начинал общаться с C++ одним из первых заданий было написать поиск пути для каких-то тараканов в TD. И вот в слух прогавариваю, что нужно «из данной клетки пустить в сторону цели прямую и когда найдешь стену, то пустить волну», а на деле сделать так и не смог. Мялся на выборе контейнеров, попытках придумать как вообще пускать волну, что есть волна и как потом еще из этого и путь собрать. Потому что не было никого, кто мог бы пояснить КАК надо думать при этом. Соотвественно возникала и «фобия» написания кода.
Этап 4. Начинаем с консолей

Согласен, программирование для XBOX и Playstation — это настолько важная ниша для C++, что можно к ней примериваться в самом начале обучения.
В любом языке программирования надо начинать писать программы не в сложных IDE, а в простых универсальных редакторах. Notepad++

Угу — а потом при запуске вчитываться в номера строк с ошибками в консоли и искать соответствующие участки кода в блокноте.
В свое время турбо-паскаль стал популярным в то-числе из-за удобной IDE.

Там опечатка в статье, прямо в заголовке! Должно быть: "Краткий гид по обучению С++: что, когда и на чём НЕ создавать"

Как-то однобоко звучит, мне кажется, так разработчиком на C++ не станешь(
Я бы на самом деле задумался, так ли нужно становиться C++ разработчиком ;)
Вы об этом лет 20 назад тоже задумались бы?
Ну так вроде и на дворе немножко не 98-й.
> К примеру, в школах и ВУЗах на изучение С++ уходит минимум 2 года, чаще 4-5.

Я наверное отстал от жизни, но разве в ВУЗах тем более школах «учат C++»?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here

Очень странно предлагать пользоваться линуксом и notepad++ вместе

Sign up to leave a comment.