SFML community forums
General => Feature requests => Topic started by: doc on August 31, 2010, 02:19:16 pm
-
While simple file access can be handled in a portable way by standard C/C++ libraries, more advanced, but still essential functions like directory listing can not. On Windows you have to use FindNextFile(), on POSIX there's opendir() and friends. It would be nice to have features like that inside SFML.
-
That would be completely out of scope for SFML. There are already portable FS libraries, such as boost.filesystem for example.
-
That would be completely out of scope for SFML. There are already portable FS libraries, such as boost.filesystem for example.
It could be usefull for GUI toolkits dedicated to SFML. They wouldn't have to use external libs to bring "Save as..." dialog for example.
-
I know, but it's not a job for SFML.
-
It could be usefull for GUI toolkits dedicated to SFML. They wouldn't have to use external libs to bring "Save as..." dialog for example.
Boost is probably the library known by a big part of the C++ community. I know it's better to avoid any dependency, but Boost provides much other useful functionality and is already installed by many users. Especially at a GUI framework, the Boost libraries Function, SmartPointer or Serialization are very handy, if not required.
-
^^^
Yes I know, but for some reason I don't like boost and I am trying to avoid it. That's why I'm using SFML threads or mutexes instead of boost ones :) There must be something at it, since most libraries I have been using don't rely on boost also.
-
Yes I know, but for some reason I don't like boost and I am trying to avoid it
So you should switch to another language, because a big part of boost is going to be integrated to the next C++ standard ;)
-
^^
But without all those compiler dependent macros there will be no boost :lol:
-
Yes I know, but for some reason I don't like boost and I am trying to avoid it. That's why I'm using SFML threads or mutexes instead of boost ones :)
I think, the SFML network and thread functionality is more straightforward and easy to use, but allows probably less custom configurations. Generally, SFML aims at being beginner-friedly, while Boost contains many parts that require an advanced C++ knowledge. But several things are easy to use, nevertheless.
However, you shouldn't throw Boost into a single pot, it consists of different libraries written by different authors. Anyway, what exactly doesn't please you at the Boost libraries you've worked with up to now?
But without all those compiler dependent macros there will be no boost
What do you mean? Every library that wants to implement platform-dependent functionality beyond standard C++ in a portable way needs to use the preprocessor for conditional compilation. Even SFML.
Additionally, Boost tries to workaround some compiler bugs to support more, especially ancient compilers. For this task, it uses macros, too. Apart from the libraries where macros are just the most user-friendly way to provide a feature (consider BOOST_FOREACH or BOOST_STATIC_ASSERT). I don't know why this should be bad.
-
What do you mean? Every library that wants to implement platform-dependent functionality beyond standard C++ in a portable way needs to use the preprocessor for conditional compilation. Even SFML.
Yes, but I believe that most of detection should be left to configuration tools like CMake, jam, SCons, autotools etc
However, you shouldn't throw Boost into a single pot, it consists of different libraries written by different authors. Anyway, what exactly doesn't please you at the Boost libraries you've worked with up to now?
Additionally, Boost tries to workaround some compiler bugs to support more, especially ancient compilers. For this task, it uses macros, too. Apart from the libraries where macros are just the most user-friendly way to provide a feature (consider BOOST_FOREACH or BOOST_STATIC_ASSERT). I don't know why this should be bad.
I think it's because I have different doctrine.
For example, when fully legal C++ code doesn't compile because of bug in a compiler I wouldn't make workarounds. Don't harm good code, but rather swap to latter version or kill a compiler vendor :)
That user-friendly macros you mentioned are abusing a language in my opinion. It's one step from analog literals (http://www.xs4all.nl/~weegen/eelis/analogliterals.xhtml), which are thankfuly a programming joke :)
-
I think it's because I have different doctrine.
For example, when fully legal C++ code doesn't compile because of bug in a compiler I wouldn't make workarounds. Don't harm good code, but rather swap to latter version or kill a compiler vendor :)
In my own projects, I share your philosophy. But Boost has a broad userbase, and there are certainly many people benefiting from the support for older compilers. And I don't know if the code would be much more beautiful without... ;)
That user-friendly macros you mentioned are abusing a language in my opinion.
Hm, I wouldn't say its abusing, rather moving at the borders of the technically feasible. I find it very interesting that C++ is powerful enough to emulate not available language features like the foreach loop. However, some things like Boost.Lambda are even suspect to me (but I still like the idea, I just don't use the library). Have you taken a look at Laurents CAMP library? It points to the same direction: Making reflection, a non-existent feature in C++, possible.
But apart from that, there are many "orthodox" Boost libraries like Boost.LexicalCast. Boost even contains pathfinding algorithms like A*. I'm sure there is something that's even useful for you. :)
-
Then maybe I'll take a look and give boost another chance.
-
Yes I know, but for some reason I don't like boost and I am trying to avoid it
So you should switch to another language, because a big part of boost is going to be integrated to the next C++ standard ;)
Oh, that's interesting. When is it going to happen?
-
Oh, that's interesting. When is it going to happen?
A part of Boost (including Function, Bind, Random, Array) has already been introduced into the TR1 (Technical Report 1) in 2005 and will be integrated in the next official C++ standard along with some other Boost libraries. The next standard, often called C++0x, is probably going to be released in 2011. Further parts of Boost are proposed for the TR2.
-
There's a nice, detailed summary here (http://en.wikipedia.org/wiki/C%2B%2B0x).
-
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
-
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).
-
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!