|It does it by using the functionality of a global variable being initialized before main, in which case Laurent created a class and then instantiated that class for the sole purpose of initializing SFML.|
Is that really what it does? I haven't looked at the source that closely. If that is indeed the case, I would call that a terrible design decision as global anything (especially in C++, especially in a lib) is problematic. I can think of at least 2 other ways to solve this problem without a global.
Automatic initialization is not a bad thing... in fact you're right it's a C++ feature and a user would expect it. But it's all in how it's done.
Do you know specifically where this global is? This is worth filing a bug report, IMO.
I might look for it later today if I find the time.
|However, I do feel that the classes are less direct when dealing with things like state management, how it handles flexibility, or how each class/struct talks to each other, leading to a confused design. I also believe it is this way because of the nature of C++ and what is now common as C++ design. |
This is where you start to lose me. The interactions between classes are near identical to what I'd expect in a C lib (only classes instead of struct pointers).
Your example of the global context initialization was excellent.
Do you have a similar example to illustrate confused class relationships?
EDIT: bah... sf::Context was your example. ...Long day...
|You wouldn't actually know this and you can't set them either if the context is of major version 3 or above.|
I haven't had any problem using OpenGL 3.3 with SFML creating the context... and I've been using SFML 2.0 for a while. Though as someone else mentioned this was a bug in the Linux port and has since been fixed in 2.1?
I'll write this point off as N/A.
|I have no idea how you're getting that I'm a C evangelist.|
It was the way you were phrasing your earlier posts. All of your qualms are design issues... not language issues... yet you present them as language issues.
I still think you're misguided in thinking that these problems are inherently C++ related. If there's any
language where multiple designs are prevalent, it's C++. I'm not saying that like it's a good thing... I'm just saying. =P
That said... I would certainly agree that designing a good API in C++ is harder than designing a good API in C. Mainly because more is expected of you if you use C++. Example: std::string vs. cstring's strxxx functions. I'm sure std::string was certainly harder to design and write.
|Also, [sf::Context] does require a window (a dummy), it's just implicit. A context without a window doesn't make sense. Which is actually my point. |
I can certainly imagine uses for a context with no window... so it makes perfect sense to me.
A commandline tool to render scenes to .png files, for example. Could be useful for batch animations and/or movie creation.
Whether or not OpenGL requires a window to be created is irrelevent from an API design standpoint (for a lib like SFML) -- there's no reason to require it.