Привіт. Колись користувався сайтом на якому були головоломки-тести по плюсам — куски коду і потім варіанти відповідей, що воно робить. Здається, російськомовний ресурс. Ссилку загубив, можливо хтось знає про що я. Буду радий посиланням на любі подібні ресурси.
Вот эти ресурсы не плохие:
Типу, лікуєм наркоманію алкоголізмом?
Давайте. Вы пишете все правильно, но, во первых, изучение предметных областей не освобождает от изучения языка, а во-вторых, в случае плюсов, он является сложным, и хуже всего то, что он является сложным внезапно, вот в чем фокус ©
Больше пятнадцати лет прошло, а синьоры старшего поколения всё ещё ассоциируют Александреску с той одной книженцией из начала двухтысячных :(
Во-первых, подходы, изложенные в ней, не хрень и всё ещё актуальны.
Но актуальны они для чего? Для стандартного «прода», где ты решаешь какие-то задачи бизнеса? Нет.
Я не знаю, каким нужно быть извращенцем, чтобы лепить их туда без необходимости (да-да, знаю, что после прочтения книжки некоторым сносило крышу и они становились такими извращенцами — но это уже проблема личной впечатлительности отдельных людей, а не книжки или её автора).
Эти подходы актуальны для разработки обобщённых библиотек. Если ты пишешь свой аналог буста или стд, грубо говоря. Что в реальной жизни большинству из нас приходится делать крайне редко (а многим вообще не приходится).
Я работал некоторое время в одной продуктовой компании, которая по ряду причин юзала свою собственную альтернативу стандартной библиотеки. Там многие вещи были написаны с использованием policy-based design — и в их продукте это прекрасно работало. Причём они умудрились задизайнить эти шаблоны так, что пользоваться ими было на удивление удобно.
Иронично, что местные синьоры тоже воротили нос от фамилии Александреску. Но когда я их спрашивал, почему они так говорят, они отвечали, что просто не хотят, чтоб джуны писали такой код в их продукте. А они в своё время написали, оно работает, и не надо больше его трогать — просто пользуйся. С чем я, конечно, не спорил.
Пока нет серьёзной необходимости — нечего лезть в подобные техники. Но это никак не означает, что такие техники — хрень.
Во-вторых, современный C++ код, реализующий идеи Александреску из той книжки, выглядит хоть и всё ещё страшновато, но уже на порядок проще кода, который приводился в книге. Ибо в языке появились новые фичи, позволяющие сделать подобное метапрограммирование чуть более безболезненным.
В-третьих, хватит уже ассоциировать Александреску с той одной книжкой про policy-based design и паттерны. На самом деле этот мужик очень разносторонний и умеет интересно рассказать о разных темах, далеко не всегда связанных с темплейтами и метапрограммированием. Послушайте его лекции на ютубе. Перечислять не буду, слишом уж их много.
Скажу только, что одну из предложенных им идей — макрос SCOPE_EXIT — я со своей реализацией тащу уже не на первый проект, на котором мне доводится работать. И у коллег она вызывает исключительно положительные впечатления.
Потому что Александреску — имя нарицательное уже давно. Имя нарицательное для безумного кода на С++.
ты же выше согласился с тем, что он простой. Или mpl это не с++?=)
Он простой, если писать на нем просто без вые...нов.
«писать просто» это входит в состав твоего стиля программирования. Простой язык тебе банально не предоставит инструментов для таких выебонов. В с++ дохрена возможностей, порой с не самым удачным синтаксисом, мягко говоря, и неадекватными полотнами выводов об ошибках.
В с++ дохрена возможностей, порой с [...] неадекватными полотнами выводов об ошибках.
Вообще, полотна выводов об ошибках — это больше особенности не языка, а конкретного компилятора.
Само собой. Но язык сложный. Поэтому реализовывать компиляторы с адекватным выводом тоже сложно.
По сути сворачиваешь С++ до С с классами и он становится простым.
Кстати, хороший способ написания пoртабельного кода.
Нынче чем более ебануто и криво пишешь код, тем больше это ценится.
Но так же хочется вые...ться, особенно молодым.
Как бабка на лавочке :( Не надо так.
Этап «хочется повы@#ываться» большинство плюсовиков перерастают на этапе джуна, максимум начинающего миддла. Длится он, как правило, недолго. И тем более он никем не ценится — ни коллегами (которым потом в этом говне ещё разбираться), ни работодателем.
А с опытом через пару-тройку лет к такому человеку начинает приходить понимание, когда «вы@#оны» в коде действительно могут принести пользу (и да, такие случаи встречаются, хоть и крайне редко), а где их использование принесёт слишком малый выигрыш по сравнению с усложнением кода, и можно написать всё проще без особых потерь.
Как, это так просто было, так зачем за такое простое платить. О, тут п****ц, как сложно, хрен без 3 литров водяры поймешь, умный очень, писал, небось. его работа стоит больших денег.
Если знаешь вакансии, где так происходит, маякни мне :) А то писать сложный плюсовый код, где без трёх литров водяры не разобраться, я умею. Правда, пишу такое редко. Ибо «этап вы@#онов» уже перерос, а на практике оно нужно чуть чаще чем никогда.
На моём опыте пока что всё наоборот.
Работодателем ценится твоя способность решать поставленные задачи в срок. Как при этом написан код — ему до лампочки. Решил задачу одной строчкой, которую поймёт любой студент-первокурсник, — молодец. Решил через обфусцированный темплейт из древней книги Александреску — тоже молодец. Задача выполнена, фича работает, клиент доволен. Красота и понятность кода там никого не интересует.
А вот коллегами-программистами ценится как раз возможность понимать твой код и сопровождать его без необходимости пить водяру литрами. Пишешь простой код — с тобой легко работать, ты молодец. Переусложняешь — заставляешь тратить на сопровождение твоего кода лишнее время, значит не молодец.
Усложнение кода замедляет общую работу команды, мешает ей вовремя закрывать таски, а значит и вставляет палки в колёса работодателю. Такого программиста выгоднее уволить. А не доплачивать ему за то, что он «умный».
Поэтому пока не могу представить, где и почему могут ценить сложность кода как таковую.
И он становится сложным, потому что всё управление памятью снова на тебе.
Потому что Александреску — имя нарицательное уже давно. Имя нарицательное для безумного кода на С++.
Среди синьоров «старой закалки», что работали уже в начале двухтысячных и застали тех самых впечатлительных извращенцев, которые после прочтения книжки начинали лепить переусложнённые темплейты в прод по поводу и без.
А для C++ девелоперов моего поколения это просто крутой эксперт с кучей интересных лекций и идей разной степени полезности. Он выпустил слишком много разнообразного контента с тех пор, чтобы всё ещё имело смысл так тесно ассоциировать его с той единственной книжечкой.
Нынче модно говно растаскивать во максимальной территории, чтобы везде воняло одинаково.
Я таким как раз не занимаюсь. Насчёт SCOPE_EXIT’а выпад не засчитан, ибо он не говно, даже если у него реализация через макрос.
При использовании он воспринимается именно как дополнительная фича языка, а не так, как мы обычно воспринимаем сишные макросы, поскольку на вызывающей стороне ему через круглые скобки никакие параметры не передаются.
Просто пишем
Повернись Живим
Viktor Alkhimov
anonymous
anonymous
Taras Morozovsky
Sergei Beloborodov
Nikola Utiuzhnikov
Мокий Парменыч
Valentin Nechayev
SCOPE_EXIT
{
// код, который должен выполниться при выходе из текущего скоупа
};
вместо создания каких-то хелпер объектов с кастомными деструкторами.Макросы в С и С++ — это безусловное уродство.
Это безусловное уродство, с которым приходится жить в наших реалиях, пока ему не изобрели менее уродливую замену.
А пока что они иногда необходимы, и использовать либо не использовать макрос — это неоднозначный выбор, который требует взвешенного решения в каждом индивидуальном случае: насколько сильное уродство ты привнесёшь в проект по сравнению с тем, какой выигрыш от этого макроса будет получен.
Если один макрос поможет тебе избавиться от сотен лишних строк кода, а его использование будет безопасным и никому ничего не поломает, — значит, это хороший макрос (насколько в принципе хорошими могут быть макросы). И SCOPE_EXIT — пример именно такого макроса.
Для С++ я предпочитаю, чтобы компилятор это сделал и по выходе из скопа прибил.
Так SCOPE_EXIT именно это и делает. Просто обычно нам для этого приходится писать кастомные классы со своими деструкторами. Или использовать существующие, если они уже были кем-то написаны раньше именно для этого конкретного сценария.
А если готового нет и писать новый класс ради одного единственного кейса как-то впадлу, можно заюзать SCOPE_EXIT. Он всего лишь автоматизирует это создание объекта класса с нужным тебе деструктором. Синтаксический сахарок, добавляющий удобства и лаконичности в код. Никаких минусов.
Конечно я тоже предпочитаю готовое из существующих библиотек, когда оно уже есть.
Но иногда готового нет. И тогда писать кастомный класс со своим деструктором просто ради возможности гарантированно выполнить определённые действия при выходе из скоупа — ну да, это вариант. Я предпочитаю так делать, если один и тот же набор действий при выходе из скоупа мне нужен в трёх или более разных местах в коде.
Если же мне нужен специфический деструктор только в одном месте, и больше, скорее всего, мне такой же не понадобится, — предпочту SCOPE_EXIT как более удобный и лаконичный аналог.
Біда тут в тому, що люди продовжують писати свої реалізації SCOPE_EXIT в той час як його реалізації в бусті десь вже років
На попередньому місці роботи буст не використовували. На поточному використовують і я, звичайно, спочатку проінвестігейтив, чи варто мені нести свій велосипед сюди, якщо вже доступна бустова реалізація. І прийшов до висновку, що варто.
В реаліях нинішнього стану буста це не біда. Бо в бусті поки що скоуп_екзіт — пєчялька.
Ти відкривав їх реалізацію? Дивився, як вона працює і який асм генерує?
Там під капотом аналог std::function з усіма витікаючими.
Це просто дурість, засовувати лямбду в type-erasing контейнер, коли type erasure тобі нафіг не треба. Коду стає надто багато, компілятор в ньому тоне і не може нічого заінлайнити, з’являється купа зайвих call’ів і непотрібних перевірок, що приводить до роздуття розміру об’єктних файлів і втрати перформансу на пустому місці.
Звичайно, в деяких місцях це може й не бути критичним. Але часто такі втрати недопустимі. Ми ж все-таки на плюсах пишемо.
От якби стандартизували (або хоча б додали в буст) версію скоуп_екзіта, яку пропонував Александреску, все було б чудово і я б її аналог не велосипедив.
Звичайно, в ідеальному світі компілятор міг би зоптимізувати й таке. Але поки що компілятори до такого не дійшли, і бустова версія скоуп_екзіта навіть на найсучасніших компіляторах з усіма ввімкненими флажками компілюється в якусь кашу з лайна.
В чому виражається складність плюсів?)
(Вони різні)
Наприклад, поклікайте cppquiz.org який я власне шукав у цьому топіку.
C++ как раз-таки является сложным. А простым Си. И да, области применения и там, и там могут быть сложные, это вообще отдельные темы.
C++ как раз-таки является сложным. А простым Си.
Самые подлые грабли — с переполнениями, алиасингами и т.п. — у них одинаковые.
А вот управление памятью на C++ проще — если соблюдать базовую дисциплину.
Думка розумна, але в контексті питання беззмістовна.
Содержательная. Тот, кто учит по книжкам — становится читателем. Тот, кто пишет лабораторки — становится хорошим писателем лабораторок. Тот, кто кодит — становится хорошим кодером.
Не будь читателем и писателем лабораторок — за это не платят. Будь кодером!
Вода мокра, трава зелена, лондон із зе кепітал оф грит британ. Але дякую за спробу.
Из крайности в крайность. Неразумно.
Тот, кто учится только через написание своего кода без чтения книжек, становится говнокодером.
А хороший кодер учится, параллельно читая книжки, статьи, просматривая лекции и т.д., и при этом естественно пописывая какой-то код (лабораторки/курсовые для этого тоже подходят, если студент).
Это научит тебя кодить.
Но чтобы стать программистом, которому деньги платят, нужно работать. Не кодить, а работать (кодинг — часть работы, но гениальный кодер за неимением остальных скиллов будет хреновым работником).
Так что после освоения основ кодинга нужно идти джуном или трейни в какую-нибудь компанию и там получать реальный опыт.
Тот, кто учится только через написание своего кода без чтения книжек, становится говнокодером.
Во время написания своего кода будут появляться вопросы. За ответами чел будет попадать на стэковерфлоу итп — а там и получит указания на хороший код, проекты в исходниках, итп.
Частично согласен. Сам так делаю с технологиями, с которыми сталкиваюсь время от времени — но не настолько часто, чтобы имело смысл читать целую книгу.
Но если читать книги, знания будут более фундаментальными и систематизированными. Здесь нужен баланс между читательством и разбирательством в процессе.
Я бы советовал по чистым плюсам всё же читать книги. А вот фреймворки и сторонние библиотеки типа кьюта или буста можно уже учить точечно разбираясь с отдельными вопросами в процессе кодинга.
Дякую! Не той самий ресурс, але по суті теж саме.
Гляньте про всяк випадок ще це:
Советы сеньоров: как прокачать знания junior C++
dou.ua/...icles/senior-c-plus-plus
Є тема на DOU корисні ресурси для програміста, можливо там знайдеш
Володимир Корнійчук
Altas
Мокий Парменыч
Altas
Sergii Voloshyn
Олексій Пєніє
Олексій Пєніє
Senseye
47 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів