SFML community forums
General => General discussions => Topic started by: eXpl0it3r on July 05, 2014, 01:05:11 pm
-
To not further spam this one issue (https://github.com/SFML/SFML/issues/129) - I already cleaned it up a bit - I thought, I open a thread here.
The subject at hand is, whether we should rewrite some things in SFML to place in conditional support for C++11, way before we most likely fully move to C++11 with SFML 3. And if we do so, what should be included as conditional support.
Points that should not be discussed here:
- How much of C++11 which compiler supports. - We are aware that not all compilers support everything, but that's the reason why it would be conditional.
- Detailed discussion on how something could be implemented. - This thread isn't here to discuss how the implementation should look like in detail.
Point that should be discussed here:
- Should SFML implement conditional C++11 support?
- Should SFML move to unconditional C++11 support at one point?
- What feature should be considered for the conditional C++11 support?
Important point that have already been made:
Supporting C++11 will allow nice additions, but it won't replace many things. After this change, I think you'll still be able to write a program that uses mostly C++98, if you want to.
Regarding backward compatibility and maintenance of older versions, it's true that we'll move forward and focus on improving the latest versions, but I think it would be wise to spend some time back-porting bug fixes to the latest revision of the previous major version (i.e. 2.x after 3.0 is out). If we want SFML to be used in the real world, and not only for short-term small projects, we have to care a minimum about backward compatibility, and not abandon users who would not stick to the latest version. So where should the limit be? I don't know, but this should definitely be discussed.
After a bit of research, it seems that I won't be able to make a single build of SFML that both supports C++03 and C++11. Mixing both can lead to binary incompatibilities.
In this case, C++11 cannot be added conditionnally, we'd have to wait until SFML completely switches to C++11 (not before SFML 3).
- initializer lists
- r-value references (move semantics)
- some of the constructors can be made constexpr really easily (for example, sf::Color, sf::VectorN, sf::Rect).
- sf::String could support the new Unicode character/string types.
-
From a development point of view, I think people underestimate the amount of maintenance that would be required to have conditional C++11 support, i.e. separate builds for C++03 and C++11 which is the only feasible way to provide such support.
Either really ugly boilerplate macros would have to be inserted all over the place which would make reading and modifying the files a pain (go try to read through some boost headers that support multiple language variants) or the codebase would have to be split into a C++03 and C++11 implementation, which would mean a lot of code duplication and possibly having to modify multiple files to fix even trivial bugs.
Let's go through the reasons why we would still need C++03 support:
- Currently used compiler doesn't support C++11
- Platform does not support/provide a C++11 compatible compiler
The first point is a very commonly heard one. The assumption is that users might not be using a C++11 compatible compiler (yet?).
There are 3 mainstream compilers that we should aim to support 100%:
- Visual Studio
- GCC (includes MinGW)
- clang
I think it is obvious which users would have issues compiling C++11 code.
GCC has had somewhat usable C++0x support since 4.6. 4.7 almost completed support for all language features and 4.8 completed support for all language features. I think it is safe to assume that any serious GCC user should currently have a C++11 capable compiler, even if not complete. I can't think of any compelling reasons why a GCC user would still be limited to a non-C++11 capable compiler outside of company politics.
clang... no debate here, it always supported a large subset of C++11 and is also currently complete.
Visual Studio... This is probably the primary reason why we are even considering keeping SFML C++03 compatible. I can understand that some managers don't fully understand the benefits of migrating to VS2013 or that platform limitations (i.e. Windows XP) prevent such an upgrade from taking place. But let's be honest, besides having to support old hardware that might only be able to run XP (which is EOL by the way), I can't see any other reason to stick with Windows XP as the platform to run applications on. Any truly new machine you would acquire these days would have an up-to-date Windows pre-installed on it if it even came with Windows pre-installed.
If you are using a current Windows and have hardware that can support VS2013 and yet still use an older development environment, either you've been working on a project for a long time and don't want to migrate mid-way, or you prefer supporting long-lived products using the original environment they were developed in (I can fully understand this). If you started a project after VS2013 was released and refused to migrate beforehand, then I really urge you to reconsider doing so. From personal experience, I've noticed myself become far more productive when using C++11 features effectively.
So to summarize, the only projects that I can understand need continued support for C++03 are those which:
- Were started before C++11 was used seriously
- Still need to be supported
- Might be limited by platform restrictions
- Were developed in Visual Studio
All of this means that SFML only really needs continued C++03 support for those users who have to provide support for their long-lived products that were made with SFML. This does not mean that those users would require the same support for newer products.
Taking into consideration that SFML only needs to maintain the stability of said products, this means that new features need not be added to old versions and platform specific bugfixes that do not target the user need not be added to old versions either. This would mean that SFML can progress with C++11 support as a requirement for all newer versions while backporting only necessary fixes to C++03 branches for the users that require them.
The effort required for backporting fixes to an older version of SFML would be much lower than simultaneously maintaining C++03 and C++11 builds. As already mentioned above, not even all bugfixes would have to be backported since only a small subset of users are actually truly limited to using C++03 and most of them as stated above as well, work on the same platform (Windows, Visual Studio). I would be happy to port them myself if requested to do so by someone who really needs them (meaning no "Can you port the fix back so I can continue using Ubuntu 8.04 please"). The effort of porting every now and then and working on a single C++11 build is much less than that required to maintain C++03 and C++11 at the same time.
I say we move on to full C++11 support in 3.x while dropping C++03 support for all future versions. Backports of fixes can be made when they are essential, but otherwise not. Everything becomes EOL at some point. Windows XP just went EOL in April, Ubuntu non-LTS goes EOL 1.5 years after release, Debian non-LTS goes EOL after 3 years, OS X... EOL after 2 releases? And SFML... EOL after 2 years... sounds reasonable to me.
P.S. My sincere apologies to any professional programmers and/or managers that I may have upset with this post. I was trying to be as objective as possible and posted everything in good conscience.
-
It should also be noted that while some C++11 features provide additional optimizations or convenience for those who use it, others have a deeper influence on the design of the library. When providing only conditional C++11 support, then:
- sf::Thread, sf::Mutex, sf::Lock and sf::ThreadLocal cannot be removed in favor of their standard counterparts
- There will be further API restrictions, e.g. it's not possible to store non-copyable objects in STL containers or to return them from functions, and we need the namespace idiom to scope enumerations
- A refactoring and simplification of several internal parts, especially regarding resource and thread management, will be prevented due to the lack of thread_local, std::unique_ptr, std::thread, std::mutex, std::atomic.
The price to pay for conditional support is, besides the points mentioned by binary1248, an unnecessarily big API and a more complex and potentially less robust/portable implementation.
-
I'd be all for SFML 3 being C++11 only. Way I see it, SFML 2.x is perfectly usable when targeting-C++11 compilers and since C++11 aids in writing code that is simple and fast, SFML 3 would benefit from it.
Though I know this not the place to discuss missing features, there are still issues with C++11 implementations that could cause problems with compatibility. I'd argue SFML 3 would need some type of build server setup, even if it's just Travis-CI (https://travis-ci.org/) and AppVeyor (http://www.appveyor.com/) to cover clang, g++ and visual studio, just because otherwise at some point the build is more likely to be accidentally broken for one of the compilers if we enable C++11 support.
-
Should SFML implement conditional C++11 support?
No, implementing optional support means maintaining duplicated code and adding too much complexity to the code base.
Should SFML move to unconditional C++11 support at one point?
Yes, I totally agree with binary1248's view on this. There needs to be a cutoff point where all new development goes forward with full C++11 support while only back porting required fixes (no new features) to the old code base that is non C++11.
What feature should be considered for the conditional C++11 support?
Same as the first question, I don't think there should be any 'conditional support' in the SFML code base.
If we go ahead with C++11 support it should begin unconditionally with SFML 3 while keeping the 2.x code base compatible with non C++11 compilers.
I'd argue SFML 3 would need some type of build server setup
Tank is already working on a BuildBot build farm.
-
Though I know this not the place to discuss missing features, there are still issues with C++11 implementations that could cause problems with compatibility. I'd argue SFML 3 would need some type of build server setup, even if it's just Travis-CI (https://travis-ci.org/) and AppVeyor (http://www.appveyor.com/) to cover clang, g++ and visual studio, just because otherwise at some point the build is more likely to be accidentally broken for one of the compilers if we enable C++11 support.
I think we don't have to go all out insane on the C++11 8). Working on SFGUI and SFNUL already gave me a bit of insight into what is and isn't supported by gcc, clang and VC. Most of the common features that have also gained public attention are supported by all of them, whereas features that not many know of and therefore not miss (such as lack of complete move support) are only unsupported by VS. GCC's standard library is also still incomplete in MinGW (and probably will be for a while), so that is also something to keep in mind.
-
I'm just saying, it's still a more fractured a 'marketplace' than C++03 was. If SFML allows C++11, then there is a need to declare which versions of the 'main' compilers/libraries to support. g++ 4.7? 4.8? 4.9? clang 3.3? clang 3.4? VC12? VC11? VC12 update? And there's a need to then not use features that break building on those compilers onwards.
For just not supporting C++11, this wasn't much of an issue since C++03 was well-established and fully implemented by the compilers. For C++11, it seems to me the complexity of ensuring support does increase. Now I'm still in favour of it, pros outweight cons, but I'd encourage appropriate steps taken to mitigate that complexity.
-
Please don't make this thread again about which compiler supports what.
-
Yeah, I'm trying to avoid that (edited that post several times xD), but it's difficult to discuss the risks in both without mentioning the risk that it could be easier break something for only one compiler when supporting C++11. And that maybe at present there's not enough support for things like thread for a lot of the benefits people are talking about to actually be usable. In the future that may change.
So, essentially, the decision of conditional or unconditional to me seems to be based on how much of the kool-aid can we drink, or expect to drink? A light-weight touch could allow for unconditionalness (no move constructors or unique_ptr? 2008 called), but would make most of the benefits people talk about for going unconditional (std::thread, unicode literals) unusable without dropping support for various toolchains and it seems like most of those lightweight features are the easiest ones to make conditional.
-
It will make more sense to look at the specific C++11 features once we actually switch -- at that time, the world will look different, and compilers may support much more than today. And of course, the list of new language and library features that SFML will use is not definitive. So, let's not look at specific features and compilers in this thread -- after all, this is what eXpl0it3r explicitly asked for in his initial post.
It would be good to gather general points for or against a mandatory C++11 SFML. Since there have already been loads of arguments in favor of making C++11 unconditional, it would be interesting to see the other point of view.
That is, people who have justified reasons against mandatory C++11 (most probably professional developers bound to a specific environment), and how they imagine progress under that constraint.
-
SFML 3 is obviously the future of SFML. However, this future won't happen overnight. Until it's ready we can expect a lot of things to change.
Having a conditional support will only slow us down beside making things more complicated for everybody else. If people need to stick with old compiler, then SFML 2.x (which is already a good product IMO) is the solution for them.
C++11 is already 3 years old and will be older when SFML 3.0 is released. I see no good argument to keep living in the past and not take advantage of the "new" features.
-
Should SFML implement conditional C++11 support?
If it can be done without too much trouble, then yes, why not?
If it is going to be too much of a pain to support and maintain, then don't bother. SFML is already perfectly usable in host projects written in pure C++11, so we can wait until SFML can go full-blown C++11 in 3.0 to reap the benefits then.
That's not to say that it wouldn't be nice to be able to enable a few C++11 features in SFML before 3.0, but it's not absolutely crucial.
Should SFML move to unconditional C++11 support at one point?
Yes!
There's no doubt in my mind about this one. C++11 is a (almost) a completely new language when compared to C++98/03 and it's a much better language. Of course SFML should adopt it. Here are some reasons (obviously incomplete list):
- Getting "with the program" and adopting modern C++ is an important signal to send to both users and contributers that SFML is still a project that's alive and well.
- Things like shared_ptr, unique_ptr, weak_ptr and move semantics make it so much easier to make the RAII (http://www.bromeon.ch/articles/raii.html) argument. Which is a good thing.
- Features like the range based for loop make code much more readable (and it can even be faster than traditional loops).
- There are so many nice new algorithms, containers and more to take advantage of in the new standard library/STL, it would be a shame for SFML not to take advantage of them (just to mention a few: std::unordered_map, std::copy_n, std::thread, std::future, std::iota, std::function, std::to_string and much, much more).
- Things like constexpr, static_assert, nullptr, override/final keywords, auto and decltype just make ones life much easier, less error prone, simpler and more readable.
- Not having to declare function objects potentially a long way from where they are used and being able to just write a lambda directly where needed is so nice.
- I'm sure move semantics with their potential performance improvement could be exploited in a few places within SFML for everyones gain.
- Uniform initialization/Initializer lists could probably be used to simplify parts of the API.
In my opinion there's absolutely no reason not to adopt C++11 as much as possible as soon as possible. It's a much better language than C++98/03 ever was and it has so much potential to simplify the code, simplify the API and make it safer. It can provide some performance improvements if used correctly and - it's simply the future.
What feature should be considered for the conditional C++11 support?
If you want to keep it really simple, then just add a CMake switch to enable whatever compiler flags are needed (like std=c++11 for GCC and Clang) to enable C++11 features in the compiler while building SFML. Doing nothing else will at least let the compiler take advantage of C++11 support in the standard library parts that SFML uses internally and whatever other C++11 optimization tricks it may have up its sleeve. Doing nothing but this will provide some (arguably minor) improvements to people using a C++11 compiler with SFML and won't place any undue maintenance burden on the SFML team.
Going a bit further (still only considering conditional C++11 support, not what we'll hopefully have in 3.0); it would be nice if we could get applicable code marked with constexpr and maybe add override to all virtual functions. That should be doable with a bit of macro magic. Making all code that deals with null pointers use nullptr would also be nice and should again be fairly trivially doable conditionally. Proper marking of relevant functions with noexcept would also be nice. I guess it would also be reasonably simple to implement move constructors and move-assignment operators for classes where it makes sense and just conditionally leave them out in a C++98/03 build.
-
If you want to keep it really simple, then just add a CMake switch to enable whatever compiler flags are needed (like std=c++11 for GCC and Clang) to enable C++11 features in the compiler while building SFML. Doing nothing else will at least let the compiler take advantage of C++11 support in the standard library parts that SFML uses internally and whatever other C++11 optimization tricks it may have up its sleeve. Doing nothing but this will provide some (arguably minor) improvements to people using a C++11 compiler with SFML and won't place any undue maintenance burden on the SFML team.
You can already add flags when configuring the CMake file. Compiling with C++11 should generate default move contructors wherever possible.
-
You can already add flags when configuring the CMake file. Compiling with C++11 should generate default move contructors wherever possible.
Although most of the classes in SFML have user-defined constructors, which means no other constructors are auto-generated (including move constructors).
-
User-defined copy constructors (which isn't the case to my knowledge)? Because otherwise it's not a problem.
See en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor (http://en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor)
-
User-defined copy constructors (which isn't the case to my knowledge)? Because otherwise it's not a problem.
See en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor (http://en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor)
Cool. Well I just learned something new! Thanks for that link.
Welp, carry on with the discussion here!
-
See en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor (http://en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor)
There are rules which is good. They are complex which is not so good.
Personally I prefer a simple rule: If I define any constructors/assignment/move operators then I'll explicitly list the rest as either "= default" or "= delete" (as private, protected or public as apropriate) depending on what I want.
That way I won't have to worry about memorizing the complex rules (and getting them wrong in some subtle situation with hard to debug problems to follow) I'll just be explicit and tell the compiler "I don't care what you would have done, this is what I want".
-
...
Visual Studio... This is probably the primary reason why we are even considering keeping SFML C++03 compatible. I can understand that some managers don't fully understand the benefits of migrating to VS2013 or that platform limitations (i.e. Windows XP) prevent such an upgrade from taking place. But let's be honest, besides having to support old hardware that might only be able to run XP (which is EOL by the way), I can't see any other reason to stick with Windows XP as the platform to run applications on. ...
First of all let me say that I'm not advocating doing anything to keep WinXP support alive. As far as I'm concerned it can't die soon enough.
That being said; VS 2013 does support WinXP. You can target WinXP SP3 with the msvcr120 runtime and it works just fine. Where I work we are (unfortunately) forced to keep supporting Windows XP (SP3 minimum) for parts of our product, but we do that with VS2013 (and using C++11 features in the code) without problems.
-
There are rules which is good. They are complex which is not so good.
Personally I prefer a simple rule: If I define any constructors/assignment/move operators then I'll explicitly list the rest as either "= default" or "= delete" (as private, protected or public as apropriate) depending on what I want.
That way I won't have to worry about memorizing the complex rules (and getting them wrong in some subtle situation with hard to debug problems to follow) I'll just be explicit and tell the compiler "I don't care what you would have done, this is what I want".
Then it would not be possible to compile pre-C++11 code with the flag and get the benefits for free (as you suggested yourself!).
Similar rules already applied with the copy constructor and assignment and the rule of three was the guide to follow, now become rule of five/zero (http://en.cppreference.com/w/cpp/language/rule_of_three) . The crux of it is do you need a hand in the class' resource management? If so, write copy/move/dtor yourself, else do not. The constructor(s) of the class should not be lumped in with the rest.
Yes, there are tricky scenarios where what is being generated makes for interesting puzzles. But i) avoid them ii) it's unlikely a mistake will result in a hard-to-debug problem; ie if you thought a move ctor was generated but is not, worst case is that the objects are getting copied instead, which should be noticeable in performance. Or if a copy ctor wasn't generated either, you 'll get a compile error.
-
Has there been any talk amongst the staff on the official verdict of C++11 (14?) usage in SFML 3?
-
In my long experience lurking in this forum and subscribing to the github repo, I don't think I've ever seen the SFML team conclusively say "we will do X in version Y." Typically the day they actually make a design decision like that is the same day the implementation gets merged to master.
Though I would be very surprised if SFML 3 was not full C++11.
-
SFML will make use of C++11 start from version 3.0. How exactly it will be implemented and how much of C++11 will be exposed in the API itself, is unclear.
We currently have enough other issues to fix in 2.x and thus the development on 3.0 hasn't started yet.
-
While C++11 won't make huge impact on SFML itself. I'm very sure (certain actually) that C++11 will make a significant difference in the development of the application in which SFML is/will be embedded.
Sadly for me I've started to learn C/C++ when C++11 was widely available and I've found that going back to older C++ makes development much harder (at least for me). I just couldn't see my self working with legacy C++ code and enjoy doing so.
I have to say that C++11 is the only thing that made me love programming with C++ while seeing others complain that C++ is a horrible language (those dynamically typed language lovers that waste 25% code checking if they work with the correct type).
I'd love to see SFML going for C++11 but until that happens try at least to get a stable legacy C++ version that is more or less stable enough to last for a long period and to allow developers to migrate their software. And if possible to even maintain it afterwards as a legacy option for those in need of such library.
C++ is definitely going through a "revolution" on whether developers should move to C++11 or keep the legacy C++ code. And that's mostly because of compiler and platform support for the new standard. At least that's how I see things.
-
Maintaining one SFML version is already a lot of work. I don't think that a legacy version in parallel is possible in any way.
Personally I don't really see what the issue is anyway. C++ is moving on, there is no real reason not to use C++11,except compiler limitations.
There is always a compromise.
-
Maintaining one SFML version is already a lot of work. I don't think that a legacy version in parallel is possible in any way.
Doesn't have to be official or obligatory to maintain a legacy version. But just to keep it there as an "unofficial" version that is still maintained for the sake of compatibility.
But yes I agree with you that migration to C++11 should be a top priority task for projects that could take advantage of it's features and have the possibility to do so.
-
Doesn't have to be official or obligatory to maintain a legacy version. But just to keep it there as an "unofficial" version that is still maintained for the sake of compatibility.
If unofficial or official doesn't matter, because the workload is the same, regardless of the label you put on it. ;)
I mean if someone in the community wants to maintain a none C++11 version they can do that, the license explicitly allows that, but I think the SFML Team itself should use whatever little resources they have on going forward.
-
I dont think there is a need for a legacy (Non C++11) version. You can still use C++98 with C++11, and if you dont have access to a compiler that allows C++11, I'd suggest updating.
-
I dont think there is a need for a legacy (Non C++11) version. You can still use C++98 with C++11, and if you dont have access to a compiler that allows C++11, I'd suggest updating.
I'm quite comfortable using C++11. Actually it's the only thing that I use. I'm trying to use the latest version that I can. Currently I'm using MinGW-w64 x32 4.9.2 and I can't wait for when 5.0 will become widely used.
I was actually referring to those who can't use such software. But never mind that.
-
I was actually referring to those who can't use such software. But never mind that.
There will always be those interesting people/organizations that somehow manage to have a compiler that isn't able to build your code. For all we know, some might still be running compilers that can't even build SFML 1.6. We have to draw the line somewhere eventually or we will never move on.
C++11 support is considered so widespread now, that there really isn't a reasonable excuse not to have a C++11 capable compiler besides having to support legacy software. In that case, they wouldn't be using newer versions of SFML anyway, so that fits the picture as well.
The ones who actually do get forced to upgrade because of SFML should be thankful that we made them do it. After a few months they will realize that it wasn't such a bad idea after all ;).
-
Bump.
Over time, my opinion has slightly changed. I am currently of the opinion that we should focus our efforts on clearing out the tracker. Once there really is nothing worthwhile left to do for SFML 2.x we can consider starting work on SFML 3, at which point we will be able to fully take advantage of C++11. Adding conditional C++11 support in 2.x would incur so much overhead that it might probably unnecessarily delay the start of SFML 3 development (which we agreed on will be full C++11).
-
I thought we already agreed on not introducing conditional C++11 support, since it would alone create a lot of work for nearly no gain.
And I agree about the tracker. As long as we still have basic bugs lying around or simple features, we shouldn't start creating one of the bigger construction sites.
-
I thought we already agreed on not introducing conditional C++11 support, since it would alone create a lot of work for nearly no gain.
Why is #129 (https://github.com/SFML/SFML/issues/129) still open? ;D
-
Because it turned into "Full C++11 support", but I guess you can also close it and open a dedicated issue. :)
-
I think contrary to #129, taking C++11 into account when writing SFML 3 isn't really an "issue" that you can tackle on its own. It's something like a coding/design/implementation guideline that should be taken into consideration.
I'll close #129 and won't make a new issue regarding full C++11 support in SFML 3, it just doesn't make sense.
-
SFML 3 won't be a full rewrite from scratch, we'll have to convert existing code to C++11 so in my opinion it is a task.
-
I agree that it is a task, but I don't think it fits with the rest of the issues on the tracker, which are either bug reports or requests for new features. It is something we will do while working on SFML 3. We also don't have issues for "Correct whitespace errors" or "Correct spelling mistakes" do we? ;)
-
Maybe we should create tasks such as "add move construction / assignment", "replace sf::Thread with std::thread", etc. because if we just adapt the code when we see something that can be changed, we'll leave SFML in an inconsistent/messy state.
-
The page Roadmap 3.0 (https://github.com/Bromeon/SFML-Team/wiki/Roadmap-3.0) could be used to keep such tasks.
-
I'll leave formulating the task list to you then. ;D
-
Migrating a C++98 codebase to C++11 (or C++14) can be a big task. But I've personally found that using Clang Modernizer (http://clang.llvm.org/extra/clang-modernize.html) can be a nice first step in the right direction.
It is not perfect and only supports a limited number of transformations, but I've found it to be a great starting point for legacy codebases.
Maybe check it out when you start work on SFML 3 ? :-)