В стандартной библиотеке нет ничего, нельзя даже имея готовую 2D картинку в памяти, вывести ее на экран... (и далее)
Можно я задам тупой вопрос: а зачем? Ну, возьмите другой язык, чтобы вывести картинку.
У С++ одна ниша - делать что-то очень-очень быстро. Всё. Если вам нужно выводить 10000 объектов в секунду - вам нужен С++, но я вас уверяю, написание кода по соббсно отрисовки UI будет наименьшей из ваших проблем. В остальных случай возьмите JS, Python, Qt и не парьтесь особо.
Кто из практических программистов пользуется чем-то выходящим за рамки 11-го ну в крайнем случае 14-го стандартов ???
Ну, я пользуюсь вполне С++17 и считаю, что до этого стандарта плюсы довольно-таки гавно и если где-то пишут на С++14 я туда уже не пойду. А я ещё на С++98 успел пописать, т.е. прошёл все итерации стандарта.
Впрочем, С++20 тоже вполне себе неплох. consteval и концепты - очень приятная вещь. Вот С++23 да, чисто косметика, да ещё и не поддерживается нигде.
Будь моя воля, я бы вообще заморозил развитие С++ как языка и сосредоточился исключительно на библиотеках.
Нужно все и сразу - ну возьмите boost. Если уж совсем печально, но есть деньги - возьмите Qt.
Для тех кому нужен высокий уровень абстракции, есть куча куда более вкусных альтернатив.
Всё так и есть. Хочется высокого уровня и не думать о железках - используйте другие языки. Я вот успешно пишут на Python в параллель к плюсам и мне вполне нормально. Rust и Go в принципе тоже ничего.
Год назад работал в месте, где были скрипты на Perl для самописной сборочной системы, написаны они были 7 лет назад одним энтузиастом, и с тех пор почти не изменились, т.к. никто в отделе из 70+ человек больше не знает Perl)
И это было единственное место за последние 10 лет, где я видел Perl)
Не знаю, от возраста сильно не зависит. Вы просто тот 1 из 10 :) Просто одни люди умеют грамотно структурировать мысли, а другие нет.
Тут стоит уточнить, что до тех пор, пока результатом вашей аналитики пользуетесь только вы - вам аналитик и не нужен особо. А вот если надо что-то узнать, оформить в понятный документ и передать его команде - тут как бы всё ОЧЕНЬ плохо у разработчиков)
Мой опыт подсказывает, что только 1 из 10 разработчиков может выполнять роль аналитика. По крайней мере сколь либо сносно. Роль QA разработчики вообще не могут выполнять) Точнее могут конечно, но качество проверки качества будет очень унылым) Особенно если продукт сложный)
Их нет) Хуже того, сейчас по разным компаниям расползлись бывшие руководители Яндекса, и они сокращают аналитиков везде, где появляются. Тестировщиков, кстати, тоже иногда) Мол роль QA и аналитика может и разработчик выполнять. И это почти цитата, на секунду)
Более 95% сообщений об ошибках компилятора С++ выглядят гораздо хуже, чем сообщения об ошибках всех остальных языков.
Тут полностью поддерживаю, но комитет по С++ делает шаги в этом направлении. static_assert и концепты решают часть проблем, по крайней мере в вашем коде) Используйте их, где только можно. Ошибки boost обречены быть ужасными, тут ничего не поделать)
Также рекомендую ChatGPT (и аналоги) для упрощения жизни себе) Эти инструменты реально хорошо расковыривают километровые логи ошибок.
Лучшее, что я до сих пор обнаружил в этой сфере — это сборщик Meson, но и он полон последствий идиотских решений
Я поработал с Meson довольно много (два года использовал его в продакшене) и могу сказать, что лучший - по прежнему громоздкий CMake. К сожалению, документация Meson оставляет желать лучшего, плюс как только нужно сделать что-то за рамками простых сценариев, реализовано из ряда вон плохо. И он жутко медленный (питончик под капотом, что тут ещё добавить). Впрочем, синтаксис его приятный + нативная интеграция с Conan радует.
CMake можно сделать совсем чуточку проще, используя вот этот набор скриптов
Я люто ненавижу RAII. Я встречаюсь с множеством ситуаций, где RAII мешает решать настоящие задачи инициализации сущностей.
Вы не совсем правильно понимаете RAII. Идеологически его определение может и требует передать всё в конструктор, но суть его на самом деле не в создании объекта, а в уничтожении, как бы парадоксально это не звучало.
Суть RAII - это момент вызова деструктора. Объект должен подчищать за собой все ресурсы которыми он завладел при его окончании времени жизни. При этом вам вообще никто не мешает реализовывать паттерны вида строитель, или тупо сделать пустой конструктор и отложенный вызов метода Init(), хоть это концепутально может быть и не очень верно.
При этом количество раз, где RAII даже в изначальном смысле бывает полезен - сильно превышает количество мест где он бесполезен. Для того, чтобы оценить всю прелесть RAII я рекомендую один раз написать что-то на С++, а потом попробовать переписать это на чистый Си :)
Язык чрезвычайно сложен из-за его истории. В С++ имеется масса устаревших конструкций, через которые приходится продираться для того чтобы найти что-то ценное.
Чтобы решить эту проблему, существуют Core Guidelines, и они регулярно обновляются
В сущности это сборник советов "как идеологически правильно писать на С++". Впрочем, на каждый совет там приведены примеры и обоснования, а также случаи, когда в целом можно и не следовать этим правилам.
Вообще, для поддержки всего, что там написано, существует либа GSL
А где есть?) Даже JS не в счёт, там что-то отличное от текста в консоли выводится только в браузере. За пределами браузера ничего нет)
Только в python можно графички повыводить, и в Java вроде чего-то есть, но опять же - не очень-то кроссплатформенно.
В С++ есть Qt. Работает вообще на всех платформах. Есть imgui, тоже работает почти везде и простой. Есть SFML. Всё вполне рабочее.
Можно я задам тупой вопрос: а зачем? Ну, возьмите другой язык, чтобы вывести картинку.
У С++ одна ниша - делать что-то очень-очень быстро. Всё. Если вам нужно выводить 10000 объектов в секунду - вам нужен С++, но я вас уверяю, написание кода по соббсно отрисовки UI будет наименьшей из ваших проблем. В остальных случай возьмите JS, Python, Qt и не парьтесь особо.
Ну, я пользуюсь вполне С++17 и считаю, что до этого стандарта плюсы довольно-таки гавно и если где-то пишут на С++14 я туда уже не пойду. А я ещё на С++98 успел пописать, т.е. прошёл все итерации стандарта.
Впрочем, С++20 тоже вполне себе неплох. consteval и концепты - очень приятная вещь. Вот С++23 да, чисто косметика, да ещё и не поддерживается нигде.
Нужно все и сразу - ну возьмите boost. Если уж совсем печально, но есть деньги - возьмите Qt.
Всё так и есть. Хочется высокого уровня и не думать о железках - используйте другие языки. Я вот успешно пишут на Python в параллель к плюсам и мне вполне нормально. Rust и Go в принципе тоже ничего.
Незаслуженно был забыт любимый многими YoptaScript
Год назад работал в месте, где были скрипты на Perl для самописной сборочной системы, написаны они были 7 лет назад одним энтузиастом, и с тех пор почти не изменились, т.к. никто в отделе из 70+ человек больше не знает Perl)
И это было единственное место за последние 10 лет, где я видел Perl)
Может ли?) Всё что мы знаем, что текущее состояние резистора какое-то, а все предыдущие его состояния - в нашей памяти)
Будем честны: лишь для (очень) немногих людей работа - это источник удовольствия, и не является необходимым условием для выживания)
Впрочем, лучшее, что я смог нагуглить, говорит что большая часть людей более или менее удовлетворена своей работой (почти везде, кроме Африки).
Кроме Яндекса. Эти будут писать каждый месяц минимум :)
Так, ну это всё направда) Рекомендую ознакомиться с тем, чем занимаются аналитики в крупных компаниях, и понять что это мало имеет отношения к коду)
Декомпозиция - это декомпозиция) Совсем другой навык)
Не знаю, от возраста сильно не зависит. Вы просто тот 1 из 10 :) Просто одни люди умеют грамотно структурировать мысли, а другие нет.
Тут стоит уточнить, что до тех пор, пока результатом вашей аналитики пользуетесь только вы - вам аналитик и не нужен особо. А вот если надо что-то узнать, оформить в понятный документ и передать его команде - тут как бы всё ОЧЕНЬ плохо у разработчиков)
Мой опыт подсказывает, что только 1 из 10 разработчиков может выполнять роль аналитика. По крайней мере сколь либо сносно. Роль QA разработчики вообще не могут выполнять) Точнее могут конечно, но качество проверки качества будет очень унылым) Особенно если продукт сложный)
Их нет) Хуже того, сейчас по разным компаниям расползлись бывшие руководители Яндекса, и они сокращают аналитиков везде, где появляются. Тестировщиков, кстати, тоже иногда) Мол роль QA и аналитика может и разработчик выполнять. И это почти цитата, на секунду)
Oracle вроде проиграл суды по этому поводу, нет?
Занятно, но делает их не ядро, хотя наверное они хотели бы)
Я вижу только один минус - я его не знаю) Последний раз я на Фортране что-то писал лет 10 назад) Мне понравилось)
userver? Или чем не устраивают Либы, из списка Communication?
https://en.cppreference.com/w/cpp/links/libs
Впрочем, если есть деньги - есть Qt)
Тут полностью поддерживаю, но комитет по С++ делает шаги в этом направлении.
static_assertи концепты решают часть проблем, по крайней мере в вашем коде) Используйте их, где только можно. Ошибки boost обречены быть ужасными, тут ничего не поделать)Также рекомендую ChatGPT (и аналоги) для упрощения жизни себе) Эти инструменты реально хорошо расковыривают километровые логи ошибок.
Я поработал с Meson довольно много (два года использовал его в продакшене) и могу сказать, что лучший - по прежнему громоздкий CMake. К сожалению, документация Meson оставляет желать лучшего, плюс как только нужно сделать что-то за рамками простых сценариев, реализовано из ряда вон плохо. И он жутко медленный (питончик под капотом, что тут ещё добавить). Впрочем, синтаксис его приятный + нативная интеграция с Conan радует.
CMake можно сделать совсем чуточку проще, используя вот этот набор скриптов
https://github.com/StableCoder/cmake-scripts
Вы не совсем правильно понимаете RAII. Идеологически его определение может и требует передать всё в конструктор, но суть его на самом деле не в создании объекта, а в уничтожении, как бы парадоксально это не звучало.
Суть RAII - это момент вызова деструктора. Объект должен подчищать за собой все ресурсы которыми он завладел при его окончании времени жизни. При этом вам вообще никто не мешает реализовывать паттерны вида строитель, или тупо сделать пустой конструктор и отложенный вызов метода Init(), хоть это концепутально может быть и не очень верно.
При этом количество раз, где RAII даже в изначальном смысле бывает полезен - сильно превышает количество мест где он бесполезен. Для того, чтобы оценить всю прелесть RAII я рекомендую один раз написать что-то на С++, а потом попробовать переписать это на чистый Си :)
Чтобы решить эту проблему, существуют Core Guidelines, и они регулярно обновляются
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
В сущности это сборник советов "как идеологически правильно писать на С++". Впрочем, на каждый совет там приведены примеры и обоснования, а также случаи, когда в целом можно и не следовать этим правилам.
Вообще, для поддержки всего, что там написано, существует либа GSL
https://github.com/microsoft/GSL
Но на практике я не видел, чтобы ей кто-то всерьез пользовался.