Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Conditional C++11 Support  (Read 26358 times)

0 Members and 1 Guest are viewing this topic.

Cornstalks

  • Full Member
  • ***
  • Posts: 180
    • View Profile
    • My Website
Re: Conditional C++11 Support
« Reply #15 on: July 13, 2014, 03:07:22 am »
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
Cool. Well I just learned something new! Thanks for that link.

Welp, carry on with the discussion here!

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Conditional C++11 Support
« Reply #16 on: July 13, 2014, 03:13:50 am »
See 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".

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Conditional C++11 Support
« Reply #17 on: July 13, 2014, 03:26:44 am »
...
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.

Kojay

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: Conditional C++11 Support
« Reply #18 on: July 13, 2014, 05:53:36 am »
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.

Ruckamongus

  • Jr. Member
  • **
  • Posts: 67
    • View Profile
Re: Conditional C++11 Support
« Reply #19 on: December 31, 2014, 04:30:59 pm »
Has there been any talk amongst the staff on the official verdict of C++11 (14?) usage in SFML 3?

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: Conditional C++11 Support
« Reply #20 on: December 31, 2014, 05:10:21 pm »
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.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10159
    • View Profile
    • development blog
    • Email
Re: Conditional C++11 Support
« Reply #21 on: December 31, 2014, 05:21:12 pm »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

SLC

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Conditional C++11 Support
« Reply #22 on: December 31, 2014, 06:11:10 pm »
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.
« Last Edit: December 31, 2014, 06:13:42 pm by SLC »

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1485
    • View Profile
    • Blog
    • Email
Re: Conditional C++11 Support
« Reply #23 on: January 06, 2015, 11:28:52 pm »
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.

SLC

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Conditional C++11 Support
« Reply #24 on: January 13, 2015, 12:12:50 am »
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.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10159
    • View Profile
    • development blog
    • Email
Re: Conditional C++11 Support
« Reply #25 on: January 13, 2015, 12:54:03 am »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Gambit

  • Sr. Member
  • ****
  • Posts: 283
    • View Profile
Re: Conditional C++11 Support
« Reply #26 on: January 13, 2015, 02:45:29 am »
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.

SLC

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Conditional C++11 Support
« Reply #27 on: January 13, 2015, 03:14:20 am »
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.

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1404
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Conditional C++11 Support
« Reply #28 on: January 13, 2015, 03:27:08 am »
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 ;).
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1404
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Conditional C++11 Support
« Reply #29 on: February 26, 2015, 02:21:57 pm »
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).
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).