С++ с чего начинать реальную работу

Знаем мы таких профессионалов, которые чтобы две строки склеить пишут страницу проверок что им malloc NULL не вернул.

Ещё мы знаем профессионалов, которые искренне верят, что обработка std::bad_alloc - это такая надёжная стратегия обеспечения отказоустойчивости, которая позволяет благополучно записать сообщения в логи и закрыть их :-) И ничего, что в системнике просто напросто может сгореть какая-то деталька, и он просто напросто вырубится без всяких std::bad_alloc :-) Но простофилям же надо std::bad_alloc проверить, это же всяко лучше, чем SIGSEGV :-) Лол :-)

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

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

Вот мой код :-) Недавно в одном гайд-лайне вызубрил паттерн:

try {
  SuperServer s;
  s.start();
} catch (MemoryCardIsDestroyed &e) {
  // Запись в логи, только не в память - плата разрушена.
}

Ну так если тебе голову оторвет, то тоже особо торопиться с первой помощью не надо.

Какие нафиг текстурки?

Ну между спрайтиками какая нафиг иерархия? :) Иерархию между спрайтиками придумывают люди (и для заданий на собеседованиях), которые игор не писали и не знают зачем нужен ООП, или что цепепе мультипарадигменный (а если задача именно «напиши тетрис» — вообще не вангуй тут никакого «ООП по канонам» :) А под задачу — не будет там никакой развесистой иерархии :) Рендер, коллекция текстурок для спрайтиков и логика «проваливания» в стакашек, которой пофиг, как и где они отображаются. Некоторым в местных чятиках и в калькуляторе какая-то иерархия мерещится.

Очень нравится мне С/С++

Да ты извращенец. Или просто ничего другого не видел?

Я думал подключиться к какому-нибудь опенсорс проекту

На самом деле нубы там никому не нужны.

Есть хороший план обучения - править старые баги, которые в новых версиях уже исправлены и сравнивать свои патчи с патчами сообщества - а на различиях этих патчей учиться, думать, почему сделали именно так, а не так как у тебя. Но это уже не нуб-левел. Фиксить чужой код, тем более на С/С++, сложнее чем писать свой.

совсем не понятен пункт 2

1) Учим по книге синтаксис

2.1) пишем простую фановую фигню

2.2) учимся отлаживать простую фановую фигню

2.3) учим алгоритмы и структуры данных

2.4) пишем фановую фигню посложнее

2.5) оттачиваем технику отладки на фановой фигне посложнее

2.6) разобравшись с этим, можно поизучать БД с более прикладной точки зрения

2.7) написать фановую фигню с базами данных

2.8) учим средства автоматизации: тестирования, контроля версий и всякие другие полезные штуки

2.9) патчим маны в опенсорсе, пишем тесты на баги, вежливо просим объяснить, почему коммиты не принимают и пытаемся исправиться. админский опыт работы с ебилдами или дебилдами приветствуется

2.10) попутно изучаем чужой код. развиваем внутреннее чувство говнокода, чтобы коммиты принимались по возможности с первой попытки

<-- вот где-то здесь уровень уверенного джуниора

2.11) пишем что-нибудь свое посложнее, и переписываем, пока детектор говнокода не перестанет пищать

2.12) вот тут, наверное, можно попробовать вышеописанный метод с правкой уже исправленных багов. ищешь что-нибудь попроще, патчишь, сравниваешь результат

2.13) можно попробовать и реальные баги править

3) Работаем на крупном проекте

Прежде чем гробить свою жизнь, посмотри в сторону нормальных языков. В любом случае, знать 2-3 языка и минимум 2-3 парадигмы (в узком смысле) будет полезно, даже если в итоге остановишься на своем С++.

Раз уж ты админ, можешь начать пп2.1 и 2.3 со скриптов (чтобы не было проблем с поиском идей) - какой нибудь питон или, не к ночи будь помянут, перл подойдут лучше сишечки.

Может быть есть какая-нибудь книжка или курс про GUI на С++?

ага, есть. парочка...

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

GUI
сетей

вот где-то тут детектор должен жалобно пискнуть

Только документацию надо читать тщательно, особенно про время жизни буферов.

ага. прочитал книжку про синтаксис - и в буферах разберешься[/sarcasm]

Или ты собрался остановиться на детских helloworld-ах с консольным вводом?

ТС, если дорастешь до уровня таких консольных helloworld-ов как grep или find, считай, пришел к успеху

если очень хочется GUI, прозреваю в тебе не админа, но вендоадмина (no offense). GUI только отвлекает на рюшечки.

за GUI нелья браться раньше, чем перестанешь называть себя админом (это уже где-то после п.2.2), и чтобы познать GUI, надо учить всякие ООП и паттерны, иначе детектор потом будет пищать не смолкая

Любая игра, примитивно, — это банальный цикол опроса в котором дергаются подсистемки, которые сами знают чего им делать, что описывается конечным автоматом если не лень а обычно длинный свич «апдейтания» всего подряд :) Логика игоря только оркеструет чего грузить, да в каком порядке рисовать, как реагировать на ввод от юзиря, да как считать коллизии и исходы. А всякие «класс Elf наследует от BaseCharacter руки-ноги + длинные ухи» — это устаревшее «ненужно», существующее только на уровне скриптов, и то не всегда, внутри двигла никто так щас не делает: все игровые объекты — тупо коллекции «свойств», обрабатываемых в своих подсистемах (еще тупее - коллекции индексов экземпляров ресурсов, обрабатываемых исключительно в подсистемах в виде плоских коллекций. Особенно если ориентируемся на современный OpenGL и шейдеры, которыми обрабатываются плоские коллекции... вершин треугольников. В примитивных игрушках типа тетриса даже любимый почем зря «граф сцены», ни octree не нужны от слова вообще) Именно поэтому Lua отлично справляется с описанием этих табличек свойств и часто пристегивается к готовому движку, который ничо про логику конкретного игоря не знает, в качестве настраивательной скриптоты (хотя мне больше нравится AngelScript или js): игрологика получается такая - «Загрузи пачку моделек», «загрузи пачку звуков», «а между модельками и звуками задай вот такие соответствия», «чекай такие коллизии, показывай то-то и вон тот клевый звук еще», «чекай такой-то ввод — делай то-то» - для удобства дезигнера обычно оперируют спеками игровых объектов (смотрим любой редактор — описание объекта — тупо табличка, даже визуально), но внутри движка-то их все одно нет — только плоские коллекции каждая в своей подсистеме :) Внутри подсистем/компонентов никто не запрещает пользоваться «ООП по канонам», но развесистых иерархий тоже не будет — благо все ресурсы конкретной подсистемы однотипные :) Где можно применить ООП? Ну, в описании сцен, если скриптовой клей позволяет — и то наследование тут с успехом заменяется агрегацией :) Но примитивно сцена — ох, щи... опять коллекция описаний объектов :)

а вы, молодые и резвые, смело пишете по нулевому адресу, без проверок? ну, удачи вам. надеюсь, я не столкнусь с результатами ваших потуг. а то кодопейсателей развелось, как собак нерезаных. а качественного софта всё меньше.

ясно. не писал

Нафига в 2016 году изучать с++ с нуля? Есть же нормальный человеческий D или Swift на крайняк, Go тоже ничего. Если бы я писал на C++ - то только сетевые приложения. Например, расширения для Node.js. Напиши компилятор less на си++. (less.js)

Какой ещё нулевой адрес? Ты C++-то вообще видел, программист с двадцатилетним стажем?

написать тетрис в миллион раз проще, чем разобрать TCP/IP-стек. сети - это сети. виджеты - это виджеты. так что котлеты - отдельно, мухи - отдельно. поэтому я и говорю, что ты пока путаешь тёплое с мягким. к тому же сейчас тенденция гуестроения идёт в сторону веба. юзер уже не хочет толстого клиента, он хочет, чтобы всё работало в браузере, на гаджетах и т.д. поэтому веб и тонкие клиенты потихоньку вытесняют развесистые интерфейсы. ну, кроме специфических приложений, в которых гуй сам по себе и есть цель и основная задача. но таких довольно мало.

пфф! детка, узбагойся и иди делать уроки. вам, видимо, ещё не рассказали в школе про защиту памяти и всякие там злые эксепшны и сегфолты. ну да ладно, всё ещё впереди.

которые игор не писали

А игры нужны? :-)

не знают зачем нужен ООП

Не для организации ли большинства кодерков для их взаимопонимания и взамозаменяемости? :-)

цепепе мультипарадигменный

Лол :-)

Рендер, коллекция текстурок для спрайтиков и логика «проваливания» в стакашек, которой пофиг, как и где они отображаются.

Ой, да ладно заливать тут про абстракции :-) Не тому в уши льёшь :-) Лол :-)

Где можно применить ООП? Ну, в описании сцен, если скриптовой клей позволяет — и то наследование тут с успехом заменяется агрегацией :) Но примитивно сцена — ох, щи... опять коллекция описаний объектов :)

Угу, поэтому ООП не нужен, и, вместе с ним и цепепе :-) Лол :-)

Ну так если тебе голову оторвет, то тоже особо торопиться с первой помощью не надо.

Поэтому не засунуть ли тебе std::bad_alloc вместе с записями в логи туда, откуда ты его вытаскиваешь, и не лить в уши про профессионализм проверки на NULL от malloc() ? :-) Лол :-)

А игры нужны? :-)

судя по наличию огромной массы эльфов 80-го уровня в сетях, игры не только нужны, они вообще чуть ли не главная индустрия в современном программировании. игры, социалочки, овощи, рожь, вот это всё.

Нет ты :)

А игры нужны? :-)

Кому-то выше по треду нужен был тетрис :) А если не нужен — ну на нет и суда нет.

Не тому в уши льёшь

Ты вообще набор буковок на экране, да еще и читать не умеешь :) Абстракции где-то увидал :)

Nyet. Поэтому не нужно ООП там, и в том виде, где его спрашивают на собеседованиях — в тетрисах всяких.

цепепе мультипарадигменный

Лол :-)

Давай, кэп, возрази по существу.

цепепе мультипарадигменный
Давай, кэп, возрази по существу.

Ничего против мультикостыльности не имею :-)

Не для организации ли большинства кодерков для их взаимопонимания и взамозаменяемости? :-)

Для организации кодерков есть специально обученный чувак - он же дежурная жеппа, отвечающая за взлет-невзлет проекта :) А ООП ради самого ООП ненужен нигде: это просто инструмент декомпозиции, который ни кода не напишет, ни, однако, и декомпозицию задачи волшебным образом не обеспечит (иерархии классов в тетрисе или в калькуляторе - пример использования не по назначению). Ни тем более они тебе не обеспечат (само)организацию кодерков, которые готовы до посинения «рефакторить» — и вообще чинить не сломаное, пока по шее не получат «по цепочке иерархии». В компонентном подходе иерархия каких-либо классов вообще вторична (особенно если язык ее позволяет как плюсы, но не форсит, или вообще не поддерживает — как Ц, что однако и в Ц не исключает использования «объектно-ориентированных» фишек), чего разумеется не понимают пасущиеся в местных сишных/цепепешных чятиках кодерки с основным бэком в жабе, которые без геттеров и MVC шагу ступить не могут :)

Имеешь-имеешь: «костыль» — оценочное суждение :)

Nyet. Поэтому не нужно ООП там, и в том виде, где его спрашивают на собеседованиях — в тетрисах всяких.

Значит ли это, что обратившемуся в форум новичку, который хочет за год набраться знаний, чтобы потом устроиться работать программистом C++, не следует изучать ООП «в том виде», в котором преподносят его в книжках, а следует начать прямо с игровых движков, чтобы на собеседовании о C++ блеснуть знаниями о текстурках? :-) Лол :-)

Абстракции где-то увидал :)

Увидел целый перечень абстракций, тобой указанных, которых ты и не заметил :-) Лол :-)

Там все предельно конкретно, Евгений Вагонович :) «Веревка — вервие простое». А обосракции на это натягивают граждане с ООП головного моска, либо умничающие не по делу «оценщики коньдедатов».

Для организации кодерков есть специально обученный чувак - он же дежурная жеппа, отвечающая за взлет-невзлет проекта :)

Нет, для организации кодерков есть целые кучи гайд-лайнов, «стандартов программирования» от Саттера до Александреску, всяких книжек про паттерны от 4-х и т.д. :-) А обученный чувак, он же «эффективный менеджер», лишь способствует координации кодерков :-)

Микроскопаме забивать гвозди — это, конечно, можно. «И это пройдет» (с)

Нет, для организации кодерков есть целые кучи гайд-лайнов

В мире розовых пони, и там где Александреску дописал D :) А Саттер пилил не только стандарт :)

Рендер,
коллекция
текстурок
спрайтиков
«проваливания»
стакашек

Это всё абстракции :-)

которой пофиг, как и где они отображаются.

Вот вот, ч.т.д. :-)

Это всё абстракции :-)

Ну это ты их так назвал — слово небось понравилось :) Зато нет никаких вымороченных и заведомо избыточных «классов блоков тетриса» на уровне движка (он битмапиками ворочает - «текстурками»). И ему в общем пофиг тетрис это или не тетрис.

которой пофиг, как и где они отображаются.

Вот вот, ч.т.д. :-)

Это всего-то пониженная связность между компонентами :) А вот любители «классов блоков тетриса» непременно запихнут в «метод рисования» блиттинг конкретными колами OpenGL или еще какой способ отображения, напрочь похерив любезную тебе «абстракцию»

Ну это ты их так назвал — слово небось понравилось :) Зато нет никаких вымороченных и заведомо избыточных «классов блоков тетриса» на уровне движка (он битмапиками ворочает - «текстурками»). И ему в общем пофиг тетрис это или не тетрис.

Лол :-) Не мог бы ты выкатить своё определение абстракции? :-)

Это всего-то пониженная связность между компонентами :) А вот любители «классов блоков тетриса» непременно запихнут в «метод рисования» блиттинг конкретными колами OpenGL или еще какой способ отображения, напрочь похерив любезную тебе «абстракцию»

Я понятия не имею о чём ты :-)

Лол :-) Не мог бы ты выкатить своё определение абстракции? :-)

Без контекста любое слово «пустое» — даже если звонкое :) Кто им пользуется, не всегда понятно — слышал ли чего кроме звона. Если у меня один рендер — OpenGL. Или DirectX. Какая ж это абстракция? Только досужие философские домыслы :) А если у меня их несколько, но они «завернуты» в обобщенный компонент, «что тот рендер, что этот» — движку без разницы. Вот она твоя абстракция :) Слой эквипенисуальности рендеров с точки зрения использования их движком :)

обобщенный компонент

А, теперь я понял :-) Для тебя обобщённый компонент - это абстракция, а абстракция - это обобщённый компонент :-) Против такой логики я бессилен :-) Лол :-)

Это твоя логика :) Даже в «абстрактной фабрике» употребляются хоть на уровне названий классов слова «абстрактный» в противовес «конкретному» - т.е. не везде там абстрактные сущности (это в естественном языке они все «абстрактны», потому что все сводится к «условным» же нулям с единицами :)). А у нормальных людей, а не евангелистов ООП, есть «интерфейсы» и «реализации». Без всякой даже привязки к ООП (потому что оно для декомпозиции не обязательно).

Это твоя логика :)

Нет, твоя :-)

Даже в «абстрактной фабрике» употребляются хоть на уровне названий классов слова «абстрактный» в противовес «конкретному» - т.е. не везде там абстрактные сущности (это в естественном языке они все «абстрактны», потому что все сводится к «условным» же нулям с единицами :))

Теперь напиши Страуструпу твои соображения насчёт абстрактных классов и абстрактных типов данных :-)

А у нормальных людей, а не евангелистов ООП, есть «интерфейсы» и «реализации».

Это абстракции :-) Лол :-)

Без всякой даже привязки к ООП (потому что оно для декомпозиции не обязательно).

Хм :-) Так и цепепе не обязательно :-) Всё, что ты мне тут пытаешься сообщить, прекрасно делается на чистом C :-) Но это только если программист является «нормальным человеком» и владеет абстрактным мышлением :-)

ООП в C++ вообще не нужен и не используетс.

ООП в C++ вообще не нужен и не используетс.

Ага, ага, не желаешь ли изучить библиотеку потоков, входящую в стандарт? :-) Лол :-)

Ага, ага, не желаешь ли изучить библиотеку потоков, входящую в стандарт? :-) Лол :-)

А где там ООП? Там даже наследования и виртуальных методов нет.

// другой анонимус

Go тоже ничего. Если бы я писал на C++ - то только сетевые приложения.

Так нафига на С++ писать сетевые приложения, когда есть Go?

А где там ООП? Там даже наследования и виртуальных методов нет.

Бугага :-) Иерархия стандартной библиотеки потоков :-)

Есть же нормальный человеческий D или Swift на крайняк

Первый обречен быть маргинальным языком на задворках, со всем вытекающим, второй - как минимум пока малоюзабелен за пределами OS X.

Go тоже ничего

Go уже нашел свою нишу, и она очень узкая.

Бугага :-) Иерархия стандартной библиотеки потоков :-)

А так ты про них, а я решил, что ты треды потоками назвал.

А так ты про них, а я решил, что ты треды потоками назвал.

А, это ты к тому, что кто-то потоки выполнения называет нитками? :-)

Ага, ага, не желаешь ли изучить библиотеку потоков, входящую в стандарт? :-)

И где там ООП, утырок? Ты б еще в STL ООП нашел.

И где там ООП, утырок? Ты б еще в STL ООП нашел.

А скажи, что круче, нити, бросание исключений или отлавливание std::bad_alloc для записи в логи? :-)