File system functions

[graphitemaster]

Boost is a nice set of libraries, but I would never recommend them to anyone unless they're lazy, a FileSystem class is pretty simple to write, and should not be out of the scope for SFML at all. I had to write one awhile back for my 3d Engine, anyways if you're interested you can get it here:

https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/FileSystem.hpp
https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/FileSystem.cpp

you will need to do some editing to the Engine::Print and Tools::FormatString functions, and also some types which should not be hard.

Types::uint    = unsigned int
Types::uchar = unsigned char
Types::ulong = unsigned long

also what good is a file system without some type of compression system, without further ado here ya go a full GZip class requires ZLIB
https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/Compression.hpp
https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/Compression.cpp

[Nexus]

Boost is a nice set of libraries, but I would never recommend them to anyone unless they're lazy

You mean unless they don't want to reinvent the wheel. Why shouldn't one use existing libraries that have been tested and optimized over long time?

By the way, your code provides much less functionality than Boost.Filesystem and is not as portable. How can one iterate through all the files in a folder, for example?

There are also some severe mistakes in your code, such as neither overloading nor forbidding copy constructor and assignment operator. You access the address of the string's first element, where c_str() would be much more appropriate (and not implementation-defined). The use of variable argument lists is inherently error-prone and can't be combined with user-defined objects. Here, a operator>> would be much more powerful and safe. And maybe you should transform some returned ints into bools (the C functions must return int because there is no bool type in C).

[l0calh05t]

Do not "roll your own". The only reason to ever do so, is if you want to learn how to do it.

Boost is:

• Very well tested, by thousands of people using it in production code
• Licensed with a very permissible license

So there really is no reason not to use it. The most frequent "reason" people don't use it, is because they don't understand how all the "template magic" and "preprocessor tricks" work. Almost as bad as people who don't use the C++ standard libraries, for those "reasons"...

There are alternatives though, as in other libraries which you can use. For example there is POCO (http://pocoproject.org/) which, to many, looks a little "friendlier" than boost. The licensing is similar (actually... it's exactly the same ).

Specifically for filesystems for games, there is also PhysicsFS (http://icculus.org/physfs), which provides a full virtual filesystem. Sadly, it uses a C API, and the internals often use integers (with a *specified* size of 32 bits) for storing pointers, and pointer differences, which makes the whole thing 64-bit incompatible. Guys... do use size_t and ptrdiff_t, please they are there for a reason!