SDL Storage API Merged For SDL 3.0

[mr_tawan]

Aren't there language specific I/O APIs that abstract it already? C++, Rust and etc. have pretty good standard libraries for this. I.e. you don't often need to use OS specific level APIs unless you really want to. So what is the benefit of this that standard libraries don't provide?

Since SDL is C library, and C does not really have a standard library for file system if I'm not mistaken. This should fit right in for those who still works in C rather than C++ for example.

Also it has an API to distinguish between application data (title storage) and the userdata (user storage), which SDL_filesystem covers it somewhat, but may be they expand it further (I haven't look at it fully).

[F.Ultra]

if you assume utf8 internally you can just call WideCharToMultiByte and MultiByteToWideChar to translate between utf8 and (broken) utf16 for filesystem operations

\\?\
Don't forget that you also have to prepend the filename with "\\?\" to avoid the 260 character max length of a complete path in Windows.

[shmerl]

Since SDL is C library, and C does not really have a standard library for file system if I'm not mistaken. This should fit right in for those who still works in C rather than C++ for example..

Why make it part of SDL though? Just make a separate library if you worry about C. Sounds like everything and your kitchen sink a bit.

Besides, SDL is intended for games to use, and games are not using C in the vast majority.

[byteabit]

Besides, SDL is intended for games to use, and games are not using C in the vast majority.

SDL has 25 language bindings, including C++, C#, Rust and Python. And it supports and abstracts away 8 backends on different operating systems and uses what is available when compiled, including DirectX, Vulkan, Metal and Xlib. At least according to https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer , I don't use SDL (yet). It sounds to me that you can use your favorite language, and makes it easier to write once and compile it for different platforms. Anyone who programs directly in DirectX or Vulkan says its complicated mess. So another abstraction like SDL seems to be a good solution for some, especially if you don't know every detail about the operating system and the diverse selection of backends you target.

[DMJC]

That's why I don't even try to make my (little) programs and scripts compatible with Windows. Especially when it comes to filesystem. Thank god I am not getting paid for doing this and don't try to sell anything.

Just target/ship for Linux and tell Windows users to install WSL. Most stuff runs in WSL anyway.

[tildearrow]

if you assume utf8 internally you can just call WideCharToMultiByte and MultiByteToWideChar to translate between utf8 and (broken) utf16 for filesystem operations

Sometimes that didn't work for me. I had to write my own functions for char encoding conversion...

[rclark]

Besides, SDL is intended for games to use, and games are not using C in the vast majority.

Ahhh, now I know why games are so 'big' ... A lot of bloat in them from not using straight 'C' and SDL for a nice lean and mean game (or any) application . Probably using Visual Basic, or just Basic I imagine.... . That said SDL can be used for more than just games. Any time you need graphic output (say automation projects with dials, switches, sliders, graphs, etc.), SDL can be the base library.

I like the portability concept between M$ and every other posix OS. If you do have have a foot in both worlds, this makes sense.... On the other hand, I'd like SDL to concentrate on optimizing the graphics side as much as possible and not run off on tangents that take resources away from making a good library better. Oh course if the goal is to allow easy porting of more applications to Linux ... This may just be a good thing. Just saying. Just like Java was (and is to some extent) to be the language of 'write once, run everywhere' language.

[rmfx]

This summarizes partially very well why I think windows is a disgusting piece of sh!t os.
Nothing is designed the proper way with this crap. Its only win is that Walmart only sells computers with this crap preinstalled, nothing more.

[pabloski]

That means Rust cannot open files with invalid filenames but C++ can.

Rust can act in an unsafe way, so it can. But for people that value security and robustness, Rust gives the means to act responsibly.