Спасибо за подробный ответ! Но один момент непонятен. Следующая практика мне казалась общепринятой: разработчик волен выбирать подходящую ему IDE/редактор (VSCode, Vim, CLion, Sublime, QtCreator, Emacs, Eclipse и т.д.), но настройка любимого IDE дело рук самого разработчика. Если нужно поправить cmake, чтобы любимая IDE работала корректно, то делаешь пул реквест с нужными изменениями. А после ревью и апрува мержишь в мастер/рабочую ветку. У Вас не так? Есть какой-то один человек, который занимается поддержкой кучи IDE?
P.S. С std::format у меня однажды подгорело. Обрадовался, что планируют затащить std::format в стандартную библиотеку C++20. До этого где можно использовал fmtlib. Но чаще убедить коллег перейти на fmtlib не удавалось и приходилось использовать велосипеды разной степени убогости. А тут стандартная реализация fmtlib "из коробки". Красота! Настал час X, обновили gcc и clang до 20-х плюсов (типа), ни один std::format не поддерживает. Через некоторое время обновили снова: в gcc появилась неполная поддержка, в clang — по-прежнему никакой. Да, елки-палки... Ах, да, в Rust format!() есть с релиза 1-ой версии.
Ну, нельзя же так! Имея очень специфическую сферу деятельности, проецировать свой опыт на весь мир. Это не потому что Ваша сфера деятельности плохая. Напротив, звучит круто: R&D, программирование микрокронтроллеров, глубокое погружение в тему. Очевидно, что Ваша работа требует высокой квалификации.
Но. R&D != разработка ПО. Работа c "железом" всего лишь одно из направлений, где используется C++. Сфера применения C++ гораздо шире. Пока ещё. Нелепо приходить из одной сферы в другую со своим представлением о прекрасном. Вас не поймут.
Из того, что Вы написали мне ничего не близко. Но вот, что мешает жить от проекта к проекту (за редким исключением):
Проблемы с архитектурой: 1.1. слабая декомпозиция — огромные функции и god классы; 1.2. чрезмерная декомпозиция — архитектура вся такая гибкая, вот только не там где нужно, а где нужно — негибкая; 1.3. неудачные архитектурные решения — за время существования проекта, требования к нему могут измениться кардинально, и принятые решения, адекватные прежде, становятся помехой.
"Велосипеды" — отчасти из-за того, что некоторые проекты старые, отчасти из-за отсутствия стандартного пакетного менеджера и общего хранилища библиотек в экосистеме C++;
Плохая читабельность кода (говнокод).
И как этому поможет знания C или ассемблера? Никак. Пусть лучше будущий C++ разработчик поглубже изучит язык и почитает книги с полезными советами, как стоит делать, а как делать не надо. (Глядишь и говнокодить не станет.) Вместо изучения C и ассемблера.
P.S. Теперь понятно почему Константин Владимиров с твердой уверенностью заявляет, что std::format не нужен. Возмутительно. При всём уважении к Константину. Но возмутительно.
Это зависит от того, каким вы видите результат. В моём представлении требования к компетентному C++-разработчику включают в себя:
знание отличий C и C++;
умение при необходимости программировать на C в согласии с местными идиомами (привет goto exit;);
умение при необходимости сориентироваться в ассемблерном листинге;
способность при необходимости разобраться, как написать ассемблерную вставку или линкер-скрипт, даже если это нужно всего раз в год.
Извините, но у Вас очень специфические представления о том, что должен знать компетентный C++ разработчик. Предположу, что они искажены предметной областью, которой Вы занимаетесь. Компетентный C++ разработчик должен хорошо знать С++ и его стандартную библиотеку. Это основное. Всё остальное зависит от предметной области. Например:
Бэкенд разработчику могут потребоваться знания реляционных/нереляционных баз данных и очередей, умение настраивать CI/CD, знание скриптового языка (очень популярна связка C++ и Python).
Рендеристу потребуется знания графического API (Metal, OpenGL, DirectX, Vulkan) и алгоритмов компьютерной графики, опыт написания шейдерных программ.
Разработчику десктопных приложений потребуется знания Qt, QML и возможно WinAPI, если целевая ОС — Windows.
Почти всегда есть требование знать примитивы синхронизации и уметь разрабатывать многопоточные приложения. Часто требуется знание CMake. В большинстве мест, где используется C++ знание C не требуется. Обычно знание C требуется для работы с железом или с легаси кодом. Знание ассемблера требуется ещё реже.
Когда-то совместимость с C помогла популяризации C++. Сейчас это наследие тянет C++ вниз, мешает языку развиваться. Бьёрн Страуструп в своей книге The Design and Evolution of C++ написал: “Within C++, there is a much smaller and cleaner language struggling to get out.” Мне бы хотелось, чтобы это произошло. Но часть C++ комьюнити предпочитает оставаться в 90-х, как будто не замечая, что мир сильно изменился :(
Я кросплатформер и сделать новый пустой проект хотя бы под 4 основных айдэе и 3 платформы без проверенного шаблона это день работы и то если у вас есть доступ ко всем этим платформам и айдэе.
У Вас очень интересный кейс! Если не секрет зачем требуется поддержка 4 IDE? Вы пишите плагины для них? И какие целевые платформы используете?
Rust — хорош! Мне нравится :) Однако преимуществом C++ является широкий круг задач, который он решает: игры, бэкенд, работа с железом, десктопные приложения и другое. Мало какой язык может похвастаться таким широким обхватом. (Только C может.) Но не бывает достоинств без недостатков, широкий круг задач делает сложным создание универсального инструмента управления проектами.
Rust пытается заходить во все эти ниши, но, AFAIK, сколько-нибудь заметное распространение получил пока только в бэкенд разработке. Вот Ваши задачи можно решать с помощью Rust'а? Не в теории, а на практике? Есть ли необходимые крейты? Наладить инфраструктуру точно будет проще?
На текущий момент полная поддержка модулей есть только в msvc. В clang ведутся работы, есть продвижение. В gcc всё плохо с модулями. Источник: https://github.com/royjacobson/modules-report
import std;
int main() {
std::println("Hello World");
return 0;
}
Пример, указанный выше можно собрать с помощью msvc. В настройках проекта нужно указать:
C/C++->Language->Build ISO C++23 C/C++->Language->Enable Experimental C++ Standard Library Modules->/std:c++latest C/C++->Language->Build ISO C++23 Standard Library Modules->Yes
P.S. Не разбирался как это сделать с помощью CMake. Но вроде как поддержка модулей включена в CMake, начиная с версии 3.28.
Чтобы воспроизвести эксперименты под виндой, достаточно будет запустить /контейнер с GCC.
Можно поставить WSL2, накатить на него Ubuntu и запускать код прямо из MS Visual Studio. Для человека незнакомого с Linux, это наиболее безболезненный способ. ИМХО.
20 лет назад это утверждение было бы верным. Но за это время Windows сильно сдала позиции в нашей стране. Плюс текущая ситуация не располагает к распостранению Windows и решений от MS.
Как раз недавно поменял работу, активно смотрел вакансии C++ разработчика. По субъективным ощущениям вакансий Linux + кроссплатформа (Linux/Windows/macOS) больше чем просто Windows.
Подача материала в exercism.org и senjun.ru сильно отличаются. В exercism.org подача идет от задачи. Есть задача и рядом идёт немного теории. При этом описание задачи по объёму сопоставимо с теорией.
senjun.ru это скорее онлайн книга, текст которой содержит задачи. Книга разбита на главы. Главы выглядят примерно так: параграф с теорией, далее пример и пояснение к нему, за примером следует задача, снова параграф с теорией, пример, задача и тд. Всё это выполнено как единое повествование. Основная идея в том, чтобы человек изучал материал, попутно решая задачи, минимально отвлекаясь на посторонние вопросы.
-------
P.S. Личное мнение. В exercism.org мне не понравились перегруженный интерфейс и геймификация. После первой задачи "Hello world!" растерялся и не сразу понял куда идти дальше. На второй задаче застрял пока не понял, что в третьей функции нужно вернуть сумму preparationTime(numberOfLayers) + actualMinutesInOven, а не preparationTime(numberOfLayers) + remainingOvenTime(actualMinutesInOven). Подача материала показалась 'водянистой'. Сайт покинул в раздраженном состоянии. Не моё.
Разработчик рано или поздно приходит к одному факту, что код приходится чаще читать, чем писать. Даже если тебе везет, и ты переходишь от одного нового проекта к другому, то всё равно потребуется смотреть чужой код: на code review, исходники используемых библиотек. Но гораздо чаще приходишь в проект, который существует уже не первый год, и в нём тонна кода, в которой придется разбираться. Как это делать без знания языка? На мой взгляд никак.
Есть одна особенность, которая мне очень не нравится в современной застройке. Начиная с какого-то момента новые дома строятся с закрытой придворовой территорией. Это может быть двор огороженный группой домов либо просто забор вокруг дома.
Лет двадцать назад я проживал в Хорошево-Мневники в микрорайоне полностью застроенным «хрущевками». Так себе жильё, но район был зеленым, было где погулять по окрестностям. Сейчас большинство «хрущевок» снесли и на их месте возвели человейники. Некоторые человейники выглядят симпатично, вокруг них есть небольшая красиво благоустроенная и закрытая территория. Но гулять стало негде (только если ты не любитель гулять вдоль заборов). Всё ранее доступное для прогулок пространство отъели закрытые придворовые территории. На мой взгляд возможность погулять вокруг дома стала актуальнее из-за пандемии ковида. А большинство новостроек такой возможности лишены.
Формула [2] требует меньше вычислений, т.к. расчет двух первых потомков это два select'а, а вычисление первого и последнего потомков это два select'а + rank. При этом формула [1] — универсальна, а у формулы [2] есть ограничение, узел должен быть не последним на своем уровне дерева:
Но допустим, у узла i существует соседний узел i+1, который располагается на том же уровне дерева, что и i.
Как понять, что выбранный узел не является последним на уровне дерева?
P.S. В статье в формуле [1] опечатка childrenCount(i) = lastChild(i + 1) — firstChild(i) + 1, полагаю должно быть lastChild(i).
Спасибо за подробный ответ! Но один момент непонятен. Следующая практика мне казалась общепринятой: разработчик волен выбирать подходящую ему IDE/редактор (VSCode, Vim, CLion, Sublime, QtCreator, Emacs, Eclipse и т.д.), но настройка любимого IDE дело рук самого разработчика. Если нужно поправить cmake, чтобы любимая IDE работала корректно, то делаешь пул реквест с нужными изменениями. А после ревью и апрува мержишь в мастер/рабочую ветку. У Вас не так? Есть какой-то один человек, который занимается поддержкой кучи IDE?
P.S. С std::format у меня однажды подгорело. Обрадовался, что планируют затащить std::format в стандартную библиотеку C++20. До этого где можно использовал fmtlib. Но чаще убедить коллег перейти на fmtlib не удавалось и приходилось использовать велосипеды разной степени убогости. А тут стандартная реализация fmtlib "из коробки". Красота! Настал час X, обновили gcc и clang до 20-х плюсов (типа), ни один std::format не поддерживает. Через некоторое время обновили снова: в gcc появилась неполная поддержка, в clang — по-прежнему никакой. Да, елки-палки... Ах, да, в Rust format!() есть с релиза 1-ой версии.
Ну, нельзя же так! Имея очень специфическую сферу деятельности, проецировать свой опыт на весь мир. Это не потому что Ваша сфера деятельности плохая. Напротив, звучит круто: R&D, программирование микрокронтроллеров, глубокое погружение в тему. Очевидно, что Ваша работа требует высокой квалификации.
Но. R&D != разработка ПО. Работа c "железом" всего лишь одно из направлений, где используется C++. Сфера применения C++ гораздо шире. Пока ещё. Нелепо приходить из одной сферы в другую со своим представлением о прекрасном. Вас не поймут.
Из того, что Вы написали мне ничего не близко. Но вот, что мешает жить от проекта к проекту (за редким исключением):
Проблемы с архитектурой:
1.1. слабая декомпозиция — огромные функции и god классы;
1.2. чрезмерная декомпозиция — архитектура вся такая гибкая, вот только не там где нужно, а где нужно — негибкая;
1.3. неудачные архитектурные решения — за время существования проекта, требования к нему могут измениться кардинально, и принятые решения, адекватные прежде, становятся помехой.
"Велосипеды" — отчасти из-за того, что некоторые проекты старые, отчасти из-за отсутствия стандартного пакетного менеджера и общего хранилища библиотек в экосистеме C++;
Плохая читабельность кода (говнокод).
И как этому поможет знания C или ассемблера? Никак. Пусть лучше будущий C++ разработчик поглубже изучит язык и почитает книги с полезными советами, как стоит делать, а как делать не надо. (Глядишь и говнокодить не станет.) Вместо изучения C и ассемблера.
P.S. Теперь понятно почему Константин Владимиров с твердой уверенностью заявляет, что std::format не нужен. Возмутительно. При всём уважении к Константину. Но возмутительно.
Извините, но у Вас очень специфические представления о том, что должен знать компетентный C++ разработчик. Предположу, что они искажены предметной областью, которой Вы занимаетесь. Компетентный C++ разработчик должен хорошо знать С++ и его стандартную библиотеку. Это основное. Всё остальное зависит от предметной области. Например:
Бэкенд разработчику могут потребоваться знания реляционных/нереляционных баз данных и очередей, умение настраивать CI/CD, знание скриптового языка (очень популярна связка C++ и Python).
Рендеристу потребуется знания графического API (Metal, OpenGL, DirectX, Vulkan) и алгоритмов компьютерной графики, опыт написания шейдерных программ.
Разработчику десктопных приложений потребуется знания Qt, QML и возможно WinAPI, если целевая ОС — Windows.
Почти всегда есть требование знать примитивы синхронизации и уметь разрабатывать многопоточные приложения. Часто требуется знание CMake. В большинстве мест, где используется C++ знание C не требуется. Обычно знание C требуется для работы с железом или с легаси кодом. Знание ассемблера требуется ещё реже.
Когда-то совместимость с C помогла популяризации C++. Сейчас это наследие тянет C++ вниз, мешает языку развиваться. Бьёрн Страуструп в своей книге The Design and Evolution of C++ написал: “Within C++, there is a much smaller and cleaner language struggling to get out.” Мне бы хотелось, чтобы это произошло. Но часть C++ комьюнити предпочитает оставаться в 90-х, как будто не замечая, что мир сильно изменился :(
У Вас очень интересный кейс! Если не секрет зачем требуется поддержка 4 IDE? Вы пишите плагины для них? И какие целевые платформы используете?
Rust — хорош! Мне нравится :) Однако преимуществом C++ является широкий круг задач, который он решает: игры, бэкенд, работа с железом, десктопные приложения и другое. Мало какой язык может похвастаться таким широким обхватом. (Только C может.) Но не бывает достоинств без недостатков, широкий круг задач делает сложным создание универсального инструмента управления проектами.
Rust пытается заходить во все эти ниши, но, AFAIK, сколько-нибудь заметное распространение получил пока только в бэкенд разработке. Вот Ваши задачи можно решать с помощью Rust'а? Не в теории, а на практике? Есть ли необходимые крейты? Наладить инфраструктуру точно будет проще?
На текущий момент полная поддержка модулей есть только в msvc. В clang ведутся работы, есть продвижение. В gcc всё плохо с модулями. Источник:
https://github.com/royjacobson/modules-report
Пример, указанный выше можно собрать с помощью msvc. В настройках проекта нужно указать:
P.S. Не разбирался как это сделать с помощью CMake. Но вроде как поддержка модулей включена в CMake, начиная с версии 3.28.
Можно поставить WSL2, накатить на него Ubuntu и запускать код прямо из MS Visual Studio. Для человека незнакомого с Linux, это наиболее безболезненный способ. ИМХО.
20 лет назад это утверждение было бы верным. Но за это время Windows сильно сдала позиции в нашей стране. Плюс текущая ситуация не располагает к распостранению Windows и решений от MS.
Как раз недавно поменял работу, активно смотрел вакансии C++ разработчика. По субъективным ощущениям вакансий Linux + кроссплатформа (Linux/Windows/macOS) больше чем просто Windows.
Подача материала в exercism.org и senjun.ru сильно отличаются. В exercism.org подача идет от задачи. Есть задача и рядом идёт немного теории. При этом описание задачи по объёму сопоставимо с теорией.
senjun.ru это скорее онлайн книга, текст которой содержит задачи. Книга разбита на главы. Главы выглядят примерно так: параграф с теорией, далее пример и пояснение к нему, за примером следует задача, снова параграф с теорией, пример, задача и тд. Всё это выполнено как единое повествование. Основная идея в том, чтобы человек изучал материал, попутно решая задачи, минимально отвлекаясь на посторонние вопросы.
-------
P.S. Личное мнение. В exercism.org мне не понравились перегруженный интерфейс и геймификация. После первой задачи "Hello world!" растерялся и не сразу понял куда идти дальше. На второй задаче застрял пока не понял, что в третьей функции нужно вернуть сумму preparationTime(numberOfLayers) + actualMinutesInOven, а не preparationTime(numberOfLayers) + remainingOvenTime(actualMinutesInOven). Подача материала показалась 'водянистой'. Сайт покинул в раздраженном состоянии. Не моё.
Разработчик рано или поздно приходит к одному факту, что код приходится чаще читать, чем писать. Даже если тебе везет, и ты переходишь от одного нового проекта к другому, то всё равно потребуется смотреть чужой код: на code review, исходники используемых библиотек. Но гораздо чаще приходишь в проект, который существует уже не первый год, и в нём тонна кода, в которой придется разбираться. Как это делать без знания языка? На мой взгляд никак.
Информация об инфраструктурных объектах берется из OSM. Данные в OSM вносят участники сообщества. Стать участником сообщества может любой человек.
Лет двадцать назад я проживал в Хорошево-Мневники в микрорайоне полностью застроенным «хрущевками». Так себе жильё, но район был зеленым, было где погулять по окрестностям. Сейчас большинство «хрущевок» снесли и на их месте возвели человейники. Некоторые человейники выглядят симпатично, вокруг них есть небольшая красиво благоустроенная и закрытая территория. Но гулять стало негде (только если ты не любитель гулять вдоль заборов). Всё ранее доступное для прогулок пространство отъели закрытые придворовые территории. На мой взгляд возможность погулять вокруг дома стала актуальнее из-за пандемии ковида. А большинство новостроек такой возможности лишены.
Есть вопрос. В разделе «Количество потомков» приведено две формулы:
[1] childrenCount(i) = lastChild(i) — firstChild(i) + 1
[2] childrenCount(i) = firstChild(i + 1) — firstChild(i)
Формула [2] требует меньше вычислений, т.к. расчет двух первых потомков это два select'а, а вычисление первого и последнего потомков это два select'а + rank. При этом формула [1] — универсальна, а у формулы [2] есть ограничение, узел должен быть не последним на своем уровне дерева:
Но допустим, у узла i существует соседний узел i+1, который располагается на том же уровне дерева, что и i.
Как понять, что выбранный узел не является последним на уровне дерева?
P.S. В статье в формуле [1] опечатка childrenCount(i) = lastChild(i + 1) — firstChild(i) + 1, полагаю должно быть lastChild(i).