Wiki - Spline doesn't compile with versions of SFML below v2.4

[QQ80]

SFML only introduced the LineStrip, TriangleStrip and TriangleFan enums in v2.4 (instead of LinesStrip, TrianglesStrip and TrianglesFan), and thus Spline doesn't compile in previous versions of SFML. However, the Setup page in the wiki only specifies to have SFML v2.

I know it's a very simple and minor issue but it spent me an hour trying to figure that out >_<

[QQ80]

Sorry if this is the wrong section to post this...

[Hapaxia]

You're absolutely right; the enum values were introduced in SFML 2.4 and the older ones were deprecated so using the newer ones automatically makes version prior to 2.4 unable to compile.

Some other classes may also be using the newer values whilst some other classes may be still using the older values. If so, they should be brought into alignment.

There are two possible solutions to this:

1. add in pre-processor code to use the correct one based on which SFML version is being used,
2. use the older, deprecated values as they seem to still compile with SFML 2.4+, or
3. just update the Wiki and force everyone to use SFML 2.4+

Solution 1 is probably the most logical but would require more maintenance.
Solution 2 risks the values stopping working at any time if and when SFML stops using them.
Solution 3 is the quickest and simplest solution but is clearly the most restrictive.

[eXpl0it3r]

SFML 2.x is guaranteed to be backwards compatible. So any version of SFML 2.x will work with the old values, but compilers may give out a deprecation warning.

[Hapaxia]

2.4's deprecations (methods, not the enum values) causes at least one compiler to fail to compile at all without specifically modifying the compiler settings. I don't think this can be considered "just a warning"; it forces newer values to be used as previously working projects using older values won't build without modification.

[Hapaxia]

Would you recommend, then, just using the older versions in this case?

[eXpl0it3r]

If a compiler defaults to error on deprecation warnings, then that's a compiler configuration issue and not a library configuration issue.

Personally, I'd just go with the latest version of SFML. Since I know that newer (and "stable") version of SFML are always better than older versions, there's really no point in sticking to an old SFML version.

But you're the maintainer of SelbaWard, so you'll have to make your own decision on who your target audience is. 😉

[Hapaxia]

I've had the discussion about SFML's deprecation "warnings" a couple of times already so I don't think I need to continue to press the issue; it's time to give up.

I agree that I don't think the older values should be used globally to "cover all bases". If the older enum values are used for "simplicity", older methods should be used too and that's not an option here.

That's solution 2 out then...
I guess now it's just whether to force people to use SFML 2.4 (which they really should be using anyway) with Selba Ward or to pollute Selba Ward's code with lots of preprocessor conditions.

[Hapaxia]

I chose solution 3 (preprocessing conditions to control use of deprecated SFML).
This allows Selba Ward to still be used with all SFML minor versions of SFML 2.

Fixed in this commit:
24b8fe4

[QQ80]

Wow! I didn't expect this much discussion to stem from a single version problem. I originally had the problem when I had just used the SFML dev libraries from the Ubuntu repositories, which are only at v2.3.2, but those things update sooner or later eventually anyways. So, I actually agree with @eXpl0it3r to always use the newest libraries, and thus to just update the wiki, to keep things neat.

As of this fix, this adds complexity, and if something similar happens in the future in SFML v2, there would have to be multiple defines of USE_SFML_PRE_2_X, which is hard to maintain.

But if I were to choose from making sure the right version of SFML is to be used, or to have code that just works no matter what, the latter option would be much more attractive.

[Hapaxia]

Thank you for bringing this to attention. Discussion is always good; it can help you focus on your direction and bring new ideas/perspectives to light.

I agree that the chosen solution is more work and potentially too complex in the future. However, owing to the fact that there are very few occurences of the changed parts in Selba Ward, it was an easy solution. I would presume that it's very rare that something will become deprecated in SFML - it's more likely that many things will deprecate at once - so won't cause too much extra maintanence.
That said, if it gets more complicated, I'll simply start using macros for some things (like primitive types) and the macros can be set once depending on the SFML version.
Thankfully, none of that is really exposed to the user so it just makes more work for me 😉

Although there are very few reasons that people should be using SFML pre-v2.4, I don't think Selba Ward should exclude those people just to save a little code. If SFML (v2.4+) considers itself backwards compatible to v2.0, Selba Ward will attempt to also be usable by the same.