function to create/delete/take list directory contents of folder

[owl721]

it would be useful to manage files. I think it will make game more portable(find save files and etc).

[Hiura]

Yes, that would be very useful. However, if we want a really robust and well design API for that in SFML, it will take considerable time and effort. If we are pragmatic about this, we should not do it at all.

Why? Well, many libraries already do it. I'm pretty sure boost has something for that. Also, with C++17, there will be a standard filesystem API. By the time we implement something in SFML, this would already be available to most users.

[owl721]

Hiura, thank for information

[Nexus]

See also: Contribution Guidelines

Contributions must fit into one of the following SFML modules: [...] That clearly rules out anything specifically related to game development. Such counterexamples are: Physics, collision detection/response, AI, path finding, 3D abstraction layer (like the current graphics module), file system, etc.

Just use Boost.Filesystem, it's a really good library.

[Mario]

But Boost as a whole is still a horrible dependency IMO.

[Rosme]

So go with Cereal. It's similar to Boost.FileSystem but it's header only and does not come with Boost dependancy.

[dabbertorres]

Cereal is a serialization library, right? That's nothing like Boost.Filesystem, that's like Boost.Serialization. That's not what he asked for.

But making your own isn't too much work if you don't want to use Boost.

For example, Vittoreo Romeo has one in his Utils library: https://github.com/SuperV1234/SSVUtils

I made my own once, though it does not have OSX support because I don't have OSX to try it with: https://github.com/dabbertorres/gfs

Or you can use something like PhysFS (https://icculus.org/physfs/) with a virtual filesystem.

[Rosme]

Oh wow, was I sleeping or what? Yeah you're right. My bad.

[dabbertorres]

Haha, I figured it was just a mistake! I just wanted to clear things up, just in case.

[fer_t]

Using POSIX and Windows API a filesystem abstraction is not that hard, a simple one could look like this:

Base class (.cpp)
Base class (.h)
Windows implementation
Unix implementation

[Nexus]

@fer_t: the implementation you showed provides a tiny fraction of the features of other filesystem libraries, and it's still less portable. One would end up re-implementing a lot from scratch, which somehow misses the point...

There are of course valid reasons for one or the other filesystem library, but not choosing Boost.Filesystem just because it's Boost might not be the best reason. At least exising solutions (also PhysFS) are well-tested, widely known and portable. With Boost, you can already get used to an API that will become part of the standard, probably with only few changes.

And of course it's another component in your game for which you don't have to spend time for development and maintenance...

[fer_t]

@Nexus I know that was a quick solution, I personally wait for C++17 (I already use C++14 functions in many projects, the only problem is the bad compiler support, at least if your users / devs use msvc), because I try to reduce dependencies.
And the linked "solution" is not designed to be used as a library, is simply a solution for the problem I had in that project, I only wanted to show that it is not that hard.

But you made a point: If you use a 3rd party library you save time.

[jamesL]

Using POSIX and Windows API a filesystem abstraction is not that hard, a simple one could look like this:

Base class (.cpp)
Base class (.h)
Windows implementation
Unix implementation

I am nowhere near the level of C++ of anyone else on this forum,
there are tons of stuff I don't know

so I have a question about this code

in this file
http://git.os-sc.org/TILES.git/tree/include/filesystem_windows.h

in the function
inline const char* platform_getHome()

there is this line
strcat(home, path)

is that a bug ?
is this even possible ?

[eXpl0it3r]

Why should it be a bug? Here is the reference for that function.

I'm not sure what getenv guarantees, but it might be better anyways to use strncat (if possible). For me personally that looks too much like C and I'd rather stick with boost or similar.

[jamesL]

Why should it be a bug? Here is the reference for that function.

I'm not sure what getenv guarantees...

yeah, the amount of memory returned by getenv is what I wondered about

specifically I was wondering about this (from the link you provided)
The behavior is undefined if the destination array is not large enough for the contents of both src and dest and the terminating null character.