Да, с --call-graph dwarf тоже тестировали. На второй картинке правая часть (с неразмеченными функциями и отсутствующими фреймами) как раз собиралась в этом режиме. Подписали для ясности.
Но ведь и для хранения любых других сущностей нужно подбирать контейнер, исходя из конкретного сценария. Хочешь быстро искать — делай маску, хочешь перебирать — массив или всё-таки вектор, если речь о мультимножестве. Так что это больше похоже на выбор между отвёрткой и гаечным ключом, чем на построение велосипеда :)
Сделать хороший курс по плюсам — действительно олимпиадная задачка: нужно удерживать множество факторов в голове, чтоб в итоге подготовить в обозримые сроки уверенного джуниор-разработчика, а не просто знающего плюсы. Мы лавируем между этими условиями, но иногда обходим подводные камни не с первого раза.
Ваш отзыв мы отдельно обсудим с командой и, если вы готовы, вернёмся с вопросами к вам лично, чтобы вместе обсудить, что можно улучшить.
В статье этого нет, в курсе есть.
Есть и ревьюеры, которые принимают все достаточно большие задачи, и отдельная тема про красивый и масштабируемый код.
Ваш комментарий содержит уйму полезных и важных идей.
Про часть из них уверенно скажу, что да, учим. Во второй половине курса есть тема (вот прямо сейчас делаем) про красоту кода, читаемость, масштабируемость и работу с чужим кодом. И одна из задач там — взять чужой сложный код, доработать его под себя и отдать на ревью. Другая задача — взять небольшую чужую библиотеку и приспособить её под нужды своего большого проекта. И тоже отдать на ревью.
Простите за рекламу, но наличие на курсе ревьюеров — это заметное преимущество Практикума перед Курсерой. К слову, я сам в своё время учил C++, проводя ревью студентов :)
Завезли :) Это не в самом-самом начале, но довольно рано.
А при первом знакомстве с вектором показываем, что при выходе за границы вас не поймают за руку — и это плата за эффективность.
Ваши сомнения отчасти оправданы: студентам всё же придётся узнать про new и delete; не только для понимания внутреннего устройства контейнеров, но и для чтения страшного кода.
Но я считаю, что не так всё и страшно, чтобы готовить к этому с самого начала. Гугление может привести как к старому коду, так и к смелому эксперименту с C++23. Поэтому в числе прочего важно научить, скажем, смотреть в нужное место на cppreference вместо рандомных поисковых запросов.
Во-первых, на C++ уже написано очень много кода — тот же Chromium. Или Кликхаус. Ну и разные сервисы в больших компаниях, в которые вам может захотеться поконтрибьютить изнутри. Сюда же можно отнести большое комьюитини и огромное количество библиотек под разные платформы.
Во-вторых, Go стремится к низкому порогу входа, и из-за этого некоторые задачи на нём решаются более многословно. (Но местами Go, безусловно, компактнее.)
Мне пока не кажется, что один язык полностью заменит другой. Скорее, будет как с Java или C#, и каждый займёт свою нишу.
Поглядим лет через 50 :)
Умение объяснить сложную вещь простыми словами всегда в цене.
Другое дело, что про while знают почти все, а вот когда нужно новичку за десять минут объяснить устройство сложной продакшен-архитектуры — тут и аналогия с тортиками подойдёт :)
Пока не пробовали, но в будущем надеемся проверить.
Его сложнее внедрить на масштабе всего кластера. ПБЧ требует всего лишь GDB, который и так доступен в каждом нашем контейнере.
Закрытый исходный код. Когда мы писали ПБЧ, VTune точно требовал лицензию для коммерческого использования.
Нам неизвестно, как с помощью VTune получать разбивку по экспериментам, как с ПБЧ.
Да, с
--call-graph dwarfтоже тестировали. На второй картинке правая часть (с неразмеченными функциями и отсутствующими фреймами) как раз собиралась в этом режиме.Подписали для ясности.
Ага, за последние годы автоинкремента у нас стало на порядок меньше.
Но ведь и для хранения любых других сущностей нужно подбирать контейнер, исходя из конкретного сценария. Хочешь быстро искать — делай маску, хочешь перебирать — массив или всё-таки вектор, если речь о мультимножестве.
Так что это больше похоже на выбор между отвёрткой и гаечным ключом, чем на построение велосипеда :)
Спасибо за фидбек.
Сделать хороший курс по плюсам — действительно олимпиадная задачка: нужно удерживать множество факторов в голове, чтоб в итоге подготовить в обозримые сроки уверенного джуниор-разработчика, а не просто знающего плюсы. Мы лавируем между этими условиями, но иногда обходим подводные камни не с первого раза.
Ваш отзыв мы отдельно обсудим с командой и, если вы готовы, вернёмся с вопросами к вам лично, чтобы вместе обсудить, что можно улучшить.
В статье этого нет, в курсе есть.
Есть и ревьюеры, которые принимают все достаточно большие задачи, и отдельная тема про красивый и масштабируемый код.
Хочешь сделать человеку хорошо? Сделай сначала плохо, а потом верни как было.
Ваш комментарий содержит уйму полезных и важных идей.
Про часть из них уверенно скажу, что да, учим. Во второй половине курса есть тема (вот прямо сейчас делаем) про красоту кода, читаемость, масштабируемость и работу с чужим кодом. И одна из задач там — взять чужой сложный код, доработать его под себя и отдать на ревью. Другая задача — взять небольшую чужую библиотеку и приспособить её под нужды своего большого проекта. И тоже отдать на ревью.
Простите за рекламу, но наличие на курсе ревьюеров — это заметное преимущество Практикума перед Курсерой. К слову, я сам в своё время учил C++, проводя ревью студентов :)
Завезли :) Это не в самом-самом начале, но довольно рано.
А при первом знакомстве с вектором показываем, что при выходе за границы вас не поймают за руку — и это плата за эффективность.
Ваши сомнения отчасти оправданы: студентам всё же придётся узнать про new и delete; не только для понимания внутреннего устройства контейнеров, но и для чтения страшного кода.
Но я считаю, что не так всё и страшно, чтобы готовить к этому с самого начала. Гугление может привести как к старому коду, так и к смелому эксперименту с C++23. Поэтому в числе прочего важно научить, скажем, смотреть в нужное место на cppreference вместо рандомных поисковых запросов.
Это явный баг, поправим.
Спасибо! Доклад правда очень хорош, мы им вдохновлялись ещё при разработке «Белого пояса» на Курсере.
Во-первых, на C++ уже написано очень много кода — тот же Chromium. Или Кликхаус. Ну и разные сервисы в больших компаниях, в которые вам может захотеться поконтрибьютить изнутри. Сюда же можно отнести большое комьюитини и огромное количество библиотек под разные платформы.
Во-вторых, Go стремится к низкому порогу входа, и из-за этого некоторые задачи на нём решаются более многословно. (Но местами Go, безусловно, компактнее.)
Мне пока не кажется, что один язык полностью заменит другой. Скорее, будет как с Java или C#, и каждый займёт свою нишу.
Поглядим лет через 50 :)
Другое дело, что про while знают почти все, а вот когда нужно новичку за десять минут объяснить устройство сложной продакшен-архитектуры — тут и аналогия с тортиками подойдёт :)