RAII есть - см. ветку "Идиомы", находится рядом с pimpl (Этап 4)
SFINAE есть - см ветку "Шаблоны (Этап 4, предшествует идиомам)
STL есть, названа как "Стандартная библиотека" (не очень удачное название получилось). В ней перечислены основные части STL (Этап 3)
Компиляция представлена в ветке "Компиляторы" (Этап 3 - часть 2)
Про gsl - хорошая ремарка, думаю, что стоит это добавить в карту
Соорудить иерархию - несложно, а вот детализировать листья - уже другой вопрос, да и стоит ли? Информацию по листьям уже можно поискать в книгах/интернете.
Если вы готовы заняться детальным описанием листьев, помимо генерации иерархии, то мы с радостью примем такую помощь, в ином случае - большого смысла сооружать мощную генерацию иерархии карты нет (к тому же кому-то придется это дополнительно поддерживать в будущем :) ).
Изначально было в планах создать дорожную карту, а затем её каждый листик сопроводить дополнительными комментариями/ссылкой на мини-статью в репозитории. В какой-то момент стало понятно, что эта задача для нас слишком масштабная, потому было решено от нее отказаться.
Мы готовы принять любую помощь от коммьюнити, чтобы дорожная карта приняла иной облик, отличный от текущего. Вы можете помочь нам с переформатированием дорожной карты в текстовом виде, так что с радостью ждем PR'ов.
Искусство разработки на современном C++. Курс поделен на этапы. Каждому этапу создатели присвоили "цвет пояса" (по аналогии из боевых искусств), который описывает уровень сложности. Многим этот курс известен, потому его частенько называют коротким названием "Пояса C++".
Отчасти это можно лечить грамотной декомпозицией проекта на компоненты, а также обертыванием этих компонентов в пакеты. Но для этого нужно очень много ресурсов, а также высокая культура/дисциплина среди разработчиков. Но это также вызывает другие проблемы, связанные с поддержкой единственно правильной версии компонента, когда его растащат в десятки дочерних кусков проекта.
Вечная борьба, которую пока никто так и не смог возглавить и одержать полноценную победу.
Предлагаю остановить обсуждение этого вопроса, т.к. данная статья ровно о другом.
Если у вас есть желание обсудить несправедливость рынка и иные вопросы, связанные с ушлыми работодателями, то на хабре и других ресурсах представлено полно статей и дискуссий, где вы можете сполна высказаться.
Продолжать же полемику не вижу никакого смысла, все равно никто никому ничего не докажет :)
Мы никого никуда не привлекаем, и никого никуда не пытаемся заманить подешевле. Данный проект - исключительно альтруизм нескольких человек, которые увидели проблему и решили объединиться вокруг нее (и решали её в рамках ограниченного ресурса).
Тогда возникает закономерный вопрос: для чего во многих компаниях сидят десятки UI/UX специалистов, которые пытаются построить удобные и дружелюбные интерфейсы?
Я вдоволь насмотрелся на эти "5 минутные" интерфейсы, прямиком из нулевых, где представлены тысячи вкладок в одном окне, а в каждой вкладке десятки и сотни кнопок/выпадающих списков/селекторов и т.д.
Предлагаю все-таки оставить эту вотчину тем, кто лучше разбирается в вопросах взаимодействия с конечным пользователем, и не пытаться быть экспертами в любом вопросе.
Я соглашусь, что если вы делаете какую-то маленькую утилиту для внутреннего использования, то может и не стоит для этого привлекать полноценный штат фронтендеров, и решить вопрос своими силами, но если же это решение направлено на большую целевую аудиторию, то пусть этим займутся профильные специалисты.
Ради нескольких кнопок может быть и не стоит, тогда в рамках дискуссии стоит провести четкую границу: какой UI собираемся строить? Для какого проекта и какого размера?
Если для себя или что-то протестировать, то наверно не стоит мучаться с фронтом и втаскивать любой зоопарк в проект. Может быть и вовсе не стоит кнопки делать, можно и через консоль протестировать то что требуется.
Если это какое-то крупное коммерческое решение - то пилить UI на C++ - очень уж опрометчивое решение. За исключение можно взять легаси-наследие, которое приходится тащить, просто потому что это уже есть, а переписывать никто не берется (тот же UI на MFC и чем-то аналогичном).
В противном случае, определенно стоит смотреть в сторону других стеков, т.к. и специалистов больше, и экспертиза лучше. Все-таки большая часть IT-продуктов живет нынче не на десктопе, а в вебе/мобилках. Отрисовать json-молотилку или очередной crud на C++? Очень и очень спорное решение. Пусть все-таки язык занимается ровно тем, под что он заточен, а не "кнопки двигает" :)
Возможно в этом поле только Automotive стоит особняком, т.к. UI на Qt там прочно занял нишу. Или же Gamedev, т.к. многие вещи, либо на готовых движках пилится, либо свои кастомные велосипеды.
Так что противоречий никаких не вижу. Нужно принимать решение в каждом отдельном случае. Но зачем колхозить на плюсах то, что можно решить гораздо проще и быстрее другими инструментами - остается открытым.
Собственно я и начну с ответа, что "они популярны", и представлены практически повсеместно во многих крупных проектах.
Я понимаю, что модное/стильное/молодежное всегда вкуснее и приятнее, нежели чем "проклятое" легаси. Никто не запрещает изучать модные штучки, но придя на проект, скорее всего придется столкнуться с богоугодными Cmake/Conan/Ninja. Если о них не упомянуть, то может случится большое разочарование у новоиспеченного плюсовика.
Подобные штуки - факультатив, который можно будет изучить в любое время, а возможно даже внедрить в свой проект, но это совершенно другая история. Да и к тому же все эти штучки: "Старые песни о главном". Посмотрев на основы, можно спокойно преисполняться новыми реинкарнациями пакетных менеджеров/менеджеров зависимостей.
Перед нами стояла задача предоставить различные комментарии по темам, которые вертятся вокруг языка. Мы считаем, что это поможет гораздо больше, нежели чем попытка все запихнуть в объем, охватываемый взглядом. Дорожная карта - автономная и не подразумевает наличие ментора или кого-то ещё (т.к. не всем удается найти себе наставника на самом старте), потому чем больше комментариев - тем меньше неоднозначностей.
К сожалению задать супер четкую последовательность для C++ - довольно сложная задача. Мы начали строить что-то подобное, но в ходе работы поняли, что впихнуть "невпихуемое", не представляется возможным. Такова цена компромисса, за возможность получить обзорную информацию, что нынче ожидается от среднестатистического плюсовика (в отрыве от конкретных специализаций)
Все верно. Секции для миддлов и синьоров предназначены для того, чтобы показать дальнейший вектор развития, когда планка джуниора достигнута. Вопрос роста заботит многих джунов не меньше, чем просто "вкатиться". Так что данные ресурсы - примерный вектор направления их движения.
К сожалению мы не можем удовлетворить всех и вся. Если человек отвалится на мотивационной книге, которая призвана замотивировать, то такому человеку стоит искренне задать самому себе вопрос: "А это действительно то, чем я хочу заниматься и положить на это месяцы своей жизни? Не будет ли разочарования в конце пути?" Наш проект - не инфоцыганство, и не курсы, чтобы заманивать кого-то к себе. Мы лишь "даем удочку", а брать её или нет - решать читателю.
Увы, по плюсам к сожалению нет и не будет "серебрянной пули" (единственной книги), по которой можно будет раз и навсегда преисполниться познанием языка. Да и в других языках ситуациях идет ровно к тому же. Языки растут и развиваются, добавляются новые фичи и возможности, которые не уместить в одну книгу.
валили в кучу общедоступную информацию и переструктурировали оглавления нескольких книжек по С++
Это и было фундаментальной основой проекта - собрать воедино актуальную информацию, и предоставить её для тех, кто желает изучить язык, и показать примерный вектор движения.
К сожалению, этого и не хватает многим новичками, т.к. за десятилетия жизни языка было выпущено слишком много книг и прочих материалов спорного качества. В момент выбора, новичок скорее бросит эту затею, т.к. потеряется в обилии информации.
Так что "свалить в кучу" - тоже нужно приложить массу усилий: отфильтровать и отобрать то, что в эту кучу стоит поместить, а что отбросить :)
Опять же, есть добротные курсы по C++, но конкурировать с ними - непосильная задача. Наша работа больше для тех, кто предпочитает самостоятельное обучение.
Технически возможно все, но стоит ли стрелять "из пушки по воробьям"?
Для UI есть более доступные инструменты, на которых можно построить графический интерфейс, но гораздо быстрее/проще/качественнее. Лучше стоять на принципе - каждому инструменты - надлежащее применение. Зачем строить звездолет, когда требуется перетащить пару мешков цемента?
Как с языка сняли! Мы с коллегами долго думали над этим вопросом, стоит ли как-то акцентироваться на тех же UI фреймворках более подробно и т.д.
Но в конце пришли ровно к тому же выводу, что и вы: UI - тема интересная, но сегодня лучше выбирать другие инструменты для их построения: делать UI на плюсах, все равно что из пушки по воробьям стрелять.
RAII есть - см. ветку "Идиомы", находится рядом с pimpl (Этап 4)
SFINAE есть - см ветку "Шаблоны (Этап 4, предшествует идиомам)
STL есть, названа как "Стандартная библиотека" (не очень удачное название получилось). В ней перечислены основные части STL (Этап 3)
Компиляция представлена в ветке "Компиляторы" (Этап 3 - часть 2)
Про gsl - хорошая ремарка, думаю, что стоит это добавить в карту
Соорудить иерархию - несложно, а вот детализировать листья - уже другой вопрос, да и стоит ли? Информацию по листьям уже можно поискать в книгах/интернете.
Если вы готовы заняться детальным описанием листьев, помимо генерации иерархии, то мы с радостью примем такую помощь, в ином случае - большого смысла сооружать мощную генерацию иерархии карты нет (к тому же кому-то придется это дополнительно поддерживать в будущем :) ).
Изначально было в планах создать дорожную карту, а затем её каждый листик сопроводить дополнительными комментариями/ссылкой на мини-статью в репозитории. В какой-то момент стало понятно, что эта задача для нас слишком масштабная, потому было решено от нее отказаться.
Базовую структуру для подобной организации комментариев мы создали в репозитории, но затем забросили. На тот момент считалось достаточным просто приложить ссылку на страничку гитхаба к каждому листику: https://github.com/salmer/CppDeveloperRoadmap/tree/main/Russian/Notes
Вы хотите сделать примерно тоже самое, или же дополнительно заняться описанием каждого листа?
Все так, извечная борьба, от которой пока не придумали как уйти: скорость vs удобство.
Все верно говорите! И вам спасибо за обратную связь!
Мы готовы принять любую помощь от коммьюнити, чтобы дорожная карта приняла иной облик, отличный от текущего. Вы можете помочь нам с переформатированием дорожной карты в текстовом виде, так что с радостью ждем PR'ов.
И правда странно :D
Искусство разработки на современном C++. Курс поделен на этапы. Каждому этапу создатели присвоили "цвет пояса" (по аналогии из боевых искусств), который описывает уровень сложности. Многим этот курс известен, потому его частенько называют коротким названием "Пояса C++".
https://ru.coursera.org/specializations/c-plus-plus-modern-development
Есть такая беда, согласен.
Отчасти это можно лечить грамотной декомпозицией проекта на компоненты, а также обертыванием этих компонентов в пакеты. Но для этого нужно очень много ресурсов, а также высокая культура/дисциплина среди разработчиков. Но это также вызывает другие проблемы, связанные с поддержкой единственно правильной версии компонента, когда его растащат в десятки дочерних кусков проекта.
Вечная борьба, которую пока никто так и не смог возглавить и одержать полноценную победу.
Спасибо за понимание!
Вот и я ровно о том же :)
Предлагаю остановить обсуждение этого вопроса, т.к. данная статья ровно о другом.
Если у вас есть желание обсудить несправедливость рынка и иные вопросы, связанные с ушлыми работодателями, то на хабре и других ресурсах представлено полно статей и дискуссий, где вы можете сполна высказаться.
Продолжать же полемику не вижу никакого смысла, все равно никто никому ничего не докажет :)
Мы никого никуда не привлекаем, и никого никуда не пытаемся заманить подешевле. Данный проект - исключительно альтруизм нескольких человек, которые увидели проблему и решили объединиться вокруг нее (и решали её в рамках ограниченного ресурса).
Тогда возникает закономерный вопрос: для чего во многих компаниях сидят десятки UI/UX специалистов, которые пытаются построить удобные и дружелюбные интерфейсы?
Я вдоволь насмотрелся на эти "5 минутные" интерфейсы, прямиком из нулевых, где представлены тысячи вкладок в одном окне, а в каждой вкладке десятки и сотни кнопок/выпадающих списков/селекторов и т.д.
Предлагаю все-таки оставить эту вотчину тем, кто лучше разбирается в вопросах взаимодействия с конечным пользователем, и не пытаться быть экспертами в любом вопросе.
Я соглашусь, что если вы делаете какую-то маленькую утилиту для внутреннего использования, то может и не стоит для этого привлекать полноценный штат фронтендеров, и решить вопрос своими силами, но если же это решение направлено на большую целевую аудиторию, то пусть этим займутся профильные специалисты.
Ради нескольких кнопок может быть и не стоит, тогда в рамках дискуссии стоит провести четкую границу: какой UI собираемся строить? Для какого проекта и какого размера?
Если для себя или что-то протестировать, то наверно не стоит мучаться с фронтом и втаскивать любой зоопарк в проект. Может быть и вовсе не стоит кнопки делать, можно и через консоль протестировать то что требуется.
Если это какое-то крупное коммерческое решение - то пилить UI на C++ - очень уж опрометчивое решение. За исключение можно взять легаси-наследие, которое приходится тащить, просто потому что это уже есть, а переписывать никто не берется (тот же UI на MFC и чем-то аналогичном).
В противном случае, определенно стоит смотреть в сторону других стеков, т.к. и специалистов больше, и экспертиза лучше. Все-таки большая часть IT-продуктов живет нынче не на десктопе, а в вебе/мобилках. Отрисовать json-молотилку или очередной crud на C++? Очень и очень спорное решение. Пусть все-таки язык занимается ровно тем, под что он заточен, а не "кнопки двигает" :)
Возможно в этом поле только Automotive стоит особняком, т.к. UI на Qt там прочно занял нишу. Или же Gamedev, т.к. многие вещи, либо на готовых движках пилится, либо свои кастомные велосипеды.
Так что противоречий никаких не вижу. Нужно принимать решение в каждом отдельном случае. Но зачем колхозить на плюсах то, что можно решить гораздо проще и быстрее другими инструментами - остается открытым.
Собственно я и начну с ответа, что "они популярны", и представлены практически повсеместно во многих крупных проектах.
Я понимаю, что модное/стильное/молодежное всегда вкуснее и приятнее, нежели чем "проклятое" легаси. Никто не запрещает изучать модные штучки, но придя на проект, скорее всего придется столкнуться с богоугодными Cmake/Conan/Ninja. Если о них не упомянуть, то может случится большое разочарование у новоиспеченного плюсовика.
Подобные штуки - факультатив, который можно будет изучить в любое время, а возможно даже внедрить в свой проект, но это совершенно другая история. Да и к тому же все эти штучки: "Старые песни о главном". Посмотрев на основы, можно спокойно преисполняться новыми реинкарнациями пакетных менеджеров/менеджеров зависимостей.
Перед нами стояла задача предоставить различные комментарии по темам, которые вертятся вокруг языка. Мы считаем, что это поможет гораздо больше, нежели чем попытка все запихнуть в объем, охватываемый взглядом. Дорожная карта - автономная и не подразумевает наличие ментора или кого-то ещё (т.к. не всем удается найти себе наставника на самом старте), потому чем больше комментариев - тем меньше неоднозначностей.
К сожалению задать супер четкую последовательность для C++ - довольно сложная задача. Мы начали строить что-то подобное, но в ходе работы поняли, что впихнуть "невпихуемое", не представляется возможным. Такова цена компромисса, за возможность получить обзорную информацию, что нынче ожидается от среднестатистического плюсовика (в отрыве от конкретных специализаций)
Все верно. Секции для миддлов и синьоров предназначены для того, чтобы показать дальнейший вектор развития, когда планка джуниора достигнута. Вопрос роста заботит многих джунов не меньше, чем просто "вкатиться". Так что данные ресурсы - примерный вектор направления их движения.
К сожалению мы не можем удовлетворить всех и вся. Если человек отвалится на мотивационной книге, которая призвана замотивировать, то такому человеку стоит искренне задать самому себе вопрос: "А это действительно то, чем я хочу заниматься и положить на это месяцы своей жизни? Не будет ли разочарования в конце пути?" Наш проект - не инфоцыганство, и не курсы, чтобы заманивать кого-то к себе. Мы лишь "даем удочку", а брать её или нет - решать читателю.
Увы, по плюсам к сожалению нет и не будет "серебрянной пули" (единственной книги), по которой можно будет раз и навсегда преисполниться познанием языка. Да и в других языках ситуациях идет ровно к тому же. Языки растут и развиваются, добавляются новые фичи и возможности, которые не уместить в одну книгу.
Спасибо! Мы искренне верим, что кого-то данный материал вдохновит и поможет пройти через тернистый путь изучения языка.
Спасибо! Надеюсь, что вы найдете для себя что-то полезное и интересное!
Это и было фундаментальной основой проекта - собрать воедино актуальную информацию, и предоставить её для тех, кто желает изучить язык, и показать примерный вектор движения.
К сожалению, этого и не хватает многим новичками, т.к. за десятилетия жизни языка было выпущено слишком много книг и прочих материалов спорного качества. В момент выбора, новичок скорее бросит эту затею, т.к. потеряется в обилии информации.
Так что "свалить в кучу" - тоже нужно приложить массу усилий: отфильтровать и отобрать то, что в эту кучу стоит поместить, а что отбросить :)
Опять же, есть добротные курсы по C++, но конкурировать с ними - непосильная задача. Наша работа больше для тех, кто предпочитает самостоятельное обучение.
Технически возможно все, но стоит ли стрелять "из пушки по воробьям"?
Для UI есть более доступные инструменты, на которых можно построить графический интерфейс, но гораздо быстрее/проще/качественнее. Лучше стоять на принципе - каждому инструменты - надлежащее применение. Зачем строить звездолет, когда требуется перетащить пару мешков цемента?
Как с языка сняли! Мы с коллегами долго думали над этим вопросом, стоит ли как-то акцентироваться на тех же UI фреймворках более подробно и т.д.
Но в конце пришли ровно к тому же выводу, что и вы: UI - тема интересная, но сегодня лучше выбирать другие инструменты для их построения: делать UI на плюсах, все равно что из пушки по воробьям стрелять.