Пишу фреймворк LDL, аналог SDL но на С++ и с поддержкой старых систем

Красава, успехов тебе

Прошу перенести тему в Форум «Development»

Не в тот раздел запостил.

Весь код написан на С++ 98, для поддержки большего числа компиляторов и систем

А что, остались какие-то актуальные компиляторы и системы, в которых нет хотя бы C++11? Просто использовать С++98 в 2023 - это издевательство над здравым смыслом.

Крутяк, а что за лицензия в 2-х словах, почему не gpl?

А что, остались какие-то актуальные компиляторы и системы, в которых нет хотя бы C++11?

Да это системы с 20+ лет. В которых и С++ 98 реализован не полностью. В том числе, что бы я мог собирать и под такие системы пришлось ограничится старым стандартом.

Просто использовать С++98 в 2023 - это издевательство над здравым смыслом. Не сказать, что С++ 98 уж совсем плох, но некоторых фич конечно не хватает. Но таков путь и мне по фану. :)

Я пишу фреймворк с поддержкой windows 95 в 2023, используя здравый смысл.

Крутяк, а что за лицензия в 2-х словах, почему не gpl? Bsd подобная, разрешает закрывать код и юзать его как угодно. Мне нравится GPL, но для библиотеки она может сыграть злую шутку.

Мудрое решение

А в чём основная претензия к SDL/SDL2? Хотя SDL2 разжирел прилично конечно. По причине плюсов лично мне полностью не интересно, но желаю больших успехов. Дело хорошее в любом случае.

Аудио подсистема в реализации, пилю поддержку потокового воспроизведения музыки.

Можно вместо именно потоковой музыки сделать очередь воспроизведения. Я себе для своих нужд на LOVE сделал клиент который просто по TCP получает данные размером в зависимости от требуемой задержки и делает из них очередь воспроизведения. Так и сеть и звук можно использовать отдельно и поток делать таким какой нужен, а не какой просто есть. Хоть звук в base64 принимай если приспичит и декодируй/воспроизводи. Я так понимаю именно прям потоковый звук как сущность будет лишена этой гибкости, ну разве что коллбеков понавешать своих.

Ну, эт я так, мысли в слух. Удачи и стараний и идей хороших.

Поддержка Soft

Программная реализация рендера одинакова по возможностям что и на основе OpenGL 1.2 и OpenGL 3? В смысле API рендера одно, разница лишь в том что под капотом выбрано?

Процесс с пустым окном по памяти сколько выдаёт?

Интересное начинание и интересный проект. Удачи!

Альтернатив у SDL не так много. Помню был SFML тоже на плюсах. А ещё был Allegro, кажется сишный.

А в чём основная претензия к SDL/SDL2? Хотя SDL2 разжирел прилично конечно. По причине плюсов лично мне полностью не интересно, но желаю больших успехов. Дело хорошее в любом случае.

Фреймворк поддерживает С API. Нужно в первом сообщении указать. SDL с каждой новой версией дропает кучу старых систем. Мне нравится старое железо, хотелось бы его поддерживать. То есть на фреймворке можно писать под старые ос и программы будут работать и с новыми ос после перекомпиляции, если не юзать не поддерживаемые примитивы.

Программная реализация рендера одинакова по возможностям что и на основе OpenGL 1.2 и OpenGL 3? В смысле API рендера одно, разница лишь в том что под капотом выбрано?

Да именно так. API одинаков, но в зависимости от возможностей железа будет юзаться определённый рендер.

Процесс с пустым окном по памяти сколько выдаёт? Пока не могу ответить. На днях доделаю полную поддержку Linux и померю обязательно.

Ну, эт я так, мысли в слух. Удачи и стараний и идей хороших.

Обдумаю, я в таком аспекте не думал. Хотел да простой колбек, как в SDL реализовано.

Интересное начинание и интересный проект. Удачи!

Спасибо.

Альтернатив у SDL не так много. Помню был SFML тоже на плюсах. А ещё был Allegro, кажется сишный.

Да я всё эти проекты смотрел. И многие концепции повторил. Хотел соединить SFML и SDL, но только сделать намного легче и проще, модульнее.

Ещё хотел показать, что можно малым количеством кода поддерживать и старые системы. Конечно это не актуально, но как фича, почему бы и нет. Старое железо ещё может приносить пользу.

К примеру поддержка OpenGL 1.2 это 1000 строк, OpenGL 3.0 это 2000 строк. Но зато это огромное количество старого железа.

Для тестирования производительности и концепций фреймворка пишу открытый движок игры Arcanum. Так сказать, как разработчик оцениваю API, какой функционал добавит, что убрать, удобен, как сделать лучше и т.д

Проект Arcanum World

Скрин

про рендеры: недавно «тыкал палочкой» векторный 2D рендер не OpenGL, исключительно на CPU: https://blend2d.com/ . Очень хорош, возьми на заметку

фреймворк с поддержкой windows 95 в 2023, используя здравый смысл.

для кого? Зачем кто-то должен начать тратить свою жизнь на твои идеи? Без пользователей нет фреймворка.

Без пользователей нет фреймворка.

И наоборот

Зачем кто-то должен начать тратить свою жизнь на твои идеи?

Он же не заставляет никого.

для кого?

Для себя, всегда все всё пишут для себя (за редкими исключениями) если не за деньги, остальные уже подтянутся сами если им надо.

Ну и for fun никто не отменял =)

Весь код написан на С++ 98

а разве сейчас есть какие то ограничения для хотя бы с++17 где-то? Ну и без мув-семантики до с++11 как то грустно и страшно даже мыслить о пользовании таким фреймворком...

Я пишу фреймворк с поддержкой windows 95 в 2023, используя здравый смысл.

я думаю это самообман.

А зачем создавать прототип allocator, если есть std::allocator?

а разве сейчас есть какие то ограничения для хотя бы с++17 где-то? Ну и без мув-семантики до с++11 как то грустно и страшно даже мыслить о пользовании таким фреймворком…

С++ 17 недоступен для очень старых систем. Это и старые дистры Linux, Windows 9x, старые MacOs и другие. И что бы быть уверенным, что фреймворк точно соберется использую С++ 98.

Так же я рассматриваю вариант, компиляции кода новым компилятором в асм с последующей трансляцией на старой системе. Пока только в теории.

Как вариант обмазать ifdef’ами с проверками на стандарт. Не собо и грустно, раньше как то писали софт и без мов семантики.

А зачем создавать прототип allocator, если есть std::allocator?

Для независимости от STL в будущем. Многие старые компиляторы, проблемно собирают кастомные аллокаторы. Решил добавить свой вариант. Проект собирается Visual C++ 6.0

Тут потенциальное UB поскольку нет никакой гарантии, что по полученному адресу находится что то вообще — сперва его могли создать, но до вызова данной строки удалить извне.

я думаю это самообман.

Это for Fun. Каким бы безумным оно не казалось:)

Для себя, всегда все всё пишут для себя (за редкими исключениями) если не за деньги, остальные уже подтянутся сами если им надо.

Ну и for fun никто не отменял =)

Именно так, вы меня поняли. Я вообще бекендер, проект в том числе, что бы разобраться как оно в унутрях устроено.

Не собо и грустно, раньше как то писали софт и без мов семантики.

ну уж нет, — как раз все грустили, поскольку были лишь нетривиальные способы обходить копирование во многих случаях, и делали кучу реальных костылей, которые работали нормально только в каких то определенных случаях.

Тут потенциальное UB поскольку нет никакой гарантии, что по полученному адресу находится что то вообще — сперва его могли создать, но до вызова данной строки удалить извне.

Спасибо поправлю.

Тут много подобных строк кода, на которых скрывается потенциальное UB — нет никаких гарантий, что память по данному адресу в момент обращения к ней будет реально нужной. А еще будет грустнее, если та память все же была «освобождена», но на самом деле не затерта (или затерта частично). Это еще и угроза безопасности софта, собранного данным фреймворком. Для этих целей и внедрили все же примитивы автоуправления лайфтаймом и владения сущностями — такие как std::shared_ptr, std::unique_ptr и другие.

хотя именно в конструкторе все же больше надо уточнить, что возможно UB только в случае параллельно выполняемого кода, для которого можно указать конвенционально про внешнюю синхронизацию. Но вот в дургих использованиях, в том числе в деструкторе — уже будет грусть.

Тут много подобных строк кода, на которых скрывается потенциальное UB — нет никаких гарантий, что память по данному адресу в момент обращения к ней будет реально нужной. А еще будет грустнее, если та память все же была «освобождена», но на самом деле не затерта (или затерта частично). Это еще и угроза безопасности софта, собранного данным фреймворком. Для этих целей и внедрили все же примитивы автоуправления лайфтаймом и владения сущностями — такие как std::shared_ptr, std::unique_ptr и другие.

Я понимаю преимущество фич современнных стандартов С++. Но в данном контексе, могу расставить assert’ы Что бы проверка работала и в релизе. Решение не идеальное конечно, но проблему решает.

А как проверить, что там лежит реально то, что ожидается? Там будет не nullptr, но не обязательно нужное.

хотя именно в конструкторе все же больше надо уточнить, что возможно UB только в случае параллельно выполняемого кода, для которого можно указать конвенционально про внешнюю синхронизацию. Но вот в дургих использованиях, в том числе в деструкторе — уже будет грусть.

На данный момент это минус фреймворка, но пока. Нужно проработать вопрос с потоками и theard safe. В будущем данные проблемы решу.

Поддержка старых систем 25+ лет.

Поддержка старого железа 25+ лет.

А где же поддержка DOS?

А, всё, нашёл на Хабре:

В будущем планирую обеспечить поддержку Dos

Меня больше такое беспокоит — тут без какого либо параллелизма (и многопоточности) возможны UB. — Тут в примере будет вызван в конструкторе

_Allocator->Deallocate(_Content);

А где же поддержка DOS?

Будет. Для портирования использую OpenWatcom, позволяет собирать 32 битные бинарники под Dos, на современных системах.

Мотивация не понятна, но удачи пожелать хочется. Успехов!

Меня больше такое беспокоит — тут без какого либо параллелизма (и многопоточности) возможны UB. — Тут в примере будет вызван в конструкторе _Allocator->Deallocate(_Content); , который уже освобожден.

Как вариант и в контексте С++ 98, только assert. Других вариантов не вижу. Или кидать исключение, я использую RuntimeError исключение на весь фреймворк, для фатальных ошибок, если оно вылетело, значит программа не может далее выполняться.

Поддержка старых систем 25+ лет.

Самый бесполезный пункт.

Мотивация не понятна, но удачи пожелать хочется. Успехов!

Это и fun, интерес разобраться как всё работает. Интерес прикоснуться к старым операционкам, железу тех лет. Посмотреть какими инструментами поьзовались разработчики. Как решали вопросы с производительностью на старом железе.

Мне нравится ретро тематика. И решил поделиться.

Самый бесполезный пункт.

Согласен. И убер фичей это не назвать. Считайте это просто пунктиком от автора:)

Самый бесполезный пункт.

Не то, что бы я хочу начать холивар. Но ещё большой плюс в том, что если фреймворк работает на древнем железе, то он будет летать на новом. Но конечно, при реализации возможностей платформы. И это довольно интересный момент. Показатель того, что явных стопоров в том, что бы разрабатывать быстрый софт нет. Это возможно и фреймворк тому доказательство.

Для себя, всегда все всё пишут для себя

нет, конечно.

Фреймворк пишут для того, чтобы другие делали так, как ты задумал. Для ограничения чужой свободы самовыражения, а за это ограничение все должны получить серьезный буст в производительности.

Фреймворк — всегда коллективная вещь для ограничения коллективной свободы/бардака.

ещё и обман других. Тут нет никакого здравого смысла

Да, бывает, что приходится поддерживать легаси, в котором даже C++11 нету, дописывать для него код.

Другое дело, что новый фреймворк туда тащить никто не будет, конечно.

Фреймворк пишут для того, чтобы другие делали так, как ты задумал.

Или для того, чтобы самому было проще делать то, что приходится делать.

Будут ли пользователи и насколько их много – это уже второй вопрос. И этот вопрос окажется совершенно неважным, если автор закроет собственные потребности.

Интересно, буду следить. Как появится поддержка, протестирую.

большой плюс в том, что если фреймворк работает на древнем железе, то он будет летать на новом

Это не всегда так.

Например, ты можешь написать вылизанный код для старого одноядерного процессора, выжимающий максимум из его производительности. Но на современном процессоре он может оказаться тормозом из-за того, что не сможет распараллелить вычислительную задачку на несколько ядер.

Но я тебя не отговариваю, конечно, твой проект внезапно для кого-то может оказаться спасением. Выбор — это всегда хорошо.

Мне нравится GPL, но для библиотеки она может сыграть злую шутку.

Есть же LGPL, которая позволяет использовать твоё детище в проприетарных разработках и при этом гарантирует, что саму библиотеку не зажмут. Золотая середина для библиотек, имхо.

А как проверить, что указатель ссылается на валидную память? сам то указатель валидный — не nullptr.