Author Topic: File system functions (Read 8624 times)

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.

Laurent · « **Reply #1 on:** August 31, 2010, 02:57:13 pm »

That would be completely out of scope for SFML. There are already portable FS libraries, such as boost.filesystem for example.

doc · « **Reply #2 on:** August 31, 2010, 04:51:16 pm »

Quote from: "Laurent"

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.

Laurent · « **Reply #3 on:** August 31, 2010, 05:04:36 pm »

I know, but it's not a job for SFML.

Nexus · « **Reply #4 on:** August 31, 2010, 08:48:51 pm »

Quote from: "doc"

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.

doc · « **Reply #5 on:** August 31, 2010, 10:41:43 pm »

^^^
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.

Laurent · « **Reply #6 on:** August 31, 2010, 10:44:56 pm »

Quote

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

doc · « **Reply #7 on:** August 31, 2010, 10:59:10 pm »

^^
But without all those compiler dependent macros there will be no boost :lol:

Nexus · « **Reply #8 on:** August 31, 2010, 11:20:45 pm »

Quote from: "doc"

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?

Quote from: "doc"

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.

doc · « **Reply #9 on:** September 01, 2010, 12:44:53 am »

Quote from: "doc"

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

Quote from: "Nexus"

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?

Quote from: "Nexus"

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, which are thankfuly a programming joke

Nexus · « **Reply #10 on:** September 01, 2010, 08:38:37 am »

Quote from: "doc"

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...

Quote from: "doc"

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.

doc · « **Reply #11 on:** September 01, 2010, 10:43:33 am »

Then maybe I'll take a look and give boost another chance.

panithadrum · « **Reply #12 on:** September 03, 2010, 08:42:12 pm »

Quote from: "Laurent"

Quote
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?

Nexus · « **Reply #13 on:** September 04, 2010, 12:06:39 am »

Quote from: "panithadrum"

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.

pdusen · « **Reply #14 on:** September 04, 2010, 01:18:45 am »

There's a nice, detailed summary here.