SFML community forums
General => General discussions => Topic started by: reduz on September 21, 2008, 06:03:04 pm
-
I see SFML doesn't hide the private scope of its classes, can't this create binary compatibility issues in case you want to change them across minor versions? (as in, symbol size changes won't link)
Usually most C++ libraries (such as Qt), to avoid this, allocate the private scope separatedly like this:
myclass.h
class MyClassPrivate;
class MyClass {
MyClassPrivate *p;
public:
void methods();
MyClass();
~MyClass();
}
myclass.cpp
class MyClassPrivate {
public:
member variables
};
MyClass::MyClass() {
p = new MyClassPrivate;
}
MyClass::~MyClass() {
delete p;
}
Well, hope this is of any use.
Cheers!
-
Using this idiom (which is called the pimpl idiom), while hiding the private details, also has some drawbacks. It makes the code a bit more complex, both to write and to execute. It's a good solution in some situations, but not for SFML (at least for now).
Anyway, even without the private members, SFML is not binary compatible across versions. Its public interface is still evolving a lot and is not stable enough yet. In other words, there's no minor version of SFML, only major ones.
But thanks for your feedback ;)
-
This is not good to know. I thought SFML being at version 1.+ had a stable binary interface.
So it means it's pretty much unusable under unix unless you link statically..
-
No, I'm sorry to tell you that SFML is not a mature and stable API. It's still young and will be improved a lot in the future. Maybe the 1.x versions should have been 0.x, you're right.
-
Oh ok, well,, so far I'm very impressed with it and with all the effort and while I'm sad to know i can't use it to replace SDL with it for now, I'll be looking forward to it becoming stable.
Cheers, and thanks for all the effort.
No, I'm sorry to tell you that SFML is not a mature and stable API. It's still young and will be improved a lot in the future. Maybe the 1.x versions should have been 0.x, you're right.