Comments 30
окончательно закрепляют в сознании правильную структуру приложения и файлов
если с приложением более-менее понятно, то про файлы не понятно совсем. Где про это можно хоть в каком-то виде почитать? Максимум, что в этом случае всплывает в памяти — разброс на include и src для библиотек.
Научить в данном случае лучше всего может только CMake в рамках проекта высокой сложности. Особенно, если в проекта присутствуют как минимум 3 языка. Структуру каталогов будет необходимо подстраивать под сложность проекта, под логические соображения, под git и под саму систему сборки. Но если обучаешься самостоятельно, то сам до этого всего либо не додумаешься, либо додумаешься очень не скоро.
Из вариантов можно устроиться на работу туда, где есть большие сложные проекты, желательно молодые и быстро развивающиеся, поскольку, главное — не попасть на legacy-проект.
А по поводу маленьких проектов, — структурирование каталогов в основном зависит от языка программирования и будет отличаться от языка к языку.
И зачем в курсе о С++ блок-схемы, паскаль и бейсик?
перемещаться к C, дублируя заученный код в новом синтаксисе
Сложно представить более вредный подход, чем заучивать код и переписывать его в новом синтаксисе. Или чем учить С++ начиная с Си.
Также ООП является ключевой разницей между C и C++
А это вообще неправда.
Сложно представить более вредный подход, чем заучивать код и переписывать его в новом синтаксисе. Или чем учить С++ начиная с Си.Мне всегда казалось, что это единственный правильный путь. В C++ не принято открыто работать с сырыми указателями, «вручную» управлять памятью и еще много всего, но оно есть под капотом в STL и всех остальных библиотеках. Должен же человек понимать как написать свой аллокатор.
Должен же человек понимать как написать свой аллокатор.
Может программист уровня мидла или крепкого джуна и должен, но вот новичек в С++ — вряд ли.
Скорость и объём новых знаний которые пытаются засунуть за ограниченное время упираются в ограничения мозга и тех знаний и ассоциаций которые уже есть у студента.
Еще меня всегда удивляло что в курсах, что в книгах никто не освещает вопрос как организовывать код, когда его реально много, и куча внешних зависимостей. Что бы в нём быстро ориентироваться, не переусложняя структуру при этом работать с кодом не увеличивая сложность. Одно дело когда у вас изделие из 100 деталей и другое дело когда из 100тыс деталей, которые еще и меняются со временем и работают не совсем так как задумывалось.
Скорость и объём новых знаний которые пытаются засунуть за ограниченное время упираются в ограничения мозга и тех знаний и ассоциаций которые уже есть у студента.
когда курс интересный, студенты запихивают себе в голову в три раза больше этих «ограничений мозга»
Еще меня всегда удивляло что в курсах, что в книгах никто не освещает вопрос как организовывать код, когда его реально много, и куча внешних зависимостей
у меня товарищей учили так: в течение семестра проект по ООП в несколько этапов, после каждого этапа кодобазы случайно перемешиваются между студентами. В итоге такие вещи как простота и расширяемость кода, личная ответственность за него, как читать чужой код, что и почему делать не стоит — всему этому они научились в рамках курса на собственном примере.
Я прошёл схему Pascal -> C -> WinApi (имхо, паскаль лишний в этой цепочке, но он был полезен более слабым ученикам). Плюсы изучал самостоятельно и первые года 2-3 реальной работы писал на си с классами, пока не познакомился с Qt. Не могу сказать, что это было плохо, но и не сказать что было хорошо. Минусы в таком подходе очевидны — мне было очень сложно приучиться к ООП мышлению и было сложно понять назначение паттернов проектирования. Много времени я был где-то между сильным джуном и слабым мидлом.
Считаю, что в этой цепочке просто не хватило следующего звена — а именно хорошего жёсткого курса по ООП с изобилием практики. Да, в универе у нас читали ООП (на примере консольных приложений в Делфи, никаких формочек) и читали хорошо. Но на лабах это не закреплялось. К тому же на тот момент я уже работал и мне было не до универа.
а здесь перечисление банальностей вперемешку со вредностями.На счет паскаля и бейсика согласен — это смешно и грустно одновременно. Один мой знакомый недавно пошел на курсы по вэбу, говорит, крутые, хорошую сумму отстегнул. Я говорю — красавец! И что вы там учите? А он — ну вот флэш начали… Дело в том, что всегда есть фактор выпавшего из струи преподователя, как правило, предпенсионного возраста, который всю жизнь пользовался тем, что уже нахер никому не надо, но что он знает досконально, а новое уже не тянет. Ну и впихивает это наивным нюбасам под тем или иным соусом. В ИТ сейчас реально столько технологий, которые маст кноу, что забирать у людей драгоценное время, забивая их головы непотребом — это просто, чисто по человечески, некрасиво.
И зачем в курсе о С++ блок-схемы, паскаль и бейсик?
Захотите работать в гейм-дизайне — путь лежит в Unity и схожие программы.Вот я, например, к своему стыду, только сейчас узнал, что С++ каким-то боком имеет отношение к Unity. Иди ты?! А в википедии написано, что только C#, JavaScript и раньше Boo.
Шутки шутками, но я встречал людей со страхом писать код практически на уровне фобии. И это был Python, а с С++ и я иногда фигею...
Этап 4. Начинаем с консолей
Согласен, программирование для XBOX и Playstation — это настолько важная ниша для C++, что можно к ней примериваться в самом начале обучения.
В любом языке программирования надо начинать писать программы не в сложных IDE, а в простых универсальных редакторах. Notepad++
Угу — а потом при запуске вчитываться в номера строк с ошибками в консоли и искать соответствующие участки кода в блокноте.
В свое время турбо-паскаль стал популярным в то-числе из-за удобной IDE.
Я наверное отстал от жизни, но разве в ВУЗах тем более школах «учат C++»?
Очень странно предлагать пользоваться линуксом и notepad++ вместе
Краткий гид по обучению С++: что, когда и на чём создавать