А можно использовать STB_image, который и вовсе header-only
Нет проблемы загрузить изображение в популярном формате из файла или даже из консоли, проблема именно с вводом-выводом изображений на экран, на печать, с камеры, со сканера и т.п.
Никто не предлагает сдлать "единственно верный API", стандартная библиотека не является и никогда не являлась "единственно верным API". Цель стандартизации библиотек не в том, чтобы предоставить что-то "единственно верное", цель в том, чтобы обеспечить базис, на основе которого прикладные программы могут работать на различных платформах. Например, в той же Windows есть замечательный набор API вызовов для асинхронной работы с файлами, и существование стандартной библиотеки ввода-вывыода никак не мешает существованию этого API. Никакого вреда от существования стандартного API работы с файлами при этом нет, только польза: если возможностей, предоставляемых стандартной библиотекой, достаточно, то программа, использующая только стандартную библиотеку великолепно работает и под Windows и под Linux и под MacOS.
Речи о поддержке фичей видеокарт вообще не идет. Сейчас стандартная библиотека С++ не позволяет вообще никак работать с большей частью способов ввода-вывода современных компьютеров. Поддерживается: - консоль - файлы Надеюсь, скоро будет поддерживаться: - сеть Очень хочу чтобы наконец стали поддерживаться: - вывод на экран изображений как массива цветов пикселов - создание окон графического интерфейса - получение координат и кликов от мышки, тычков от touch интерфейса - получение осей и состояний кнопок от иных видов контроллеров - вывод звука - ввод звука - ввод изображений - ввод видео
Это самый базовый уровень для наиболее распространенных способов ввода-вывода, который позволил бы полноценно использовать самые базовые возможности современных компьютеров.
Только потребности всяких Гуглов могут очень сильно отличаться от потребностей разработчиков нормального прикладного программного обеспечения. Всякие Гуглы поддерживают написанный на С++ много лет назад серверный софт, у них есть огромные библиотеки для работы с интересующей их платформой, и проблема высокого порога вхождения для создания прикладных программ типа мессенджеров для iOS их вообще не беспокоит.
Я очень люблю С++ и пишу на нем быстрые и легковесные программы. И я уверен, что и другие могли бы писать на С++ быстрые и легковесные программы вместо высаживающих батарейку телефона за 1 час программ на других языках, если бы им это было делать не слишком сложно. И даже ядро языка С++, само по себе, не слишком сложное, люди вполне справляются с изучением, высоченный порог сложности возникает при переходе от "написать на С++ консольную программу" к "написать на С++ программу с графическим интерфейсом". Даже само по себе это - не слишком сложно, берешь тот же Qt и готово. Проблемы начинаются с совместимостью разных библиотек, как программной так и по лицензии. И вот тут оказывается, что у С++ нет стандартного, то есть предположительно работающего на всех платформах, способа вывести на экран хоть что-то отличное от текста в консоли.
Косвенно, да. Если сократить цепочку рассуждений то получается примерно так: Коммитет по стандартизации вместо добавления в С++ адекватной библиотеки ввода-вывода продолжает тратить время на добавление в язык свистелок. Тем временем на дворе 2025 год и прикладные программы для тех же телефонов можно писать в том числе и на С++, но пишут их на JavaScript, потому что на С++ нарисовать пузырь мессенджера и текст настолько тяжело, что опытному разработчику на С++ может быть проще выучить JavaScript и сделать мессенджер на нем. При этом этот самый мессенджер, сделанный на JavaScript, нагружает процессор телефона на порядок сильнее, чем нагружали раньше мессенджеры, написанные на С++.
Проблема совместимости версий python создана соврешенно искусственно, и, можно сказать, умышленно. Не было никакой причины делать это именно так. Ну и "почти работающий" инструмент миграции это все равно что "пациент почти жив".
Но особенно больно на python потому, что это интерпретируемый язык.
Ты сейчас шутишь? Вот правда, что, сложно стандартизовать способ получения в программу на С++ координат курсора мышки в системах где такой курсор в принципе есть? Где нет - там и не надо, по аналогии с тем, что если в системе нет консоли то там и cout не выводит на консоль. Или сложно стандартизовать пару функций для создания окна и вывода битмэпа так, чтобы при вызове первой создавалось окно, а при вызове второй изображение отображалось на canvas во все это окно? да, это тоже будет что-то рисовать только если система поддерживает вывод изображений. Или сложно стандартизовать функцию для открытия TCP сокета? Не написать реализацию которая бы была оптимальной, не придумать стандарт, гарантирующий возможность оптимальной реализации, нет, просто стандартизовать что-то достаточно хорошее для наиболее распространенных сейчас платформ. Реализация делающих все это библиотек для многих платформ вообще говоря уже есть, более того, их много разных, с разными лицензиями и разными интерфейсами. И в том то и проблема.
Стандартная библиотека не может решить вообще все задачи, очевидно, всегда найдется сложный случай, для которого вместо стандартной библиотеки придется использовать что-то другое. Это нормально. Не нормально когда у современного языка программирования стандартная библиотека ввода-вывода застряла в 1980.
Что-то, что называется "модуль" в стандарте С++ есть. Но, как это часто бывает, пользоваться этим наверное можно, но полезность очень сильно ограничена.
Каков порядок инициализации статических переменных внутри и между модулями в С++?
Есть ли у модулей в С++ код инициализации модуля, запускаемый до первого использования модуля?
Как в С++ подключить модуль во время выполнения программы? Ну, на микроконтроллере, например, чтобы память экономить?
А вот в Modula-2 модули имели хорошо формализованный способ инициализации, могли подключаться динамически и вообще, если посмотреть на модули в Modula-2 и в С++, складывается впечатление, что из этих двух языков обьектно-ориентированный - это Modula-2
Нет, не Скайп, им я почти перестал пользоваться после того как он перестал нормально работать на узких каналах и совсем перестал пользоваться когда он перестал работать со старой учетной записью.
Какие прикладные библиотеки? Я пишу о библиотеках ввода-вывода. Сейчас в С++ есть ввод-вывод в файл и на консоль. Консоль - это современный способ ввода-вывода в мейнстриме?
Так хороший или надо выверять?
А ты на стороне ранних или поздних ECS?
И на каком языке ты предлагаешь разрабатывать саму игру, а на каком - описывать component-ы?
Ну уговорил, можешь оставить
Стандартная библиотека это часть того что стандартизует коммитет
Для чего мы обсуждаем поддержку форматов? Какое она на самом деле имеет отношение к наличию библиотеки ввода-вывода?
А можно использовать STB_image, который и вовсе header-only
Нет проблемы загрузить изображение в популярном формате из файла или даже из консоли, проблема именно с вводом-выводом изображений на экран, на печать, с камеры, со сканера и т.п.
Это понятно, я согласен на вывод графики и получение пользовательского ввода, без совсем уж гуи типа кнопочек и прогрессбаров.
Да я и сам пользуюсь и auto и range for, сахар он ведь на то и сахар что с ним жизнь слаще.
Никто не предлагает сдлать "единственно верный API", стандартная библиотека не является и никогда не являлась "единственно верным API". Цель стандартизации библиотек не в том, чтобы предоставить что-то "единственно верное", цель в том, чтобы обеспечить базис, на основе которого прикладные программы могут работать на различных платформах. Например, в той же Windows есть замечательный набор API вызовов для асинхронной работы с файлами, и существование стандартной библиотеки ввода-вывыода никак не мешает существованию этого API. Никакого вреда от существования стандартного API работы с файлами при этом нет, только польза: если возможностей, предоставляемых стандартной библиотекой, достаточно, то программа, использующая только стандартную библиотеку великолепно работает и под Windows и под Linux и под MacOS.
Речи о поддержке фичей видеокарт вообще не идет. Сейчас стандартная библиотека С++ не позволяет вообще никак работать с большей частью способов ввода-вывода современных компьютеров.
Поддерживается:
- консоль
- файлы
Надеюсь, скоро будет поддерживаться:
- сеть
Очень хочу чтобы наконец стали поддерживаться:
- вывод на экран изображений как массива цветов пикселов
- создание окон графического интерфейса
- получение координат и кликов от мышки, тычков от touch интерфейса
- получение осей и состояний кнопок от иных видов контроллеров
- вывод звука
- ввод звука
- ввод изображений
- ввод видео
Это самый базовый уровень для наиболее распространенных способов ввода-вывода, который позволил бы полноценно использовать самые базовые возможности современных компьютеров.
Только потребности всяких Гуглов могут очень сильно отличаться от потребностей разработчиков нормального прикладного программного обеспечения. Всякие Гуглы поддерживают написанный на С++ много лет назад серверный софт, у них есть огромные библиотеки для работы с интересующей их платформой, и проблема высокого порога вхождения для создания прикладных программ типа мессенджеров для iOS их вообще не беспокоит.
Я очень люблю С++ и пишу на нем быстрые и легковесные программы. И я уверен, что и другие могли бы писать на С++ быстрые и легковесные программы вместо высаживающих батарейку телефона за 1 час программ на других языках, если бы им это было делать не слишком сложно. И даже ядро языка С++, само по себе, не слишком сложное, люди вполне справляются с изучением, высоченный порог сложности возникает при переходе от "написать на С++ консольную программу" к "написать на С++ программу с графическим интерфейсом". Даже само по себе это - не слишком сложно, берешь тот же Qt и готово. Проблемы начинаются с совместимостью разных библиотек, как программной так и по лицензии. И вот тут оказывается, что у С++ нет стандартного, то есть предположительно работающего на всех платформах, способа вывести на экран хоть что-то отличное от текста в консоли.
Косвенно, да. Если сократить цепочку рассуждений то получается примерно так: Коммитет по стандартизации вместо добавления в С++ адекватной библиотеки ввода-вывода продолжает тратить время на добавление в язык свистелок. Тем временем на дворе 2025 год и прикладные программы для тех же телефонов можно писать в том числе и на С++, но пишут их на JavaScript, потому что на С++ нарисовать пузырь мессенджера и текст настолько тяжело, что опытному разработчику на С++ может быть проще выучить JavaScript и сделать мессенджер на нем. При этом этот самый мессенджер, сделанный на JavaScript, нагружает процессор телефона на порядок сильнее, чем нагружали раньше мессенджеры, написанные на С++.
Проблема совместимости версий python создана соврешенно искусственно, и, можно сказать, умышленно. Не было никакой причины делать это именно так. Ну и "почти работающий" инструмент миграции это все равно что "пациент почти жив".
Но особенно больно на python потому, что это интерпретируемый язык.
Ну да, давайте жить со стандартной библиотекой ввода-вывода из 1980
Ты сейчас шутишь?
Вот правда, что, сложно стандартизовать способ получения в программу на С++ координат курсора мышки в системах где такой курсор в принципе есть? Где нет - там и не надо, по аналогии с тем, что если в системе нет консоли то там и cout не выводит на консоль.
Или сложно стандартизовать пару функций для создания окна и вывода битмэпа так, чтобы при вызове первой создавалось окно, а при вызове второй изображение отображалось на canvas во все это окно?
да, это тоже будет что-то рисовать только если система поддерживает вывод изображений.
Или сложно стандартизовать функцию для открытия TCP сокета?
Не написать реализацию которая бы была оптимальной, не придумать стандарт, гарантирующий возможность оптимальной реализации, нет, просто стандартизовать что-то достаточно хорошее для наиболее распространенных сейчас платформ. Реализация делающих все это библиотек для многих платформ вообще говоря уже есть, более того, их много разных, с разными лицензиями и разными интерфейсами. И в том то и проблема.
Стандартная библиотека не может решить вообще все задачи, очевидно, всегда найдется сложный случай, для которого вместо стандартной библиотеки придется использовать что-то другое. Это нормально. Не нормально когда у современного языка программирования стандартная библиотека ввода-вывода застряла в 1980.
Что-то, что называется "модуль" в стандарте С++ есть. Но, как это часто бывает, пользоваться этим наверное можно, но полезность очень сильно ограничена.
Каков порядок инициализации статических переменных внутри и между модулями в С++?
Есть ли у модулей в С++ код инициализации модуля, запускаемый до первого использования модуля?
Как в С++ подключить модуль во время выполнения программы? Ну, на микроконтроллере, например, чтобы память экономить?
А вот в Modula-2 модули имели хорошо формализованный способ инициализации, могли подключаться динамически и вообще, если посмотреть на модули в Modula-2 и в С++, складывается впечатление, что из этих двух языков обьектно-ориентированный - это Modula-2
Нет, не Скайп, им я почти перестал пользоваться после того как он перестал нормально работать на узких каналах и совсем перестал пользоваться когда он перестал работать со старой учетной записью.
А какой там единственно верный способ вывода буковок в консоль? Curses? Borland TurboVision? printf? cout? Notcurses?
Какие прикладные библиотеки?
Я пишу о библиотеках ввода-вывода.
Сейчас в С++ есть ввод-вывод в файл и на консоль. Консоль - это современный способ ввода-вывода в мейнстриме?