Comments 215
У меня на ладони лежит очень горячий сотовый телефон, который разогрелся из‑за того, что мессенджер отображает статичное сообщение с пузырем и текстом на экране при помощи браузерного движка и безумного количества сторонних библиотек.
А много вы видели мобильных приложений на С++??????
Хоть и я тоже считаю, что стандарты С++, это тот еще геморрой, но C++ обеспечивает обратную совместимость, поэтому комитет совершенно прав, что очень осторожно подходит к удалению устаревших конструкций.
И проблема с постоянным усложнением ПО никак не зависит комитета по стандартизации С++. Скорее наоборот, он, что называется, "в тренде" и вынужден добавлять новые возможности, чтобы угнаться за постоянным появлением новых подходов при разработке ПО.
В MeeGo были мобильные приложения на C++, на одноядерном процессоре с частотой 1 ГГц просто летали, и камера очень отзывчивая была. Сейчас тоже можно создавать на C++/Qt, например, под Android, но прослойка в виде JVM присутствует, ощущения очень высокой скорости работы нет. Хотя приложение 2ГИС довольно долго именно так и работало вроде как, не знаю сейчас изменилось ли что-то
Порядочно. Например, и Unity и Unreal написаны на С++, и на том и на другом много мобильных игр. Да и браузер на моем телефоне тоже написан на С++.
На самом деле, нет никакой реальной проблемы с выбрасыванием старья и ломкой совместимости. Зачем тянуть совместимость со старьём в новые версии стандарта? Транслируйте программу, написанную на C++93, в соответствующем режиме компилятора, и очистите современный язык от всякого хлама в новых версиях.
На самом деле, впечатление такое, что комитет по стандартизации старается впихнуть в язык как можно больше фишек, причём как можно более извращёнными способами, а реальные проблемы не только не решает, но ещё временами и усугубляет. Особенно это касается UB: в 95% случаев поведение вполне себе определённое, но, поскольку его не желают объявить таковым, компилятор волен творить любую дичь. Например, почему не убрать UB из случая переполнения целочисленной переменной со знаком? На любой платформе, использующей для представления целых чисел дополнительный код (а сколько-нибудь современные платформы все такие), самое большое положительное число переходит в самое большое отрицательное, и наоборот, и правила перехода одного в другое совершенно чётко определены логикой операций сложения/вычитания на уровне "железа". Единственный вопрос: будет ли исключение при переполнении? Так запросто можно и нужно стандартизировать, и самый лучший вариант -- определить, что это зависит от стандартной прагмы: если включено, компилятор обязан обнаруживать переполнение и кидать исключение, а если выключено -- просто позволить процессору формировать значение, как он это всегда и делает.
То же самое касается и нулевых указателей, и выходов за границу массива, и т.д.: никакого UB с точки зрения языка (компилятора) там быть не должно. Если обращение по нулевому указателю -- выполняй обращение по адресу 0, и всё, остальное -- не твоё дело. Если выход за границы массива -- вычисляй адрес, как обычно вычисляешь, и выполняй обращение, и не твоё дело, что при этом произойдёт. А заодно следовало бы добавить стандартные прагмы, управляющие обнаружением таких случаев во время выполнения: если они включены -- компилятор должен генерировать код, обеспечивающий обнаружение и выдачу исключений, если выключен -- не обнаруживать эти случаи и дать программе работать, как она работает.
Зачем тянуть совместимость со старьём в новые версии стандарта?
Потому что в не всегда есть возможность "транслировать" программу по множеству различных причин (нет исходников, другой компилятор, нет поддержи оборудования и т.д.), и поэтому единственным действительно работающим случаем обеспечить обратную совместимость, это гарантировать её на уровне стандартов языка.
Например, почему не убрать UB из случая переполнения целочисленной переменной со знаком?
Из-за обеспечения обратной совместимости. И это действительно проблема, ведь нельзя ломать стандартное поведение, так как стандарт работает в обе стороны :-(.
Так запросто можно и нужно стандартизировать, и самый лучший вариант -- определить, что это зависит от стандартной прагмы ...
Примерно это и предлагается сейчас сделать в виде профилей безопасности или даже без принятия нового стандарта
и поэтому единственным действительно работающим случаем обеспечить обратную совместимость, это гарантировать её на уровне стандартов языка.
Хорошо, что в Фортране об этом не знают. А то б до сих пор пришлось писать программы с 7 позиции и разрешать переход внутрь цикла с помощью goto.
На самом деле, транслятору достаточно просто понимать, на какой версии стандарта написан каждый отдельно взятый модуль... хотя в C++ же повсюду напиханы инклюды, превращающие модульную структуру в спагетти... ну бог его знает, как из этого тупика выходить.
Потому что в не всегда есть возможность "транслировать" программу по множеству различных причин (нет исходников, другой компилятор, нет поддержи оборудования и т.д.), и поэтому единственным действительно работающим случаем обеспечить обратную совместимость, это гарантировать её на уровне стандартов языка
Если программу нет возможности транслировать, значит, совместимость на уровне языка уже абсолютно безразлична, поскольку на этом уровне она использована быть не может. Ну а совместимость на уровне соглашений о связях (правила передачи параметров и т.п.) к собственно языку программирования прямого отношения не имеют и вполне могут быть одинаковыми для совершенно разных языков (не говоря уж о возможности написать, если припрёт, небольшие переходники-"прокладки" на ассемблере).
Из-за обеспечения обратной совместимости
Новому коду она не нужна, а старый код можно транслировать старыми версиями. Для возможности вызова одного из другого достаточно соблюдать низкоуровневые соглашения о связях, что к языку вообще, по большому счёту, не привязано, о чём я сказал выше.
На любой платформе, использующей для представления целых чисел дополнительный код (а сколько-нибудь современные платформы все такие), самое большое положительное число переходит в самое большое отрицательное, и наоборот
Вполне себе современные DSP смотрят на вас с недоумением. Кстати, арифметика с насыщением весьма уязвима к потенциальному переупорядочиванию операций компилятором. Например, компилятор имеет право изменять порядок операций типа a + b + c, и разные компиляторы действительно выполняют это сложение в разном порядке. Вы, думаю, в курсе, но для остальных напомню, что оба компилятора используют стандартную для x86-64 calling convention, где для передачи параметров типа INTEGER используются регистры rdi, rsi, rdx и rcx по порядку, т.е. gcc производит сложение как ((a + b) + c) + d), а clang - как (a + b) + (c + d). Так вот, предположим в нашем гипотетическом примере с a + b + c, что a == INT_MAX, b == INT_MAX, а c == INT_MIN. Тогда, если сложение будет производиться компилятором в порядке (a + b) + c, то результатом будет -1, а если оно будет производиться в порядке a + (b + c), то результатом будет INT_MAX - 1.
Справедливое замечание, но на это можно заметить, что переупорядочивание операций - вообще зло и самостоятельная причина для критики C/C++.
переупорядочивание операций - вообще зло
Ну это вы так думаете. Я бы настолько категорично на эту тему не высказывался, но я - это я, а вы - это вы.
В стандарте C++, между прочим, насколько я помню, написано, что переупорядочивание допускается только в том случае, когда не может повлиять на результат выражения. Правда, для меня всегда было загадочно, как компилятор должен был бы, по замыслу авторов, это проверять.
Ну скажем так на cppreference этот момент формулируется следующим образом:
When signed integer arithmetic operation overflows (the result does not fit in the result type), the behavior is undefined, — the possible manifestations of such an operation include:
it wraps around according to the rules of the representation (typically two's complement),
it traps — on some platforms or due to compiler options (e.g. -ftrapv in GCC and Clang),
it saturates to minimal or maximal value (on many DSPs),
it is completely optimized out by the compiler.
то есть, вообще говоря, знаковое переполнение (даже если оно завершается сатурацией) - это UB, а компилятор, как известно, имеет право выполнять любые оптимизации в расчете на то, что UB не происходит. К слову, у TI-евских DSP есть ассоциативные интринсики (например, _a_sadd - ассоциативное сложение с насыщением), так вот, их тоже нужно применять с осторожностью, т.к. компилятор их будет переупорядочивать при необходимости.
так вот, их тоже нужно применять с осторожностью, т.к. компилятор их будет переупорядочивать при необходимости.
Ну там уже только при твёрдом знании, что результат не изменится.
А вот и нет. Открываем TI-евский "Optimizing C/C++ Compiler User’s Guide" и читаем:
The compiler supports associative versions for some of the addition and multiply-and-accumulate intrinsics. These associative intrinsics are prefixed with “_a_”. The compiler is able to reorder arithmetic computations involving associative intrinsics, which may produce more efficient code.
[...]
However, this reordering may affect the value of the expression if saturation occurs at different points in the new ordering. [...] A rule of thumb is that if all your data have the same sign, you may safely use associative intrinsics.
То есть с одной стороны код будет лучше оптимизироваться компилятором, а с другой погромист должен сам думать, с какими данными эти ассоциативные интринсики можно применять, а с какими нет.
Это не зло, когда оно не вредит. И зло, когда вредит. Я понимаю, что это тавтология типа "надо делать хорошо и не надо делать плохо", но в конкретном случае это подсказывает, что программист может и должен указать компилятору, когда он имеет право делать оптимизации конкретного вида, а когда нет.
Местами это делается, например, вспомним C# с его checked и unchecked блоками, включая части выражений. Или намеренно возьмём древнейший пример - COBOL с ON SIZE ERROR. Но желательно было бы расширить это на все основные проблемы. Например, где-то в ядре можно считать, что разыменование NULL это законная операция для доступа к чему-то по физическому адресу 0. И эти куски надо соответственно помечать. Аналогично для переполнений в целых числах, порядка вычисления аргументов функций, и так далее.
С вашей аргументацией сложно поспорить в принципе. Но в частности мы видим на примере Фортрана, где порядок вычисления выражения строго фиксирован, что это не оказывает различимого негативного влияния на оптимизацию. Компилятор C++, переупорядочивающий операции, на практике не порождает более эффективный код для вычисления выражений, чем компилятор Фортрана, не переупорядочивающий. Скажу более, если бы переупорядочивание операций позволило выиграть на практике хоть десятую долю процента эффективности реальных вычислительных программ, то оно было бы разрешено в Фортране. Таким образом, позитива нет. А негативные последствия такого решения очевидны.
Вполне себе современные DSP смотрят на вас с недоумением. Кстати, арифметика с насыщением весьма уязвима к потенциальному переупорядочиванию операций компилятором.
DSP -- весьма специфическая ниша, и ориентироваться на неё в универсальном языке... Ну, такое себе. Если так уж хочется реализовать в нём те же операции с насыщением, правильней, как по мне, делать специальные типы данных для подобных целей, а не пытаться всё вогнать в один и тот же int. Тогда можно будет наиболее естественным образом и обычную арифметику считать, и всякие специальные виды -- и всё это безо всяких UB.
На самом деле, нет никакой реальной проблемы с выбрасыванием старья и ломкой совместимости
Как показывает опыт перехода python2 => python3 проблема таки есть. Сообщество оказалось под угрозой раскола на много лет. При этом у python слом совместимости был тепличным:
несовместимость касалась небольшого подмножества языка, при этом был даже почти рабочий инструмент миграции. По большому счёту было одно действительно больное место - работа со строками
в python не было такого зоопарка сторонних библиотек
в python по сути одна референсная реализация (cpython)
При всём этом переход на python3 оказался растянут почти на 10 лет. Даже сейчас есть живые кодовые базы на python2, и это больно
Проблема совместимости версий python создана соврешенно искусственно, и, можно сказать, умышленно. Не было никакой причины делать это именно так. Ну и "почти работающий" инструмент миграции это все равно что "пациент почти жив".
Но особенно больно на python потому, что это интерпретируемый язык.
Проблема python возникла, потому что вопрос совместимости никто серьёзно не решал.
В Фортране вопрос совместимости решали, и никакой проблемы совместимости нет. Я сейчас совершенно спокойно могу включать в свои фортрановские программы модули из тех времён, когда не только C++, но и C ещё не было, и всё будет работать. Хотя язык изменился за это время до неузнаваемости.
А много вы видели мобильных приложений на С++??????
Под Symbian или Windows Mobile большинство приложений было на C++
ИМХО нужно добавить таг - "наброс на вентилятор".
А какое отношение имеют прикладные библиотеки к, собственно, языку? Сейчас вот в моде нейросети - их тоже надо срочно тянуть в стандарт языка?
Ну в питоне затянули же.
Кто затянул и куда? В стандарте (считаем CPython стандартом) такого нет.
Есть вендоры и есть очень популярное применение. Не менее и не более того.
Давайте не цепляться к терминологии, а смотреть на вопрос по существу. Питоновские программы рассчитаны на работу с репозиторием PyPl, и никак иначе. Практически ни одна реально используемая программа на Питоне не будет работать без PyPl. Это в большей степени неотъемлемый элемент языка, чем, скажем, редко используемые операторы вроде nonlocal или pass.
Питоновские программы рассчитаны на работу с репозиторием PyPl, и никак иначе. Практически ни одна реально используемая программа на Питоне не будет работать без PyPl.
Нет, это фактически неверно. Есть и поставки в виде системных пакетов, и в готовом крупноблочном виде, как Conda, и альтернативные менеджеры. То, что pip + PyPI используется большинством сейчас, факт текущего времени и не больше. При этом локальных менеджеров уже несколько соревнующихся: есть virtualenv, есть venv, есть pipenv, и это только те, что я с ходу вспомнил.
Это в большей степени неотъемлемый элемент языка
Нет.
Локальный менеджер никак не отменяет использование пакетов из PyPl. Под этим я не подразумеваю, разумеется, что компьютер должен быть обязательно подключен к интернету и выкачивать оттуда пакеты. Я имею в виду, что PyPl является первоисточником неотъемлемых частей реальной питоновской программы, выполняя такую же функцию, как системная библиотека C++. А то, что вы модули из PyPl можете распространять вместе со своей программой – так и слава богу.
Я имею в виду, что PyPl является первоисточником неотъемлемых частей реальной питоновской программы, выполняя такую же функцию, как системная библиотека C++.
Нет. "Такую же функцию, как системная библиотека C++" в питончике выполняет Python Standard Library (кстати, с кучей платформозависимых оговорок, см. раздел Notes on availability). А PyPl - это пакетный менеджер, его аналогами в C++ являются vcpkg, conan и тому подобное.
Индекс пакетов Python (PyPI) - это хранилище программного обеспечения для языка программирования Python.
PSL – это маленькая и совершенно недостаточная для практического программирования часть библиотеки.
Ну да, как я и написал - пакетный менеджер. Использование PyPl в питончике для того, чтобы подключить какой-нибудь PyTorch - это нормально, а использование vcpkg в C++ для того чтобы подключить тот же libtorch - это ужас-ужас, я правильно понимаю?
PyPl – это репозиторий программного обеспечения. Доступ его содержимому является штатной и фактически неотъемлемой частью Питона. Чего не скажешь про vcpkg и libtorch.
И даже если согласиться с вами, что vcpkg – это то же самое, что PyPl, то в vcpkg 2500 пакетов, а в PyPl – 600000. Это не просто количественное, а уже качественное различие.
PyPl – это репозиторий программного обеспечения. Доступ его содержимому является штатной и фактически неотъемлемой частью Питона.
Вполне себе отъемлемой. Впрочем, не вижу смысла повторяться, @netch80 уже ниже все расписал.
то в vcpkg 2500 пакетов, а в PyPl – 600000. Это не просто количественное, а уже качественное различие.
Вот бы узнать, какой процент среди этих 600000 пакетов составляют разнообразные лефтпады. Впрочем, суть не в этом, а в том, что ваше утверждение, что "нейросети затащили в стандарт питона" просто-напросто ложно.
Я имею в виду, что PyPl является первоисточником неотъемлемых частей реальной питоновской программы, выполняя такую же функцию, как системная библиотека C++.
И снова - нет. Аналогом системной библиотеки C++ является стандартная библиотека Python, которая весьма обширна и присутствует вместе с интерпретатором. Остальное - подключаемые модули уже по заказу. И вот их можно поставлять разными путями. Поставка в рамках дистрибутива 100% опирается на модули, уложенные в дистрибутив в виде rpm, dpkg и прочих. На pip (если на него) опирается только собираемое за пределами стандартного корня в отдельных окружениях.
Именно вариант в окружениях в основном использует pip, это верно. При этом то, что входит в стандартную библиотеку интерпретатора, вообще не исключается, а добавленное дистрибутивом - можно добавить через ключ --system-site-packages у venv и аналоги у прочих.
Но, как уже сказал, это не единственный вариант даже для своих окружений.
Я вообще ни слова ни говорю о том, как можно поставлять модули. Это неважно. Я говорю о том, что любая реально значимая программа на Питоне подразумевает использование модулей из PyPl. Если угодно, то сам Питон – это просто клей для модулей из PyPl.
любая реально значимая программа на Питоне подразумевает использование модулей из PyPl.
Каким именно образом она, по-вашему, это "подразумевает"?
Я вообще ни слова ни говорю о том, как можно поставлять модули.
Именно про это вы и говорите. Нет "модулей из PyPI". Есть модули от их авторов, версии которых поставляются, в числе прочих мест, из PyPI - и там просто удобнее всего по умолчанию их брать. Само это по себе никак не делает их "модулями из PyPI", это модули от авторов. Вы можете брать их напрямую (как делают майнтейнеры дистрибутивов Linux) или через другой менеджер, как вам угодно.
Если угодно, то сам Питон – это просто клей для модулей из PyPl.
Нет, не угодно, потому что это уже просто чушь.
Каким именно образом она, по-вашему, это "подразумевает"?
Тем, что в её тексте прописан импорт модулей, по умолчанию находящихся в PyPl.
Есть модули от их авторов, версии которых поставляются, в числе прочих мест, из PyPI - и там просто удобнее всего по умолчанию их брать. Само это по себе никак не делает их "модулями из PyPI", это модули от авторов.
Так даже и про libc++ можно сказать. Это софистика.
Тем, что в её тексте прописан импорт модулей, по умолчанию находящихся в PyPl.
Покажите версию Python, в которой есть такое умолчание.
В CPython, PyPy, с которыми я работал, модули берутся из файловой системы, по пути, зависящему от расположения и режима сборки интерпретатора. Если вы работали с чем-то особо странным, которое само умеет при старте тянуть модули из сети, назовите его, но это в любом случае будет не то, что работает у большинства.
Так даже и про libc++ можно сказать.
Нельзя, libc++ - аналог стандартной библиотеки из поставки интерпретатора.
Это софистика.
Аж никак.
Какие прикладные библиотеки?
Я пишу о библиотеках ввода-вывода.
Сейчас в С++ есть ввод-вывод в файл и на консоль. Консоль - это современный способ ввода-вывода в мейнстриме?
А какой там единственно верный способ вывода графики? DirectDraw? DirectX? OpenGL? OpenVG? Vulcan?
А какой там единственно верный способ вывода буковок в консоль? Curses? Borland TurboVision? printf? cout? Notcurses?
Вы забыли еще eдинственно верные Metal, WebGPU, GNM/GNMX и NVN
Стандарт на графическую библиотеку может просто объявить API для отрисовки базовых примитивов, например взять за основу Qt-шные виджеты. А уже самой отрисовкой могут заниматься разные движки под капотом, на основе DirectDraw, DirectX, OpenGL, OpenVG, Vulcan.
Но сеть по-моему можно и нужно сделать раньше.
Это не движки а разные API с разными возможностями и ограничениями. Вы же предлагаете сделать ещё один единственно верный API, который будет поддерживать все возможные фичи видеокарт.
Зачем все возможные фичи? Нет конечно. Только базовые, чтобы текст рисовать, линии, прямоугольники закрашивать, кнопы, чекбоксики и т.п. В Qt есть виджеты, а есть разные движки для рендеринга.
Вот здесь красиво описано
https://doc.qt.io/qt-6/topics-graphics.html
Вы предлагаете весь QT перенести в STD? Любители GTK будут очень рады.
Включение Qt в std никак не помешает использовать GTK.
Вы предлагаете весь QT перенести в STD? Любители GTK будут очень рады.
Любители GTK пусть идут в комитет стандартизации C или кто там сейчас сишечкой занимается?
Qt это библиотека C++. Но в принципе за C++ API может скрываться и движок GTK, почему бы и нет? Такой пример есть, смотри например gtkmm - тоже можно взять за основу.
Есть и другие графические C++ библиотеки, но Qt как основа вполне ничего. Совместимость с Qt не нужна, поэтом проблем не возникнет.
Весь Qt портировать конечно не надо, только виджеты. При этом надо ещё выкинуть QString и прочие Qt-шные контейнеры, заменив их стандартными контейнерами. А qt-шные сигналы заменить сигналами на темплейтах из того же буста, например, или из gtkmm.
Никто не предлагает сдлать "единственно верный API", стандартная библиотека не является и никогда не являлась "единственно верным API". Цель стандартизации библиотек не в том, чтобы предоставить что-то "единственно верное", цель в том, чтобы обеспечить базис, на основе которого прикладные программы могут работать на различных платформах. Например, в той же Windows есть замечательный набор API вызовов для асинхронной работы с файлами, и существование стандартной библиотеки ввода-вывыода никак не мешает существованию этого API. Никакого вреда от существования стандартного API работы с файлами при этом нет, только польза: если возможностей, предоставляемых стандартной библиотекой, достаточно, то программа, использующая только стандартную библиотеку великолепно работает и под Windows и под Linux и под MacOS.
Речи о поддержке фичей видеокарт вообще не идет. Сейчас стандартная библиотека С++ не позволяет вообще никак работать с большей частью способов ввода-вывода современных компьютеров.
Поддерживается:
- консоль
- файлы
Надеюсь, скоро будет поддерживаться:
- сеть
Очень хочу чтобы наконец стали поддерживаться:
- вывод на экран изображений как массива цветов пикселов
- создание окон графического интерфейса
- получение координат и кликов от мышки, тычков от touch интерфейса
- получение осей и состояний кнопок от иных видов контроллеров
- вывод звука
- ввод звука
- ввод изображений
- ввод видео
Это самый базовый уровень для наиболее распространенных способов ввода-вывода, который позволил бы полноценно использовать самые базовые возможности современных компьютеров.
Жду не дождусь, когда в стандартной библиотеке C++ появится JSX - вот тогда-то заживём.
Если вы не в курсе, то гонять массив пикселов между оперативной и видео памятью на каждый чих - очень ресурсоёмко, особенно на больших разрешениях. Поэтому-то и существуют разные апи, позволяющие как можно больше работы перенести на GPU. И тут дело не в том, что реализация растеризации разная, а в том, что весь пайплайн рендеринга строится иначе и вы не оперируете массивами пикселов напрямую.
stdin/stout/stderr если писать консоль типо своего нкурсес это будут эти буфферы консоли системные, в винде к ним обёртки, в остальных надо документацию смотреть, и будет это на согласовании вызовов IPС, потомучто нужен read рабочий как и с графикой так и с консолью, графическая консоль будет отображать все абстракции лежащие в этой основе, строковый буфер и буфер строк в графике
тоесть либа нкурсес решила по своему эти вопросы
Очень хочу чтобы наконец стали поддерживаться:
Можно узнать - для каких целей вам нужна поддержка всего этого перечня? Разработка ПО для конечного пользователя с использованием одной стандартной либы?
Вот вы пишете:
Речи о поддержке фичей видеокарт вообще не идет.
Ну возьмем для примера виндовый GDI (где все кисти, примитивы, вывод текста, изображения и пр.), с его отрисовкой на CPU. На нем даже анимацию плавную не сделать толком - все дергается и мерцает, а ведь это нативный виндовый API.
Если учесть, что производительность стандартных функций не очень-то и хорошая, что тогда пользователю ждать?
Плюсом ко всему, вот ввели в стандарт этот аналог древнего ископаемого graphics.h пусть даже производительного, но вот какие из 100500 форматов мультимедиа по стандарту должны в ней поддерживаться?
Например, упомянутый SDL для изображений по дефолту только Micro$oft .BMP использует, а ее сателлит - SDL_image на полном фарше за собой такой паровоз зависимостей тянет, что из исходников ее собирать то еще удовольствие.
просто уточенение, оффтопик
SDL_image на полном фарше за собой такой паровоз зависимостей тянет, что из исходников ее собирать то еще удовольствие
при сборке можно отключить ненужные вам зависимости
А можно использовать STB_image, который и вовсе header-only
Нет проблемы загрузить изображение в популярном формате из файла или даже из консоли, проблема именно с вводом-выводом изображений на экран, на печать, с камеры, со сканера и т.п.
при сборке можно отключить ненужные вам зависимости
Наверное я не так выразился и когда я говорил о поддержке "100500 форматов" и библиотеке SDL_image "на полном фарше", я не имел ввиду что не знаю как собрать SDL_image без ненужных мне зависимостей.
SDL_image можно собрать только с использованием stb_image в 100 КБ. Можно собрать только с поддержкой необходимых форматов. Да и GDI может быть аппаратно ускоренным.
Для чего мы обсуждаем поддержку форматов? Какое она на самом деле имеет отношение к наличию библиотеки ввода-вывода?
Да и GDI может быть аппаратно ускоренным.
Про SDL_image, меня не так поняли. А вот за уточнение по GDI спасибо, мой косяк. Оно с висты/семерки появилось, как я понял, но все равно хуже, чем Direct2D. Просто я по древним манускриптам демки учебные писал, вместо того, чтобы в документацию всматриваться, и более им не пользовался.
сеть
На каких уровнях OSI? А SSL, CGI, конкретные протоколы попадают в библиотеку или нет? Я считаю, что придумать сколь угодно вменяемый уровнь абстракции для всего популярного, что считается сетевым как-то сложно.
Следующей хотелкой наверняка будет стек БД инструментов, с разными идиомами, это опять же полезно, но сложно вообще-то. И всем уже существующим проектам не поможет, а новые и так модно (сохраню опечатку) писать на питоне.
вывод на экран изображений как массива цветов пикселов- создание окон графического интерфейса- получение координат и кликов от мышки, тычков от touch интерфейса
Совершено вредно. Выйдет либо что-то вроде Qt в стандартной библиотеке (зачем?), либо на конвеер пойдут приложения с недо-ui, которые нормально не умеют в динамический ppi, без accessibility, наповал нестандартные и ненативные для ОС, не умеющие в message handling OS (если оно есть) и все это дико тормощящее, потому что как верно писали, пайплайн графики с кучки пискелей уже никто не начинает.
Но да ладно.
получение осей и состояний кнопок от иных видов контроллеров
Их же миллион видов и новые делаются, как это вообще стандартизировать. Если что-то на уровне "DirectInput мне бы хватило", то он уже есть.
ввод звука- ввод изображений- ввод видео
А кодеки разве уже все опенсорсные? Это настолько сложная проблема, что хочется спросить, зачем вообще это все?
Чтобы с той же стандартной библиотекой скомпилить прикольную игрушку для контроллера на десктоп? Нет смысла, вот вообще никакого, никто в неё не будет играть. Чтобы перенести десктопное приложение на контроллер с подключённым дисплеем 160 на 120 и 80 МГц ядра? Нет смысла никакого.
Но хуже даже не это, а то, что если бы такая библиотека была, то я бы все равно взял Electron, потому что ui будет красивым! А если я хочу, чтобы ui ещё и не тратил ресурсов (лишних), то встрою простейший http сервер, который отдаст мне ui в виде того же html/js/CSS локально, и он все равно будет красивым, а бонусом получу фичу удалённого управления.
Так что в сухом остатке, лишь соглашусь, что тривиальный http (а лучше https) сервер в стандартную библиотеку включить было бы не вредно. Тогда уже и тривиальный https клиент тоже.
это драйвер kms или drm, всё остальное это бинды от ключевой платформы-драйвера к вашему типу драйвера, тоесть ответом будет то как вы реализовали драйвер, и типо а нужно ли писать драйвер и прочее, но кароче драйвер и соглашение с устройством и платформа и некоторые безопасные функции на платформе
тоесть можно накатать на С++ драйвер, некоторые библиотеки имеют свой драйвер кстати например сдл, просто на С++ вроде пишут сразу в выбранный стандарт под платформу на выбранном фреймворке который решает эти согласованности и сборка под платформу будет решением поидее, тоесть в С++ не входит написание драйвера, драйвера согласуются с железками железки между собой, а платформа запускает эти железки, а потом в юзерленде юзаем С++
получается стандарт это либа которая учла все эти АПИ
но это уже не С++, а просто ктото собрал либу с поддержкой платформ и этими всеми АПИ
и ГТК получше реализован в нём есть некоторые особенности, сигналы интересно конечно и виджеты, но ГТК поосновательнее вроде реализовали штучки свои
Не, ну в общем, в посыле так сказать, автор прав. Когда уже даже C# умеет компилироваться в нативные бинарники (я в курсе про ограничения)... С++ реально просто неудобный. И никак он не выигрывает у того-же Rust, Golang и так далее. Ну ладно, ладно, еще там микроконтроллеры остались и всякое низкоуровневое железо. Но на прикладном уровне таки да. С++ слишком уж монструозен и "бардачен". Я программист если чо. Перепробовал почти все.
После D смотришь на C++ как на динозавра за рулём.
Для микроконтроллеров очень очень много где используются не плюсы, а си.
И вот он в своей нише - действительно (достаточно) комфортный и (почти) безальтернативный
Ибо производители железа что то не спешат пилить софтверные инструменты под Rust
Несмотря на некое ощущение наезда, автор абсолютно прав. Кто из практических программистов пользуется чем-то выходящим за рамки 11-го ну в крайнем случае 14-го стандартов ??? Может таковые и есть, но вряд ли их много. А вот отсутствие стандартизации библиотек, действительно куда серьёзнее чем какие-то новые мало кому нужные возможности языка. Посмотрите хотя бы на V https://vlang.io/ . Он ещё из беты не вылез, а уже идёт со стандартной черт возьми библиотекой, где есть всё, на все случаи жизни https://modules.vlang.io/ ! Будь моя воля, я бы вообще заморозил развитие С++ как языка и сосредоточился исключительно на библиотеках. Чтобы они решали основные задачи, были надёжны как топор, и обеспечены превосходной документацией на всех языках (на русском в том числе). Язык создавался в расчете на производительность. Пусть таковым и остается. Для тех кому нужен высокий уровень абстракции, есть куча куда более вкусных альтернатив.
Да даже библиотеку regex в STL не перенесли толково из boost, где она хоть и средне (по сравнению с PCRE2) но работала стабильно, тогда как версия из STL падает на тех же регулярках. По крайней мере так было несколько лет назад, может быть сейчас уже прокачали.
Кто из практических программистов пользуется чем-то выходящим за рамки 11-го ну в крайнем случае 14-го стандартов ??? Может таковые и есть, но вряд ли их много.
Неужто так мало программистов пользуется span и структурами в темплейтах?
В 17 и 20 стандартах появились вещи, принятые в большинстве современных языков - std::variant и std::visit (практически Rust enum), std::ranges (LINQ из С#, steam api Java, Iterator trait Rust), корутины и многое другое
А можете поделиться, каких библиотек на С++ не хватает?
Ну автор правильно пишет, не иметь библиотеки для стека TCP/IP в 21 веке – это за гранью добра и зла.
С GUI тоже интересная штука, в C++ свои типы, а в Qt свои (и те и другие отличаются от C).
С точки зрения объектной модели и прочего к Qt у меня претензий вообще нет, меня все устраивает, кроме того, что у Qt специфическая лицензия, ну и вот такие приколы с тем, что Qt, как и Boost - это не набор самостоятельных библиотечек, это огромная мегабиблиотека, которую или не используешь или таскаешь целиком. У Boost иногда еще получается таскать не вообще весь Boost, а только 1/10, а у Qt так, насколько я знаю, вообще нельзя.
Ну автор правильно пишет, не иметь библиотеки для стека TCP/IP в 21 веке – это за гранью добра и зла.
А смысл?
Библиотека в стандарте заведомо не может охватить все юзкейсы, потому что у автора опердня, у hft-трейдера и у разработчика браузера сильно разные задачи и сильно разные требования, которые все сразу учесть не получится. Соответственно, сеть в стандарте — это как libm, совершенно базовые функции, чтобы по-быстрому, одной строкой скачать что-нибудь откуда-нибудь, когда тебе неважны детали.
Но Комитет патологически не может выдавать простые решения, чтобы по-быстрому и одной строкой. Там наверняка будут экзекуторы какие-нибудь или вообще senders/receivers, попытка охватить все возможные протоколы, все возможные юкзейсы, и так далее, но при этом это не будет юзабельно для большинства из этих юзкейсов, а для тех, где будет, нужно будет написать грёбаную кучу неочевидного кода, который все будут копипастить из cppreference или stackoverflow (или chatgpt).
ИМХО единственное, что должно быть в стандартной библиотеке — словарные типы. variant. optional. string. unordered_map(правда, в плюсах она уродливо тормознутая по стандарту). Нужны данные. Фич не нужно. Вместо фич нужен адекватный и де-факто стандартный в коммьюнити пакетный менеджер. В хаскеле в стандартной либе нет сети, но я просто добавляю в package.yaml строчку с одной удобной мне в данный момент либой, и у меня есть сеть. Отсутствие сети в стандартной либе меня никак не напрягает.
В хаскеле в стандартной либе нет сети, но я просто добавляю
В хаскеле чудовщно плохая по сравнению с C++ обратная совместимость. А это одна из selling points. Я полагаю, что вот это предложение является одним из подрывающих обратную соместимость действий.
Обратная совместимость C++ — это миф примерно на уровне «C++ даёт самую высокую производительность из возможных».
Во-первых, на практике невозможно просто взять и собрать старый C++-код новым компилятором с хотя бы минимальными гарантиями работоспособности. Новый компилятор может интерпретировать стандарты по-другому, новый компилятор может чинить баги, на которые опиралась старая кодовая база (например, проект по портированию кода в десятка три-четыре kLOC с gcc 6 на gcc 8 в одном моём месте работы занял больше месяца). Самое важное — новый компилятор может (и будет) добавлять новые оптимизации, использующие UB, которые у тебя в коде гарантированно есть. Нельзя просто взять и бампнуть компилятор, починить deprecation-ворнинги и быть уверенным, что получился работоспособный кусок кода.
И именно поэтому в компании, где мы с тобой оба работали, на C++11 перешли, напомни, в 2017-м? В 2018-м? И то после очень больших и систематических усилий core infra-тимы и пинания прикладных тим.
Во-вторых, в хаскеле уже очень давно есть stackage LTS, и я могу взять проект годовй (пятилетней, десятилетней) давности и собрать его сегодня одной командой (те же версии библиотек, и так далее, подтянутся автоматически), получив функционально (а иногда и побитово, если там, условно, при сборке дата сборки не зашивается) эквивалентный бинарник, а в C++ — нет. Это — та «обратная совместимость», которая на самом деле нужна бизнесу — чтобы код, написанный N лет назад, с минимальными правками можно было слегка подправить под новые бизнес-требования и снова запустить сегодня. Успехов тебе взять ПО, написанное на плюсах 10 лет назад, и собрать его без изменений сегодня с гарантиями, что получится эквивалентный бинарник. Тебе нужно будет руками найти тот же компилятор, те же версии зависимостей, и так далее.
Да, есть Комитет, который провозглашает эту совместимость. Только ещё есть суровая реальность, где её нет, потому что провозглашать — не мешки ворочать.
невозможно просто взять и собрать старый C++-код новым компилятором с хотя бы минимальными гарантиями работоспособности.
Да. Тут ты безусловно прав, а я это не учёл. В смысле UBшечки.
на C++11 перешли, напомни, в
Ты не поверишь... :-) :-) :-)
И то после очень больших и систематических усилий core infra-тимы и пинания прикладных тим.
Компилятор SUN Pro так нормально C++11 не поддерживает, поэтому...
есть stackage LTS
Это — та «обратная совместимость», которая на самом деле нужна бизнесу
Я внезапно для себя понял, что я смотрю с точки зрения мейнтейнера дистрибутива Linux с единственным snapshot'ом. А на бизнес мне начхать, хотя, конечно, и эта точка зрения имеет право на жизнь.
Спс.
на практике невозможно просто взять и собрать старый C++-код новым компилятором с хотя бы минимальными гарантиями работоспособности
гмм, даже стало интересно!
криптография 2004-2006 года - это старый и сложный код?
берем свежий компилятор:
> g++ --version
g++ (Rev6, Built by MSYS2 project) 12.2.0
берем исходники DersCrypt https://ders.by/crypt/derscrypt/cpp/src.zip
и делаем:
g++ -Wall -DDERS_CPU=cpu *.cpp -lgmp
key.cpp:39:37: warning: suggest parentheses
и кроме идиотского "suggest parentheses" все прекрасно собралось и отлично работает!
ЗЫ может дело немножно в руках?
Правильней было бы сказать, что не всякий старый код можно собрать в новом компиляторе. И до всяких стандартов можно было писать, не полагаясь на поведение конкретной версии конкретного компилятора, а там, где без этого обойтись невозможно, предпринимать специальные меры, упрощающие перенос проекта. Скажем, разрядность целых типов данных была хоть как-то стандартизирована лишь в C++11, но ничто не мешало и за 20 лет до этого определить с помощью typedef'ов свои INT8, INT16 и т.д. и в проекте использовать только их, а не всякие там short int, которые непонятно во что превратятся при трансляции на произвольной платформе; соответственно, при "переезде" пришлось бы изменить лишь эти typedef'ы в одном заголовке, а не перелопачивать весь проект.
Так что дело, конечно, в том числе и в руках, но не столько собирающего сейчас, сколько пишущего тогда.
криптография 2004-2006 года - это старый и сложный код?
Старый, но несложный.
все прекрасно собралось
Добавьте оптимизации:
% g++ -v |& grep "gcc version"
gcc version 14.2.1 20241221 (Gentoo 14.2.1_p20241221 p7)
% g++ -Wall -Wextra -O3 -DDERS_CPU=cpu -c key.cpp
[...]
In file included from uint.hpp:22,
from key.hpp:19,
from key.cpp:11:
In destructor 'sh_ptr<T>::~sh_ptr() [with T = UInt]',
inlined from 'void Key::computeRemainders(ShUInt, int, std::vector<sh_ptr<UInt> >&)' at key.cpp:57:1:
sh_ptr.hpp:93:30: warning: '*(sh_ptr<UInt>::Rep*)<unknown>.sh_ptr<UInt>::Rep::refs' may be used uninitialized [-Wmaybe-uninitialized]
93 | ~sh_ptr() { if (--rep->refs==0) delete rep; }
| ~~~~~^~~~и отлично работает!
Не могу проверить, потому что хз с чем это запускать вообще.
Но зато ошибки видны просто невооружённым глазом. Например,
else return ShUInt(); // NULLвызывает сначала конструктор sh_ptr<UInt> с нулевым указателем ptr, а потом его удаляет через в итоге fixed_alloc::free(ptr), который…
static void free(void* ptr)
{
fixed_alloc_private::void_alloc<SIZE>::free(ptr);
}, который…
static void free(void* ptr)
{
*(void**)ptr=head;
head=ptr;
}Ой-вей, поздравляю с записью по нулевому указателю.
ЗЫ
ЗЫ — чувак написал 1400 строк кода, из которых треть — переизобретение своего наколенного boost::shared_ptr и прочего подобного, в которых сходу находятся ошибки, и пытается этим опровергнуть наличие проблем с миграцией на новые компиляторы у тех, кого строк кода не 1400, а 140000000.
Это, конечно, смешно.
может дело немножно в руках?
Это про любую технологию сказать можно. Дело всегда в руках, технологии всегда шикарные. Не можешь писать производительный код на JS? Да у тебя просто руки кривые.
о боже, ШИКАРНЫЙ камент!
Не могу проверить, потому что хз с чем это запускать вообще.
файл README там, конечно, для слабаков.
Ой-вей, поздравляю с записью по нулевому указателю.
таки не поверим и внесем изменения здесь:
// fix_alloc.hpp
static void free(void* ptr)
{
printf("free(%p)\n", ptr);
*(void**)ptr=head;
head=ptr;
}и здесь:
// main.cpp
ShUInt f()
{
return ShUInt(); // NULL
}
int main()
{
ShUInt a=f();
printf("a.get()=%p\n", a.get());
}а теперь запускаем:
a.get()=0000000000000000
free(000002b9791b5b00)
ну и??
ЗЫ еще раз убеждаюсь, что главная проблема C++ это некомпетентые кодировщики.
Я вот сопрограммами пользуюсь -- для асинхронного ввода-вывода (на микроконтроллерах).
Кто из практических программистов пользуется чем-то выходящим за рамки 11-го ну в крайнем случае 14-го стандартов ??
C++17: использую auto для structured binding declaration и std::tuple - очень удобно:
auto [a, b, c] = C()наконец-то можно нормально возвращать несколько переменных а не прописывать их как входные параметры
Также - std::optional, string_view
C++20: designated initializers
struct A { int x; int y; int z; };
A b{.x = 1, .z = 2}; - позволяют избежать ошибок когда надо инициализировать много однотипных переменных.
Также использую оператор <=>, std::span
наконец-то можно нормально возвращать несколько переменных
Только захватить в лямбду у вас их получится то ли с C++20, то ли с 23 :]
Глупости. Синтаксис просто чуть более громоздкий, но все будет работать.
Это не отменяет того, что сделано совершенно бессмысленное ограничение, которое вызывает вопросы на практике (тем более, и в вашем подходе можно ошибиться, получив по-тихому копию, забыв &, если structured binding был объявлен как auto&).
тем более, и в вашем подходе можно ошибиться, получив по-тихому копию, забыв
&, если structured binding был объявлен какauto&
В C++20 и выше забывать & тоже нельзя, даже если structured binding был объявлен как auto&, абсолютно никакой разницы в этом плане нет.
Кто из практических программистов пользуется чем-то выходящим за рамки 11-го ну в крайнем случае 14-го стандартов ???
Ну, я пользуюсь вполне С++17 и считаю, что до этого стандарта плюсы довольно-таки гавно и если где-то пишут на С++14 я туда уже не пойду. А я ещё на С++98 успел пописать, т.е. прошёл все итерации стандарта.
Впрочем, С++20 тоже вполне себе неплох. consteval и концепты - очень приятная вещь. Вот С++23 да, чисто косметика, да ещё и не поддерживается нигде.
Будь моя воля, я бы вообще заморозил развитие С++ как языка и сосредоточился исключительно на библиотеках.
Нужно все и сразу - ну возьмите boost. Если уж совсем печально, но есть деньги - возьмите Qt.
Для тех кому нужен высокий уровень абстракции, есть куча куда более вкусных альтернатив.
Всё так и есть. Хочется высокого уровня и не думать о железках - используйте другие языки. Я вот успешно пишут на Python в параллель к плюсам и мне вполне нормально. Rust и Go в принципе тоже ничего.
С одной стороны - ну я, например, пользуюсь ranges - а это C++20/23. С другой стороны - автор первым делом наехал на половину C++11 (range for, lambda, auto). Никто никогда не жаловался, и вдруг блюм - C++98 ему было хорошо, и тут комитет насрал никому видите ли не нужного синтаксического сахара.
Хоть и не могу не согласиться с тем, что комитет где-то потерялся. Пытаться тащить совместимость с C 70-хх годов выпуска до сих пор - это несколько глупо, если эта совместимость активно мешает. Они вот сейчас про safe c++ заговорили; чую, что сделают через задницу - что семантика "нового безопасного" C++ по lifetime будет несовместима со старым кодом, а легаси типа array decay останется
Кто из практических программистов пользуется чем-то выходящим за рамки 11-го ну в крайнем случае 14-го стандартов ??? Может таковые и есть, но вряд ли их много.
На каждом интервью на высокоскоростного байтолюба спрашивают по текущему и иногда следующему стандарту. В 2016-м спрашивали по C++17-фичам, в 2019-м спрашивали по C++20, в 2023-м году спрашивали по C++23. Сейчас не удивлюсь, если по C++26 что-нибудь спросят.
Лично вы пытались что-то стандартизировать? Думаете достаточно решить и оно само сделается? и 25 конкурирующих предложений исчезнут?
Одна из проблем, в том, что комитент пытается сделать всё максимально универсально. Из-за этого не могут согласовать годами базовые вещи, которые есть в других языках. А те, что согласовывают, получаются монструозными.
С++ auto ?
Для того, чтобы создавая параметр цикла в операторе for(...) не приходилось писать конструкцию на полэкрана, если это итератор. Если кто-то злоупотребляет использованием auto в ущерб понятности кода - это проблема использования а не языка.
Для чего синтаксический сахар с новыми формами цикла for ?
Для того, чтобы не возникала неестественная ситуация, когда индекс цикла в исходном коде инкрементируеся, но в исполняемом коде после оптимизатора он наоборот декрементируется, или вообще отсутствует. Оптимизаторы делают такое сплошь и рядом.
Однако, не согласен. Если в языке есть конструкция, которой злоупотребляют, это определённо проблема языка.
И, нет, auto ввели не для итераторов, а для переменных, тип которых уточняется в момент компиляции. И когда его используют не для этого, а для того, чтобы "не приходилось писать конструкцию на полэкрана" это уже злоупотребление.
Не "тип определяется", а "тип выводится автоматически". Что очень неплохо для шаблонов
Если в языке есть конструкция, которой злоупотребляют, это определённо проблема языка.
Соглашусь, но лишь частично. Проблема не в том, что чем-то можно злоупотребить (злоупотребить, пожалуй, можно вообще всем), а в том, что некоторые языки провоцируют злоупотребления, а другие -- наоборот, препятствуют. В качестве крайне примитивного примера -- "оформление" в C (а из него и в C++) присваивания как операции (operator), а не как оператора (statement), из-за чего можно писать (и нередко пишут) что-то вроде:
if ( a = read() )...Запись более короткая, чем, скажем, паскалевское:
a := read();
if a then...Однако сишная запись провоцирует ошибки (= вместо == или наоборот), а нередко и читабельность уменьшает, поскольку поощряет впихивание кучи операций в одну строку -- и усугубляет это практически полным отсутствием контроля типов. Поэтому лично я так никогда не пишу -- предпочитаю паскалевский стиль.
Сейчас, правда, проблема с такими вещами стоит не так остро, как 30 лет назад: если включить все предупреждения компилятора и превратить их в ошибки, бОльшая часть подобных проблем будет отловлена. Но вот во времена ДОС...
Однако сишная запись провоцирует ошибки (= вместо == или наоборот), а нередко и читабельность уменьшает, поскольку поощряет впихивание кучи операций в одну строку -- и усугубляет это практически полным отсутствием контроля типов. Поэтому лично я так никогда не пишу -- предпочитаю паскалевский стиль.
Эту проблему много где решили без запрета таких конструкций, из последних неплохих примеров - Python с его ":=". Там же есть обоснование, почему полный запрет подобных конструкций ограничивает возможности. В C/C++, увы, застыл ранний проблемный стиль.
Фундаментальная разница платформ? Не!
Современные требования к адаптивности ГУЯ? Тоже чушь какая-то!
Скорость разработки и диффицит кадров? Тоже не то!
Виноват С++! Там сложный стандарт, его трудно реализовать!
Предлагаю сразу стандартизировать ядро хромиум в С++:)
Там и сеть и графика и гуй и ещё 100500 разного функционала.
Напоминает религиозные войны, которые велись на ЛОРе в конце 90х.
Последние предложения по развитию языка от Бьярне и Саттера выглядят весьма многообещающими.
А есть ли действительно какая-то сложность делать интерфейсы на JS, а функциональный код на C++? Возьмём хотя бы тот же Electron. Да и более-менее стандартизованные библиотеки есть, тот же Qt есть. Сравнивать HTML+JS+CSS с плюсами в плане удобства описания интерфейса заведомо нечестно, настолько, что даже не вижу смысла это долго аргументировать.
С частью претензий, вроде нормального стандартного вебсервера соглашусь.
С претензией про кроссплатформенный Гуй да ещё и на мобилках не соглашусь, его никто кроме браузеров особо не умеет. И это целеноправленный выбор владельцев платформ, за что им мои пожелания крепкого, но недолгого здоровья.
Складывается впечатление, что цель комитета стандартизации C++ — заставить всех С++‑разработчиков на конец
право слово, как дети...
Главная Цель любого комитета по ХХХ - гарантировать свое существование! а проблемы самого ХХХ тут дело десятое.
далее.
C++ "зашел не в ту дверь" еще при Страуструпе. но! если выбросить ерунду, то можно прекрасно ехать.
вот вы, например, чего бы хотели выбросить??
НЕ ИСПОЛЬЗУЙТЕ ССЫЛКИ и вы избежите почти всех проблем!
С++ тем и хорош, что его применять можно везде, на любой платформе. И библиотечный функции работают на любом процессоре и микроконтроллер.
Вот есть у меня простой микконтроллер, там нет никакого TCP/IP, и зачем мне стандартная библиотека работы с TCP/IP там?
C++ хорош тем, что ты не платишь за то, что ты не используешь. Если ты не используешь библиотеку TCP/IP, то ты никак не ощущаешь ее наличие. Она не компилируется при компилятции твоего кода и не поставляется вместе с собранным тобой бинарником. И это так и сейчас т.к. библиотеки нет, и будет так же, когда библиотека будет. Не подключил - не ощущаешь что она есть никак.
А вот если тебе нужно писать сетевое приложение, то на С++ ты будешь в очередной раз героически превозмогать работу с сокетами на конкретном наборе платформ, потому что в стандартной библиотеке ничего для этого нет, все используют что попало, кто-то таскает с собой гигантский буст, кто-то пишет на нативном API одной платформы, кто-то возится с 2-3 платформами, в результате широко известных качественных и используемых большинством разработчиков библиотек для более высокого уровня нет, и взяться им неоткуда, потому что нет общего фундамента для их построения. Стандартная библиотека должна быть в первую очередь слоем абстракции между базовыми возможностями платформы и высокоуровневым прикладным кодом, а в С++ она осталась на уровне "Смотрите! Моя ЭВМ может вывести ASCII-символ в консоль! Круто -то как!"
Нет, в идее std было заложено, что она может быть реализована на любой платформе, так как это часть языка. Там нет такого, что ты захотел использовать что-то, а оно у тебя не работает на платформе.
Всё что есть в std, должно быть реализовано и работать везде. Это база.
Всё остальное отдельными библиотеками.
На микроконтроллерах запросто половина std может не работать. Файлов, например, может не быть.
Это как так? Почему может не быть, std это часть языка, не может не быть, ну либо это уже не С++.
Файлы есть везде, где есть память. Это же просто именованная область памяти.
Это называется неполной реализацией стандарта.
Конечно, можно сказать, что формально это не C++, но вопрос же здесь не в названии, а в существующей практике. Тогда, впрочем, придётся сделать утверждение, что C++ не может быть реализован в системах, где, например, нет файлов в среде выполнения. А к такому утверждению никто не готов, потому что микроконтроллеры являются важной целевой платформой для применения C++.
Файлы есть везде, где есть память. Это же просто именованная область памяти.
Это не так.
Имею некоторый опыт разработки под QSEE (Qualcomm Secure Execution Environment).
Там не было файловой системы, и, соответственно, в стандартной библиотеке не было функций типа `fopen/open`, `fread/read`, `fwrite/write`. Данные для программы приходилось хранить в виде констант в исходниках, и при каждом их изменении - все перекомпилировать.
Это просто означает, что ваш Компилятор не поддерживал в полной мере стандарт С++, со всеми вытекающими на ваш страх и риск, считайте это некий диалект С++.
Есть такое понятие Embedded C++, там как раз часть библиотеки отсутствует и ещё кое что, например нет исключений. Ну дак это и другой язык
Всё что есть в стандартной либе С++ - должно быть реализовано по стандарту и никак иначе.
а могут и быть. И тогда std будет работать.
Насколько помню, прямо в стандарте указано, что на "полноценных" платформах реализуется всё, а на "неполноценных", типа тех же микроконтроллеров, обязательной является лишь малая часть библиотеки.
Можете прислать ссылку на такую фразу. По моим данным, это не так
https://stackoverflow.com/questions/7854954/is-the-c-std-library-platform-independent
Посмотрите здесь: https://en.cppreference.com/w/cpp/freestanding
Стандартная библиотека должна быть в первую очередь слоем абстракции между базовыми возможностями платформы и высокоуровневым прикладным кодом
И это должно быть верно. Фишка плюсов в том, что значимая часть кода на них не имеет ни сети, ни даже консоли. И тащить сеть, а тем более гуй, в стандарт языка, на котором пишут прошивки и ядра это не правильно.
Хотите язык для компьютеров, с сетью и графикой? Вам нужен не язык, а фреймворк.
Поддержка нужна не в стандарте языка, а в стандартной библиотеке. Нет сети - не пользуйся, в чём проблема?
Ну, речь о том, что поддержку всяких достаточно высокоуровневых вещей вроде сети и гуйни хотят не просто в какой-то библиотеке, а в стандартной библиотеке. Если с сетью ещё можно согласиться (в конце концов, TCP/IP -- он везде, и предусмотреть разумное множество стандартизированных функций по работе с входящими в него протоколами можно), то с гуйнёй -- сомнительно, так скажем.
C++ хорош тем, что ты не платишь за то, что ты не используешь. Если ты не используешь библиотеку TCP/IP, то ты никак не ощущаешь ее наличие. Она не компилируется при компилятции твоего кода и не поставляется вместе с собранным тобой бинарником. И это так и сейчас т.к. библиотеки нет, и будет так же, когда библиотека будет. Не подключил - не ощущаешь что она есть никак.
Это в теории. На практике получается, например, так: ты написал пустой main(). Для оформления argv к нему нужен менеджер динамической памяти. malloc и free имеют диагностику разрушения кучи, которая выводится в stderr. Автоматом подтянулся stdio. Сообщение диагностики может быть локализовано, подтянулся NLS. NLS подтянул ещё что-то для работы со строками. Ты ничего ещё не сделал, а у тебя пол-библиотеки уже подключилось. А если там ещё и оно может какие-то настройки получать (если заказано явно) по сети, код для этого уже есть, привет, и библиотека для TCP/IP...
Проблема до какой-то степени нивелируется тем, что libc мапится всем процессам, а часть кода вынесена в подгружаемые модули. Но именно что "до какой-то степени".
Чтобы такого не происходило, берём не стандартную libc, а специально ограниченную. Возможно, у неё будут слабые символы для замены того, что сейчас не используется, добавляем всякие -lnls -lstdio -ltcpip... и тогда подключаются полноценные реализации. Такое в Linux, например, с libm - в libc есть затычки для небольшого количества простых функций.
Но всё это полностью на откупе у реализации.
А зачем вам на микроконтроллере стандартная библиотека работы с файлами? Или, страшно сказать, параметры argc и argv у функции main?
Ну с файлами вполне полезно, когда поднимаешь, например, fat.
argc и argv можно использовать с загрузчиком, но смысла не много.
Если поднимаешь fat, то и tcp/ip можно поднять. Согласитесь, что они примерно в одной весовой категории аппаратуры.
Ну, мне вот нужен был ФАТ -- но асинхронный, а не fatfs, который насквозь синхронный. Пришлось своё писать. Ну и попробуй такое стандартизировать, чтоб удовлетворить всех и каждого на все случаи жизни :) Не говоря о том, что файловые системы -- это, вообще говоря, забота ОС, а не прикладного кода, и лишь во всяких микроконтроллерных вещах приходится этим заниматься самому.
Так что стандартные библиотеки -- это хорошо, но всё же не стоит валить в одну кучу собственно язык и библиотеки. Это вещи связанные, но не одно и то же.
Стандартная библиотека не может решить вообще все задачи, очевидно, всегда найдется сложный случай, для которого вместо стандартной библиотеки придется использовать что-то другое. Это нормально. Не нормально когда у современного языка программирования стандартная библиотека ввода-вывода застряла в 1980.
Так-то fstream довольно абстрактная вещь, предназначен для работы с данными в именованной области памяти и с абстрактным I/O потоком.
Почему вы думаете, что он не нужен для микроконтроллеров?
Это же не обязательно файл на диске. Вполне себе нужная и самое главное возможная для реализации везде штука.
Аналогию можно привести с консолью. В микроконтроллере нет консоли, однако std::cout прекрасно работает и выводит информацию через отладочный интерфейс в IDE, ну или вы можете перенаправить поток I/O куда хотите, в UART, например.
С TCP/IP так не выйдет - это уже какая-то специфика.
Насколько я понимаю, всё что есть в std, должно быть реализовано и работать везде. Это база.
Так-то fstream довольно абстрактная вещь, предназначен для работы с данными в именованной области памяти и с абстрактным I/O потоком.
Почему вы думаете, что он не нужен для микроконтроллеров?
Это же не обязательно файл на диске. Вполне себе нужная и самое главное возможная для реализации везде штука.
Аналогию можно привести с консолью. В микроконтроллере нет консоли, однако std::cout прекрасно работает и выводит информацию через отладочный интерфейс в IDE, ну или вы можете перенаправить поток I/O куда хотите, в UART, например.
Реализовать на микроконтроллере сие можно. Но это будет реализация специально под конкретный даже не микроконтроллер, а проект на микроконтроллере, а соответственно, не может поставляться как часть библиотеки компилятора.
Насколько я понимаю, всё что есть в std, должно быть реализовано и работать везде. Это база.
Нет. Обязательной базой является лишь малое подмножество, почти всё остальное может отсутствовать в конкретной реализации библиотеки.
Нет. Обязательной базой является лишь малое подмножество, почти всё остальное может отсутствовать в конкретной реализации библиотеки.
Не знаю таких исключений, и стековерфлоу https://stackoverflow.com/questions/7854954/is-the-c-std-library-platform-independent
Аж залогинился чтобы написать ответ. Кризис стандартизации есть, но он совсем не в этом.
Кому вообще нужна эта графика в стандарте? Даже если что-то стандартизуют, то максимум это будет примитивная 2D-графика. Кому она нужна? Студентам для лабораторных? Кто будет использовать ее в продакшене вместо проверенных годами SDL и прочих?
И кто будет ее реализовать? Разработчики стандартных библиотек в этом не разбираются, а тут придется делать аж три копии одной и той же библиотеки, по одной на каждый крупный компилятор. И в каждой будут какие-то свои баги и проблемы, которые потом никогда не исправят, потому что ABI.
Зачем все это? "Фрагментация сообщества" звучит слабовато. Даже если это как-то пропихнут, будет как в https://xkcd.com/927/, добавится еще один (а точнее три!) варианта, а старые никуда не исчезнут. И новые библиотеки будут хуже, чем тот же SDL, поэтому кто их будет использовать?
Настоящий кризис стандартизации в том, что комитет не хочет ломать ABI и добавлять эпохи, поэтому костыли в языке остаются навечно. И в том, что нарисовался Rust и мода на безопасность, а комитет не может толком ничего этому противопоставить.
Настоящий кризис стандартизации в том, что комитет не хочет ломать ABI и добавлять эпохи, поэтому костыли в языке остаются навечно. И в том, что нарисовался Rust и мода на безопасность, а комитет не может толком ничего этому противопоставить.
Вот тут поддерживаю на 300%.
Совместимость и с древними багами C++, и с багами C, и вообще непонятно с чем.
Совместимость и с древними багами C++, и с багами C, и вообще непонятно с чем.
Чтобы не переписывать на новом смузи языке мегатонны кода, в которые уже вложены миллиарды долларов?
смузи языке
Я предполагаю тут конструктивную дискуссию. Постарайтесь, пожалуйста, без подобных приёмчиков.
мегатонны кода, в который уже вложены миллиарды долларов?
И мегатонны новых багов, на которые потратятся ещё миллиарды.
Стандартная дилемма между эксплуатировать старое и создать новое. К сожалению, не всегда она на уровне "отмыть этих, или новых нарожать?"
Кто говорит про переписывать? Я же сказал, "эпохи". Возможность помечать новый код какими-то маркерами, которые отключают старое кривое поведение.
Кажется всегда большая часть таких рассуждений разбивается об аргумент, что если нужно писать запросы в сеть, возьми язык, который для этого сделан. А в этом языке ты вряд ли сможешь работать с указателями. Но с библиотеками да неудобно.
Ну то есть ты говоришь - бросайте С++, учите JavaScript. Это понятная позиция, но меня она расстраивает тем, что такой подход приводит ровно к тому, с чего я начал, к горячему телефону, разогревшемуся и разрящившемуся при отрисовке мессенджера, при том, что даже когда я играю на нем в 3д игры он так не греется, а для вывода мессенджера написанного на С++ КПК хватало и ARM процессора на 200 мегагерц еще 20 лет назад, и КПК от этого не грелся и не тормозил.
Странно, а что делать тем разработчикам, которые используют С++20 и выше? И системы сборки, которые им удобны.
И каждый день работают со span, auto, лямбды, for и считают это очень удобным?
Лично я вообще не вижу большой проблемы в языке, скорее в компиляторе, который много делает не предупреждая о последствиях.
Как что им делать? Я не говорю, что надо что-то запретить или у кого-то отнять их любимые системы сборки. Я говорю, что у С++, как у современного языка, должна быть стандартная система сборки, являющаяся частью языка, что должна быть нормальная библиотека ввода-вывода, соответствующая возможностям ввода-вывода современных платформ, тоже являющаяся частью языка.
Преждевременно говорить о системе сборки, если даже модульность сделана через #include. Это самая архаичная часть C++, от которой остальные языки ушли лет 30-40 назад.
Да пиши как есть: модульность в С++ не сделана. Даже в более древних языках она уже была.
прямо так модулей в стандарте нет? (не будем пока о том, как оно работает)
Что-то, что называется "модуль" в стандарте С++ есть. Но, как это часто бывает, пользоваться этим наверное можно, но полезность очень сильно ограничена.
Каков порядок инициализации статических переменных внутри и между модулями в С++?
Есть ли у модулей в С++ код инициализации модуля, запускаемый до первого использования модуля?
Как в С++ подключить модуль во время выполнения программы? Ну, на микроконтроллере, например, чтобы память экономить?
А вот в Modula-2 модули имели хорошо формализованный способ инициализации, могли подключаться динамически и вообще, если посмотреть на модули в Modula-2 и в С++, складывается впечатление, что из этих двух языков обьектно-ориентированный - это Modula-2
Модули в C++ по синтаксису фактически прямо дёрнуты из Scheme. Но только Scheme - динамический язык, и библиотека там - просто макрос поверх исполняемых операторов, вот и получается в статическом C++ вся эта фигня.
Согласен, что естественнее было бы заимствовать из Modula/Delphi, или хоть из Ada/Fortran.
Причём модули в C++20 прикрутили, но, как обычно, через такую задницу, что они... не шибко хороши, скажем так.
А вот ввод-вывод нормально не стандартизируешь, поскольку это сильно завязано на ОС. В Винде всю жизнь был асинхронный ввод-вывод, а в Унихе его нет. Стандарт POSIX предлагает его, но это стандарт, а не конкретная ОС, и далеко не все ему следуют. В Линух сравнительно недавно добавили IO_URING, но он какой-то странный и переусложнённый, как по мне. Ну и как делать нормальную стандартную библиотеку в таких условиях? printf как консольная печать хорош тем, что он действительно может быть стандартным: весьма сложно найти систему, где его невозможно реализовать. А что-то сложней -- всё, приехали, здесь так, там эдак...
Модули-то в C++20 сами по себе в вакууме почти нормальные, фактически это приличный кусок модульной системы R7RS Scheme. Но вот на легаси код (и принципы работы компилятора C++) они не ложатся вообще никак.
Ты сейчас шутишь?
Вот правда, что, сложно стандартизовать способ получения в программу на С++ координат курсора мышки в системах где такой курсор в принципе есть? Где нет - там и не надо, по аналогии с тем, что если в системе нет консоли то там и cout не выводит на консоль.
Или сложно стандартизовать пару функций для создания окна и вывода битмэпа так, чтобы при вызове первой создавалось окно, а при вызове второй изображение отображалось на canvas во все это окно?
да, это тоже будет что-то рисовать только если система поддерживает вывод изображений.
Или сложно стандартизовать функцию для открытия TCP сокета?
Не написать реализацию которая бы была оптимальной, не придумать стандарт, гарантирующий возможность оптимальной реализации, нет, просто стандартизовать что-то достаточно хорошее для наиболее распространенных сейчас платформ. Реализация делающих все это библиотек для многих платформ вообще говоря уже есть, более того, их много разных, с разными лицензиями и разными интерфейсами. И в том то и проблема.
Я очень любил C++ на протяжении многих лет (даже первая статья на хабре про него). Но в какой-то момент просто устал превозмогать трудности на ровном месте (отсутствие стандартного менеджера зависимостей, стандартного сборщика, нормальной стандартной библиотеки), перешел на Rust и полностью счастлив. Закопайте старичка и не ворошите труп
Я переходил на C# и тоже был счастлив несколько лет, но потом пришлось вернуться ради производительности и кроссплатформенности. Смотрел на Rust - заявленные цели красивые, но реализация вызывает вопросы. История с самым быстрым и безопасным веб-сервером на Rust для меня показательная - внутри оказался небезопасный код с гонками, наличием которого объяснялась хорошая производительность и ставился жирный крест на безопасности. И то, что язык такое позволяет, для меня говорит о крахе основной идеи безопасного языка в этом случае. Вообще ситуация напоминает ситуацию с исключениями в С++, где нет способа написать код, использующий чужой класс так, чтобы при появлении в коде этого нового класса новых исключений которые он вдруг решит выбрасывать, использующий его код перестал компилироваться до тех пор, пока разработчик не изучит все эти исключения и не обработает их надлежащим образом.
Такая история с исключениями вроде была в Java. Потом почему-то решили, что это решение было ошибкой и откатили обратно.
Да, это было ужасное решение, из тех что хорошо выглядят на бумаге, но по факту очень неудобны.
В большинстве случаев все что нужно знать - бывает в этом методе эксепшен или нет. Какой именно - знать надо очень редко, так как в 99% случаев во всех реальных проектах где я был вся обработка исключений сводится просто к catch Exception, без разделения на подтипы. Зато везде нужно пробрасывать бесконечные списки исключений в сигнатурах методов, ну или опять же сводить все к throws Exception, или оборачивать все в RuntimeException.
И по факту если ты работаешь с фреймворком каким-то, то ты и так ожидаешь эксепшенов в нужных местах, и знаешь где что может вылететь, и оно обычно всегда достаточно очевидно, чтобы не нужно было тащить это в код в виде обязательных обработчиков,
Слава богу, в Kotlin эту фичу тащить не стали. Там есть аннотация Throws, которую можно использовать как подсказку, а можно не использовать, если это не нужно или не удобно.
Вам не придётся таскать списки исключений, если они будут выводиться компилятором.
В большинстве случаев все что нужно знать - бывает в этом методе эксепшен или нет
А вас опция компилятора -fno-exceptions или конструкции noexcept, __has_feature(cxx_exceptions), __has_feature(cxx_noexcept), __has_extension(cxx_noexcept) ни на какие мысли не наводят?
Про эксцепшены не только можно знать, но и гарантировать их отсутствие, если это необходимо вашему реальному проекту. Просто этим нужно уметь немного пользоваться.
Я про Java.
В С++ везде где я работал (геймдев и ИИ) исключения были отключены для производительности, поэтому вообще хз как там устроено все.
Значит я не понял, что речь пошла уже о Java
Отключение исключений для производительности - имело смысл в ранние времена. Сейчас потеря в большинстве случаев реально ничтожна и незаметна на общем фоне вариативности в зависимости от 100500 факторов включая микрокод процессора и соседние программы. Наоборот, постоянные проверки возвращаемых значений влияют постоянно.
Так что если где-то сейчас есть такая полиси - почти наверняка это чистая устарелость.
а какая проблема с кроссплатформенностью у C#?
Знаете, это просто самоутешения. Я тоже долго подобное испытывал со стороны глядя на Rust, и утешаясь тем, что на самом деле якобы он не такой уж безопасный, не такой уж быстрый, и так далее. Но стоило попробовать и понял что Rust просто лучше. Лучше экосистема, лучше синтаксис, легкое подключение библиотек, легкая сборка под разные платформы, легче отладка (отладчик практически не нужен), лучше работа "из коробки". C++ просто слишком стар.
C++ и кризис стандартизации
Допускаю, что у профессионалов может быть куча претензий к С++, но у меня, как любителя, их нет вообще.
Предпочитаю работать на VS C++ 2013 либо чуть больше / чуть меньше. С++ практически всегда использую в связке с WTL.
Пример моего пет-проекта можно посмотреть в https://habr.com/ru/articles/848836/ . Либо скриншот для неопубликованного проекта «МедиаТекст» в http://scholium.webservis.ru/Pics/MediaText.png .
Есть и другие проекты, включая создание dll, но претензий именно к языку нет. Только к подключаемым внешним модулям.
В общем работать с С++, для меня, одно удовольствие
Мессенджер описанный в статье подозреваю Скайп? Гуй Скайпа, напомню, написан на языке Делфи, который отлично подходит для подобного рода задач. Он и не плюсы со всеми описанными и не только проблемами и не JS/Электрон со всеми его известными минусами. Однако было решено переписать гуй на электрон. Закончилось так себе. Я, для примера, вообще от Скайпа отказался. Работал просто отвратительно что на телефоне что на компе. К слову на плюсах мессенджеры вполне существуют. Телеграм. Отлично (ожидаемо) работает на ПК. Телефоны, правда, не осилили: Жава.
Да посмотрите на самые базовые возможности SDL в конце концов.
Ага, а еще посмотрите как эту SDL перехреначивают каждый мажорный релиз. Вот и в SDL3 по сравнению с SDL2 все перехреначили до неузнаваемости, там и ABI и API весь сломан - все попереименовали, типы поменяли (где раньше стол был яств теперь там гроб стоит был int, теперь bool)... И я уверен что еще будут фиксить всякие баги, которых там все еще миллион, со сломом API/ABI, а юзер будет вынужден лепить свои #if SDL_VERSION_ATLEAST( ... ) чтобы лавировать между всем этим с разной степенью успешности. В std такому точно не место. Идея запихать в std все на свете заведомо мертворожденная, никто этим заниматься не будет.
Ну да, давайте жить со стандартной библиотекой ввода-вывода из 1980
все попереименовали, типы поменяли (где раньше стол был яств теперь там гроб стоит был int, теперь bool)...
Бог с этими bool, они int на float заменили и сейчас встроенные примитивы да и вообще всё рендерится исключительно с точностью до субпикселя. Пару недель назад проект небольшой с SDL2 на SDL3 хотел перенести, первоначальный результат - черный экран, пока SDL_Rect на SDL_FRect не поменял везде.
... горячий сотовый телефон...
...Для чего в С++ auto и лямбды?
Телефон из-за лямбд греется, что ли?
Косвенно, да. Если сократить цепочку рассуждений то получается примерно так: Коммитет по стандартизации вместо добавления в С++ адекватной библиотеки ввода-вывода продолжает тратить время на добавление в язык свистелок. Тем временем на дворе 2025 год и прикладные программы для тех же телефонов можно писать в том числе и на С++, но пишут их на JavaScript, потому что на С++ нарисовать пузырь мессенджера и текст настолько тяжело, что опытному разработчику на С++ может быть проще выучить JavaScript и сделать мессенджер на нем. При этом этот самый мессенджер, сделанный на JavaScript, нагружает процессор телефона на порядок сильнее, чем нагружали раньше мессенджеры, написанные на С++.
JS вызывает ту же самую библиотеку для рисования, что используется и в C++. А телефон ваш греется из-за некомпетентных разработчиков, которые на любом языке натворят полной дичи.
Ну и не понятно это бросание в крайности - можно далеко не отходить от C++ и взять D. Там тоже нет "единственно верной библиотеки рисования", но там есть модульная система и репозиторий пакетов, что позволяет легко использовать чужие наработки.
А промежуточные варианты в виде Java (для андроида), Swift (для айфона) и пр. - нет, надо сразу в Javascript, а небось ещё и Electron?
Ну тогда это точно не проблема платформы, это "в консерватории" (ц) надо менять.
Главная причина тормознутости современного прикладного ПО это то что руководство не просто не требует от разработчиков написания оптимизированного софта, но и демотивирует их это делать. Обычно требуется чтоб очередная фича была реализована как можно быстрее и нормально работала на целевом устройстве (пофигу сколько памяти съест, если на целевом устройстве эта память есть). Задержка реализации очередной задачи даже на 1-2 дня (не говоря уже о неделе) ради оптимизации, воспринимается как потерянные деньги (в эти 1-2 дня можно было бы следующую фичи напилить) и ненужные потенциальные риски (риск регресса в будущем оптимального алгоритма и риск того что другие разработчики в будущем будут долго вносить изменения в оптимизированный участок или привнесут баги в него).
Так что пока оптимизированный софт не станет писать выгодно, ничего не изменится.
В стандартной библиотеке нет ничего, нельзя даже имея готовую 2D картинку в памяти, вывести ее на экран... (и далее)
Можно я задам тупой вопрос: а зачем? Ну, возьмите другой язык, чтобы вывести картинку.
У С++ одна ниша - делать что-то очень-очень быстро. Всё. Если вам нужно выводить 10000 объектов в секунду - вам нужен С++, но я вас уверяю, написание кода по соббсно отрисовки UI будет наименьшей из ваших проблем. В остальных случай возьмите JS, Python, Qt и не парьтесь особо.
Я очень люблю С++ и пишу на нем быстрые и легковесные программы. И я уверен, что и другие могли бы писать на С++ быстрые и легковесные программы вместо высаживающих батарейку телефона за 1 час программ на других языках, если бы им это было делать не слишком сложно. И даже ядро языка С++, само по себе, не слишком сложное, люди вполне справляются с изучением, высоченный порог сложности возникает при переходе от "написать на С++ консольную программу" к "написать на С++ программу с графическим интерфейсом". Даже само по себе это - не слишком сложно, берешь тот же Qt и готово. Проблемы начинаются с совместимостью разных библиотек, как программной так и по лицензии. И вот тут оказывается, что у С++ нет стандартного, то есть предположительно работающего на всех платформах, способа вывести на экран хоть что-то отличное от текста в консоли.
А где есть?) Даже JS не в счёт, там что-то отличное от текста в консоли выводится только в браузере. За пределами браузера ничего нет)
Только в python можно графички повыводить, и в Java вроде чего-то есть, но опять же - не очень-то кроссплатформенно.
В С++ есть Qt. Работает вообще на всех платформах. Есть imgui, тоже работает почти везде и простой. Есть SFML. Всё вполне рабочее.
Начал за здравие, а закончил предложением добавить графический API... Кажется, я понял, как попадают в комитет =)
Комитет стандартизации C++ есть конечно за что ругать. Но отсутствие стандартизации работы с графикой - последнее, что приходит в голову. Это слишком платформоспецифичная вещь, чтобы её можно было стандартизировать.
Ругать надо за отсутствие стандартизации того, что казалось бы должно быть, но по каким-то странным причинам отсутствует. embed ещё не завезли, хотя это по сути тот же #nclude с парой дополнительных шагов. Работа с пользовательскими типами в unordered_map - головная боль, ибо нужно руками писать классы для хеширования, к тому же хеширования нету даже для некоторых встроенных классов. Ассоциативные контейнеры реализованы неоптимальным образом и их оптимизации мешает священная корова совместимости ABI. Поддержка UTF-8 рудиментарная, в std::regex её нету совсем. std::variant сделан криво - вместо методов get/get_if/holds_alternative там зачем-то внешние функции, что добавляет сумбурности при их использовании.
Мне кажется, причиной такой медлительности и нерешительности являются подходы работы. Цель стандартизации видимо состоит в том, чтобы нововведения не вызывали возражений, в том числе у самых отъявленных перфекционистов. А если так не получается, внедрение полезного функционала откладывается на неопределённое будущее.
std::variant сделан криво - вместо методов get/get_if/holds_alternative там зачем-то внешние функции, что добавляет сумбурности при их использовании.
Встречал объяснение от членов комитета, что это ради экономии ключевых слов. Если бы они были мембером, то в шаблонном коде с зависимым от параметров шаблона типом variantа вам бы пришлось писать variant.template get<T>()
Смотрите, с++ это ИСО стандарт. Что такое ИСО стандарт? Это пдфка. Все, там ничего другого нет. Реализация стандарта в виде компилятора и библиотеки к комитету вообще никакого прямого отношения не имеет. Да там заседают много людей которые потом все это имплементируют, но это случайность.
Стандарт полон фич которые уже депрекэйтед или вообще удалены. И знаете каких? Тех которые не взлетели, ну например гц, ограничения на эксепции, когда то давно был экспорт шаблонов, да много чего ещё я не могу всего знать. А знаете кто решает нужна фича или нет? Нет, не вы и не я и не тот парень за соседним столом. Это решают имплементоры стандарта. Их по сути 3. Если они скажут комитет принял какую-то херню и решат ее не имплементировать то вообще не важно, что там в той пдфке написано. И так было не раз.
Ваше предложение добавить в стандарт графику противозачаточное. Оно не имеет шансов воплотится в работающий код ни в одной мне известной вселенной. Даже если комитет его примет. Даже если графика по функционалу будет проще консоли. Это не нужно ни одному вендору.
Едем дальше, предъявите список других стандартов ИСО на языки? Я знаю только ещё один Си. Там ситуация с вашей точки зрения должна быть в 10 раз хуже, я конечно не варюсь в этой экосистеме, но ни разу не видел подобных жужаний.
Языки где все то что вы хотите идёт в библиотеке либо управляются единственным вендором либо сразу рождены с этим функционалом. В других языках эта проблема эффективно решается не стандартом/спекой или ещё чем то похожим, а центральным репозиторием библиотек читай экосистемой/комьюнити.
Мне не нужна графика в стандарте вот вообще никакая, мне нужен центральный репозиторий. Нет, мне не нужен стандартизированный способ сборки, мне нужен центральный репозиторий и я буду с удовольствием жрать любой кактус который этот репозиторий будет использовать для сборки. Ворочать нос, ворчать, но жрать и вслух ещё и нахваливать.
Попыток сделать такой репозиторий много, но центральным ни стала ни одна. Почему? я не знаю, но вижу, что задача объективно сложная, финансово затратная и просто (если вообще возможно) не монетизируемая. Чрезвычайно рискованная черная дыра времени, усилий и денег. Мне кажется для с++ окно возможностей создать такой репозиторий уже закрылось. Его никогда не будет. Смиритесь и живите с этим, ну или запилите уже наконец-то сами :)
Вообще стандартов ISO на разные языки много, но только в C и C++, насколько мне известно, исторически сложилась такая ситуация, что телега прицеплена впереди лошади, то есть в комитете по стандартизации сидят какие-то мечтатели, которые сами выдумывают фичи для будущих реализаций языка. В других языках в основном стандарты фиксируют лучшую практику из уже существующих трансляторов (хотя последние 10-15 лет ISO Fortran тоже пошёл в отрыв от реальности, но там по крайней мере никто стандарт не воспринимает как абсолютную догму).
Я не специалист, но Полухин, несомненный эксперт, в своих выступлениях как раз обратную ситуацию говорил - что в коммитет добавляет в основном фичи, что многим нужны и уже лет 20-30 наколхозены в разных видах. И что многие фичи пропихивают всякие Гуглы и понятное дело не просто так "помечтать".
Только потребности всяких Гуглов могут очень сильно отличаться от потребностей разработчиков нормального прикладного программного обеспечения. Всякие Гуглы поддерживают написанный на С++ много лет назад серверный софт, у них есть огромные библиотеки для работы с интересующей их платформой, и проблема высокого порога вхождения для создания прикладных программ типа мессенджеров для iOS их вообще не беспокоит.
Я не представляю себе, то ли изображать 🤦🏻 во всей красе, то ли просто проигнорировать. Ну, пока есть немного времени и настроения, отвечу более-менее по пунктам, но не сильно растекаясь.
Для чего в С++ auto и лямбды? Для чего синтаксический сахар с новыми формами цикла for?
auto и for - чтобы код нормально читался и легко писался, а значит, и на нём было меньше ошибок. Вы не представляете себе объём головной боли даже от простейших ситуаций, когда код вида for(i=0;i<n;ii++) сначала для новичка, а потом для замученного жизнью и потоком задач профессионала начинает требовать часы потери на том, что он уже в упор не видит, что в третьем выражении ii вместо i.
Лямбды - потому что есть масса случаев, когда удобно и полезно сделать замыкание, или просто вынести кусок действий в отдельную функцию даже формально.
Или вот тот же механизм исключений. Изначально хорошая идея была реализована настолько неудачно, что многие крупные проекты полностью запрещают использование исключений.
Потому что запретили в самом начале, пока исключения были неэффективными, а сейчас там тотальное легаси.
в C++ до сих пор нет стандартного пакетного менеджера.
Не может быть "стандартного пакетного менеджера" там, где платформы варьируются от условного Arduino через Yocto и до стандартных десктопов-серверов. Он в принципе не потянет все варианты указания зависимостей, сборки, доставки, проверки и линковки.
Ситуация усугубляется полным отсутствием стандартных инструментов для работы с сетью. В 2024 году, когда интернет стал неотъемлемой частью любого приложения, в C++ до сих пор нет даже простейшей библиотеки для работы с TCP/IP!
Потому что нет общего стандарта интерфейса нижнего уровня даже по возможностям. Там, где он есть (99+% это BSD sockets), можно работать через эти сокеты, применить ASIO или ещё кучу других библиотек. Но, например, где-то надо работать через DPDK. Прикажете писать свой стек в userland поверх него? А зачем, если задача этого напрямую не требует?
Я бы понял ещё вариант, когда стандарт говорит "если есть BSD sockets или TLI/XTI, то обязан быть вот такой-то хедер с вот такими-то возможностями". Но только под таким "если", и его надо продумывать, что туда должно входить и как... сторонние вендоры типа Boost этим занимаются не хуже (и даже лучше).
Но если так не делать, получится как сейчас. Всегда в hosted варианте должны присутствовать stdin, stdout, stderr и соответственно cin, cout, cerr. А если их просто некуда завести? Кто гарантирует наличие /dev/null в рантайме, чтобы чтение из stdin не клинило программу даже случайно? Это требование просто избыточно в таком виде.
Такое впечатление, будто с сетью вы смотрите на Java или C# как на пример. Это там норма назвать ServerSocket то, что у не зацикленных на парадигме людей звалось бы TcpServerSocket, как будто других и не существует. Они не думают про другие варианты. С целевыми нишами C++ так не получится.
даже о простых вещах, таких как стандартная библиотека для работы с сетью
Работа с сетью НЕ является простой вещью. Извините за капс, но повторюсь: вы смотрите с точки зрения, будто другой работы, кроме поверх TCP (и 99% - REST over HTTP) не существует. Это не так.
Даже в случае общестандартного BSD sockets есть куча вариантов реализации. Например, в BSD (а значит Mac и iPhone) и Linux совершенно разный подход к обработке ошибок передачи датаграмм по UDP. В Linux, если не включен спец-режим, нормально, что ошибка отправки датаграммы 1 рапортуется в sendto() на датаграмму 2. И если это некорректно обрабатывать - можно наломать дров. А вы хотите ещё один уровень навернуть, на котором всё это скрывается.
Абсурдность ситуации достигла такого уровня, что создание простого мессенджера на C++, который будет работать хотя бы на двух‑трех популярных операционных системах, требует от опытного С++‑разработчика больше времени и усилий, чем изучение JavaScript с нуля и создание того же мессенджера с использованием веб‑технологий. Это не просто провал — это полная капитуляция языка перед базовыми потребностями современной разработки.
Потому что "веб-технологии", браузер - это отдельная платформа. Это не Windows, не Linux, это браузер. Там все детали тщательно проработаны и максимально сглажены - и да, кодом почти исключительно на C++. Ну разве что Rust местами примешивается.
до инструментов для создания графического интерфейса.
Смешно. На который из подходов будем ориентироваться, когда фреймбуфер, GDI формата Win32 и какой-нибудь Vulkan не имеют ничего общего, кроме идеи про пиксели с цветами? И то, на смартфоне вам придётся учитывать вырез под камеру, скруглённые углы и наложение управляющих кнопок.
"Текстовый интерфейс", как вы говорите, в варианте, жёстко зажатом в рельсы ASCII - это ещё хоть как-то универсально. И то, на SystemZ будут проблемы, там EBCDIC, и терминалы, которые не TTY, а текстовый фреймбуфер с разметкой полей. TTY придётся эмулировать.
Да для чего это все нужно? Комитет, очнитесь! В стандартной библиотеке нет ничего, нельзя даже имея готовую 2D картинку в памяти, вывести ее на экран.
На какой именно экран? Пока вы не ответите хотя бы на этот вопрос, не будет ответа на ваш.
Складывается впечатление, что цель комитета стандартизации C++ — заставить всех С++‑разработчиков наконец выучить JavaScript и перестать использовать С++.
Складывается впечатление, что вы кроме обстановки браузера ничего и не видели. Это не в наезд, просто я иначе не могу понять, откуда такие идеи в принципе.
Определённое рациональное зерно в вашем эмоциональном выплеске есть: вполне возможно, в пределах комитета стоило бы сделать подкомитеты разных типовых доменов. Налево - embedded, направо - браузер, прямо - десктоп с GDI, ещё по какой-то кривой дорожке - сетевой высокоскоростной обработчик чего-то сетевого с трансформацией данных. И у каждого профиля свои стандартизации, рекомендации, что должно быть и как. Браузеру не нужен DPDK, embeddedʼу не нужен графический ускоритель, десктопу не нужна оптимизация под работу в ста килобайтах. Профили соответственно будут иметь разные рекомендации, что обязательно, что желательно. Такое я бы послушал, и комитет будет меньше рваться на части. Но не в том формате, как эта статья.
Стандартизация C++ проблемна, да. Но то, что вы описываете - почти во всём не его проблемы, а его проблемы вам, судя по данному постингу, незнакомы.
Никто не догадался задать малтчику классический ленинский вопрос - "Как нам реорганизовать рабкрин?"
Его ответ был таким.
Реорганизация языка C++ — это сложная задача, учитывая его историю, широкое использование и множество существующих кодовых баз. Однако, если бы мы задумались о том, как можно улучшить или модернизировать C++, вот несколько идей, которые могли бы быть рассмотрены:
1. Упрощение синтаксиса
Проблема: Синтаксис C++ может быть излишне сложным и перегруженным.
Решение: Ввести более простые и интуитивно понятные конструкции для часто используемых паттернов. Например:
Упростить шаблоны (templates) с помощью концепций (concepts) и других механизмов.
Уменьшить количество способов сделать одно и то же (например, инициализация переменных: =, {}, ()).
2. Улучшение системы модулей
Проблема: Заголовочные файлы (#include) устарели и могут вызывать проблемы с зависимостями и временем компиляции.
Решение: Полноценная поддержка модулей (как в C++20), чтобы заменить #include. Это ускорит компиляцию и улучшит инкапсуляцию.
3. Безопасность памяти
Проблема: Управление памятью в C++ требует высокой дисциплины и может приводить к утечкам, висячим указателям и другим ошибкам.
Решение: Встроить инструменты для автоматического управления памятью (например, умные указатели как стандарт) или добавить опциональный сборщик мусора. Также можно улучшить статический анализ и добавить больше проверок времени выполнения.
4. Улучшение стандартной библиотеки
Проблема: Стандартная библиотека C++ иногда неудобна или недостаточно функциональна.
Решение: Расширить стандартную библиотеку, добавив больше современных структур данных и алгоритмов. Например:
Встроить поддержку сетей, JSON, XML и других популярных форматов.
Добавить больше функций для работы с асинхронным программированием.
5. Упрощение многопоточности
Проблема: Многопоточное программирование в C++ сложно и подвержено ошибкам.
Решение: Ввести более высокоуровневые абстракции для работы с потоками и синхронизацией, например, как в Rust или Go.
6. Обратная совместимость
Проблема: C++ должен поддерживать обратную совместимость, что ограничивает возможности для улучшений.
Решение: Ввести "режим совместимости" и "режим современного C++", где в современном режиме можно было бы использовать более строгие и безопасные конструкции.
7. Улучшение инструментов разработки
Проблема: Инструменты для работы с C++ (компиляторы, отладчики, анализаторы) иногда недостаточно удобны.
Решение: Улучшить стандартизацию инструментов и их интеграцию. Например:
Унифицировать форматы диагностики ошибок.
Встроить больше возможностей для статического анализа.
8. Упрощение метапрограммирования
Проблема: Шаблоны и метапрограммирование в C++ могут быть чрезвычайно сложными.
Решение: Ввести более простые и мощные механизмы для метапрограммирования, такие как рефлексия и улучшенные концепции.
9. Улучшение документации и обучения
Проблема: C++ сложен для изучения из-за своего объема и нюансов.
Решение: Создать более структурированную и доступную документацию, а также обучающие материалы, которые бы учитывали современные подходы.
10. Экосистема пакетов
Проблема: В C++ отсутствует стандартная система управления зависимостями.
Решение: Ввести стандартный менеджер пакетов, подобный npm для JavaScript или cargo для Rust.
Заключение
Реорганизация C++ должна быть осторожной, чтобы не нарушить существующие кодовые базы. Однако, с учетом современных требований к языкам программирования, такие изменения могли бы сделать C++ более безопасным, удобным и конкурентоспособным. Многие из этих идей уже частично реализуются в современных стандартах (C++11, C++14, C++17, C++20, C++23), но есть еще куда расти.
С этим Я с ним абсолютно солидарен!
У меня на ладони лежит очень горячий сотовый телефон, который разогрелся из‑за того, что мессенджер отображает статичное сообщение с пузырем и текстом на экране при помощи браузерного движка и безумного количества сторонних библиотек
Да, это действительно боль - когда открываешь какой-нибудь сайт, где рекламы больше, чем полезного контента и смартфон начинает жрать батарейку как не в себя. Бесит. Надо их всех запретить в выдаче поисковиков для мобильных бразуеров, чтобы у владельцев этих говно-сайтов упала посещаемость и они озаботились оптимизациями.
Для чего в С++ auto и лямбды? Для чего синтаксический сахар с новыми формами цикла for?
Может быть, для решения тех самых базовых задач современного программирования? Что важнее, как раз эти фичи позволяют решать задачи эффективно с точки зрения производительности. Потому что без range based for, ваш код скорее всего окажется необоснованно неэффективным в силу того, что вам нужно в голове держать кучу информации. От существенной вроде того факта, что из-за strlen в условии можно получить квадрат до более тонких, как, например, как знание того факта, что беззнаковые индексы хуже оптимизируются компилятором ввиду наличия гарантий на поведение при их переполнении
А без лямбд любой реалистичный программист устанет от написания классов с operator(), выполняющим роль лямбд и начнёт пытаться в разных местах программы переиспользовать один и тот же класс, что негативно скажется как на эффективности кода (придётся передавать кучи ненужных полей), так и на архитектуре проекта
Программисты вынуждены искать сторонние решения или подключать громоздкие фреймворки только для того, чтобы отправить HTTP‑запрос
А расскажите, как именно "громоздкий фреймворк" перестаёт быть таковым, когда вы его переносите в стандартную библиотеку?
он парализован и годами не может договориться даже о простых вещах, таких как стандартная библиотека для работы с сетью
Быть может, вы заблуждаетесь, считая эту вещь такой уж простой? Реальность такова, что "простое" решение может оказаться невостребованным, даже если оно является стандартным. Что важнее, вы уж определитесь, вы за производительность, требующей нетривиальных вещей вроде асинхронного ввода-вывода, или же вы за медленную простоту
Все по делу. Удивительно, что фанаты стандартов и мертворожденных решений в них не заминусили статью.
Для чего в С++ auto и лямбды?
Auto нужен, чтобы вместо std::unordered_map<std::string, std::vector<std::vector<uint32_t>>>::iterator it = m_data.begin();
можно было писатьauto it = m_data.begin();
Лямбды нужны, чтобы не замусоривать область видимости функцией, которая будет нужна ровно в одном месте.
Для чего синтаксический сахар с новыми формами цикла for?
Чтобы не было побочных эффектов, связанных с возможностью изменить счётчик из любого места в цикле. Выше написали пример. Чтобы избежать громоздких конструкций обращения по индексу.
Концепты, корутины, ranges, span не являются ни базовыми, ни необходимыми для создания прикладных программ
Концепты по духу близки к интерфейсам в Java — дать возможность оперировать объектами, зная о них только какое-то определённое свойство. Вы же не предложите выкинуть из джавы интерфейсы и заменить множественным наследованием классов?
Корутины и ranges — так это как раз всенародно любимый функциональный стиль с map-reduce. Сам я не фанат запихивать сложные преобразования коллекций в однострочник, но людям нравится. По крайней мере, в примерах на тех же Rust и Javascript регулярно встречаю map + filter + collect + что-то-там-ещё.
Span — а у вас когда-нибудь была ситуация, когда вам нужно обработать массив объектов, функция обработки принимает только const std::vector&, а вам ну вот вообще не впёрлось выделять новый vector в куче для нескольких локальных объектов? У меня было, и неоднократно. Span решает именно эту проблему — хочешь передавай vector, хочешь std::array, хочешь самописный велосипед. Лишь бы объект был представим в виде "указатель + размер". Span сильно снижает количество произнесённого мата, вы даже не представляете, насколько.
Auto нужен, чтобы вместо std::unordered_map<std::string, std::vector<std::vector<uint32_t>>>::iterator it = m_data.begin();можно было писатьauto it = m_data.begin();
Вообще это называется "сначала героически страдать, вводя полную статическую типизацию, а потом по факту её отменять, потому что пользоваться ей неудобно".
Ваш пример с auto корректен, однако он также просто решается typedef. И не забудем, что Мейерс в "Effective Modern С++" посвятил 25 страниц разъяснениям, когда auto может "выстрелить в ногу"
Лямбды нужны ввиду отсутствия в языке локальных (вложенных) функций, которые гораздо лучше читаемы.
В ногу, особенно в C/C++, может выстрелить очень много что, начиная с простого типа char (который имеет хз какой размер, да ещё может быть и знаковым, и беззнаковым -- про отсутствие контроля типов вообще промолчим).
Насчёт отсутствия локальных функций согласен. Но, как по мне, короткая и простая лямбда, вставленная прямо там, где она нужна, будет читабельней, чем отдельная, пускай даже вложенная функция (скажем, когда функции сортировки нужно передать указатель на функцию сравнения, а последняя сводится к сравнению одного поля структуры, что прекрасно укладывается в однострочную лямбду).
Вот если лямбда занимает несколько строк, то, как по мне, почти всегда лучше всё-таки оформить отдельную функцию.
Однострочные лямбды экономичнее локальных функций, с этим, я думаю, никто не спорит. Маркером проблемы становится код, где лямбду помещают в локальную переменную, потом вызывают эту переменную.
Однако 25 страниц разъяснений по поводу простой языковой конструкции типа auto означает её недостаточную продуманность.
Недавно было обсуждение, где я было пожаловался на те же проблемы отсутствия в стандартной библиотеке не то что сетевых средств, но даже ведения логов! Тут же получил тучу минусов от блюстителей непонятно чего. Действительно, возникает ощущение стандартизации, как самоцели, при этом процветает практика добавления "сделать то же самое, но по-новому" вместо действительно нужной функциональности.
Несколько лет назад я начал писать рецензию "Книга ужасов "Effective Modern С++"", но "забил" на середине. Многие программисты пользуются только некоторым подмножеством стандарта языка и собственными наработками, но это тупик в развитии.
Интересно, что в Раст-сообществе тоже очень ревностно относятся к критике, причем если Си++ совместим с Си, то Раст не совместим ни с чем. Rust, или дожить бы до зрелости
совместимость со старым кодом (в том числе на языке С) это не баг, а фича
зачем затаскивать в стандарт языка то
что, с одной стороны, можно легко реализовать через библиотеку
невозможно хорошо реализовать с учетом ограничений огромного числа платформ, под которые есть компилятор
На счёт графики и прочего. Язык С++ достаточно низкоуровневый и используется для разработки ПО под самые разнообразные платформы. Начиная с микроконтроллеров с мизерной памятью и производительностью и заканчивая игровыми движками для игр класса AAA. Такие вещи безболезненно можно реализовать только в виде набора стандартных библиотек, но никак не в виде части самого языка. Лично я не использую в нем даже шаблоны классов, так как достаточно простого полиморфизма и перегрузки операций. Во многих современных языках даже этого нет, но они при этом прекрасно живут.
C++ и кризис стандартизации