C++11. To be or not to be?
by Andrey Syrokomskiy · in Technical Issues · 02/02/2014 (1:11 pm) · 12 replies
On one of commit began to discuss about allow to use the standard C++11. It's strange, when think about it: (1) outside 2014 and (2) without modern solutions the Torque3D to stuck in an Y2K :(
I quoted below and propose to continue to consider here.
LuisAntonRebollo
DavidWyand-GG
timmgt
DavidWyand-GG
dottools
I quoted below and propose to continue to consider here.
LuisAntonRebollo
Quote:Some features of c++11 as "auto", are supported in VS2010.
Currently the generator project have support for VS2008, would have to discuss whether it is time for deprecate.
Will the new committee decision, to lift the ban on c++11.
My personal opinion is YES to c++11.
DavidWyand-GG
Quote:Don't worry guys -- we won't just merge in a Pull Request that requires it. We won't move onto C++11 without it being a conscious effort. The reasons for and against it across multiple platforms and compilers would need to be considered.
What I would recommend is that any Pull Request that has been written to require C++11 to be rewritten to not require it. Unfortunately, that looks like a number of them lately.
timmgt
Quote:I ended up just ditching 2008 standard for 2013 express. I havent seen any issues with using it instead of 2008 yet other than I had to merge the other pull request by signmotion to get it to compile. Figured since so many people are using C++11 I might as well update if express handles what I need.
DavidWyand-GG
Quote:I should probably clarify my last statement. Right now my statement is true, but it will ultimately be up to the new people that have write access to the repo to decide. I can offer my opinion of each Pull Request if asked, and may offer an opinion even if not asked. :) I'm using T3D on my own personal projects after all, and will continue to have a future interest in it. But we can't both give autonomy to the new group and then also require that they check in all decisions with GG, so the decision will have to be theirs to make.
dottools
Quote:My problem with jumping the gun on C++11 is that you've just completely alienated everybody who doesn't have the latest Visual Studio and other development tools simply because of their work requirements. Not everybody can afford to upgrade to Visual Studio 2013. Myself I'm currently stuck with Windows XP because of embedded development tools issues and latest Visual Studio isn't supported on that OS. So I'm out of luck and so is anybody else that uses Visual Studio 2008 to 2010.
About the author
#2
You keep mentioning this! :) How would such a big change be committed? As smaller parts? Like, replace String in one commit, then Vector in a separate commit?
02/02/2014 (7:43 pm)
I guess I'd like to use lambdas and (in some rare cases) auto, but more than that - I'm not sure. You'd break compatability with a lot of (not so old) older environments.Quote:
That said, I think the main reason T3D is 'stuck in Y2K' is not lack of C++11 adoption, but lack of std:: adoption :P.
You keep mentioning this! :) How would such a big change be committed? As smaller parts? Like, replace String in one commit, then Vector in a separate commit?
#3
To me, C++11 is a bunch of new things that gives plain old C++ some handy shortcuts that other languages already have. My main issue with auto is that it hides what is going on from the programmer. Ignoring the issue of excluding people for the moment, if we were to make VS2013+, Vista+ as the minimum requirement for T3D then perhaps I could live with it. But if we're (as a community) looking to have T3D run on multiple platforms, all it takes is one compiler on one platform to interpret things differently in a critical area to mess you up. Cross-platform development is hard enough as it is, especially when you want to network them.
As an engine programmer I prefer things less hidden and to minimize cross-platform hassles. Anyone would, of course, be free to pursue whatever path they choose for their own game code.
Anyway, those are my thoughts for the future maintainers of T3D.
- Dave
02/02/2014 (9:22 pm)
My thoughts: Why does this set of Pull Requests need to be written using C++11? What is special about C++11 that the issues these Pull Requests are trying to solve cannot be done without it? Why is now the right time to force anyone that wants to use T3D to switch their build environment, or to force them to move on if they won't/can't?To me, C++11 is a bunch of new things that gives plain old C++ some handy shortcuts that other languages already have. My main issue with auto is that it hides what is going on from the programmer. Ignoring the issue of excluding people for the moment, if we were to make VS2013+, Vista+ as the minimum requirement for T3D then perhaps I could live with it. But if we're (as a community) looking to have T3D run on multiple platforms, all it takes is one compiler on one platform to interpret things differently in a critical area to mess you up. Cross-platform development is hard enough as it is, especially when you want to network them.
As an engine programmer I prefer things less hidden and to minimize cross-platform hassles. Anyone would, of course, be free to pursue whatever path they choose for their own game code.
Anyway, those are my thoughts for the future maintainers of T3D.
- Dave
#4
Sorry, Dave, but standard C++11 is not just "a bunch of new things that gives plain old C++ some handy shortcuts". Yes, modern standard allows to reach more generic code (lambdas, initializer lists, auto, range based loop, override / final, typed enums etc.). But also makes code on C++ faster on the compiletime (static asserts, type traits, extern templates) and runtime (move semantic, threads, mutexes, condition variables, future, smart pointers etc.).
So as not to speak without proof - https://testbit.eu/2013/cpp11-signal-system-performance
I have be interested to hear, how "inline assembly" are consistent with the "minimize cross-platform hassles".
02/03/2014 (12:04 am)
Quote:@Dave: As an engine programmer I prefer things less hidden and to minimize cross-platform hassles.Cocos2d-x: multiplatform engine on C++11. It does work very good.
Sorry, Dave, but standard C++11 is not just "a bunch of new things that gives plain old C++ some handy shortcuts". Yes, modern standard allows to reach more generic code (lambdas, initializer lists, auto, range based loop, override / final, typed enums etc.). But also makes code on C++ faster on the compiletime (static asserts, type traits, extern templates) and runtime (move semantic, threads, mutexes, condition variables, future, smart pointers etc.).
So as not to speak without proof - https://testbit.eu/2013/cpp11-signal-system-performance
I have be interested to hear, how "inline assembly" are consistent with the "minimize cross-platform hassles".
#5
Compiler support. It sure is better nowadays, but looking at some recent compiler support tables its still not 100%. I've heard that console support for C++11 is still pretty dire, but if you are making a PC, iPad, or Android game you're mostly fine.
Use case. Is there a real use case for C++11 features? The only good thing I can see is support for variadic templates which would help with the mess of the engineAPI function binding code. Other things like lambdas feel more like you need to design your code from the ground-up to use them effectively.
Its the new shiny thing (relatively speaking). Programmers like new shiny things, but don't always know how to use them effectively leading to poorly designed code. Using C++11 for no reason other than "Its not something from Y2K" is a bad idea since it turns the engine code into more of a modern fashion statement than a trustworthy, useable codebase.
02/03/2014 (3:02 am)
Problems I see with C++ 11.Compiler support. It sure is better nowadays, but looking at some recent compiler support tables its still not 100%. I've heard that console support for C++11 is still pretty dire, but if you are making a PC, iPad, or Android game you're mostly fine.
Use case. Is there a real use case for C++11 features? The only good thing I can see is support for variadic templates which would help with the mess of the engineAPI function binding code. Other things like lambdas feel more like you need to design your code from the ground-up to use them effectively.
Its the new shiny thing (relatively speaking). Programmers like new shiny things, but don't always know how to use them effectively leading to poorly designed code. Using C++11 for no reason other than "Its not something from Y2K" is a bad idea since it turns the engine code into more of a modern fashion statement than a trustworthy, useable codebase.
#6
Inline assembly is already there, and it's been there since V12 and Tribes. It's not something they've actively been adding lately.
02/03/2014 (3:47 am)
Quote:
I have be interested to hear, how "inline assembly" are consistent with the "minimize cross-platform hassles".
Inline assembly is already there, and it's been there since V12 and Tribes. It's not something they've actively been adding lately.
#7
But I think the important question is, WHEN?.
To support c++11 the committee would have to:
Sorry for the offtopic: About STD ...
I'm not against use STD, but we need information to make the decision. Another problem is that the implementation should be reviewed at each platform.
I do think it would be good to imitate the STD interface for our containers.
If we want to talk about STD, better to wait until new committee is formed.
02/03/2014 (4:17 am)
My personal vote is YES.But I think the important question is, WHEN?.
To support c++11 the committee would have to:
- Make a list of the features supported by all target platforms.
- Deprecate some versions of Visual Studio that do not meet the requirements. Important decision.
- Add to "Contribute code guide" the supported features and style guide on when permitted use. This is important to some features, for example "auto", if used without much control can obscure the code.
Sorry for the offtopic: About STD ...
I'm not against use STD, but we need information to make the decision. Another problem is that the implementation should be reviewed at each platform.
I do think it would be good to imitate the STD interface for our containers.
If we want to talk about STD, better to wait until new committee is formed.
#8
As has been mentioned, it is still early in C++ 11's life cycle and not all compilers support it equally (or even completely). There is probably no big problem with making a pair of C++ 11 branches to mirror the current Master/Development pair but until everyone supports all features completely your mileage WILL vary. And it's too bad, too; I was really looking forward to getting the Engine API stuff working correctly with the new variadic template features.
And Luis - I think you mean "STL"....
And on that note - yes, Torque uses many constructs that are incomplete or inconsistent implementations of STL constructs. When they were written the STL was still fairly immature and performance was inconsistent or unreliable. You'll note that most of Torque's constructs have little to no "safety net" built in - trying not to waste cycles testing for cases that shouldn't happen anyway (and we crash horribly when they do). Stroustrop himself says in his book that the STL is a starting point - if it does what you need with acceptable performance, use it. If not, use it as a starting point to make something that performs better in your use case. This is also the underlying philosophy of the STL - most useful in most use cases possible, not "perfect for every need - do not deviate."
Having said that, I do believe that it would be good to just replace our current custom STL-like constructs with their actual STL counterparts. Modern implementations are far better than they were 15 years ago and should require very little tuning to attain good performance in a game. Hell, even dusting the existing ones off so that they behave consistently with the STL would help - most of them are OK but some are just weird.
02/03/2014 (7:07 am)
Quote:Not everybody can afford to upgrade to Visual Studio 2013.Invalid - it's free for "desktop" applications, which encompasses Torque.
Quote:Myself I'm currently stuck with Windows XP because of embedded development tools issues and latest Visual Studio isn't supported on that OS. So I'm out of luck and so is anybody else that uses Visual Studio 2008 to 2010.Strongly valid. If you're restricted to using an older operating system where more modern tools actually won't work then you are hamstrung by the move to C++ 11.
As has been mentioned, it is still early in C++ 11's life cycle and not all compilers support it equally (or even completely). There is probably no big problem with making a pair of C++ 11 branches to mirror the current Master/Development pair but until everyone supports all features completely your mileage WILL vary. And it's too bad, too; I was really looking forward to getting the Engine API stuff working correctly with the new variadic template features.
And Luis - I think you mean "STL"....
And on that note - yes, Torque uses many constructs that are incomplete or inconsistent implementations of STL constructs. When they were written the STL was still fairly immature and performance was inconsistent or unreliable. You'll note that most of Torque's constructs have little to no "safety net" built in - trying not to waste cycles testing for cases that shouldn't happen anyway (and we crash horribly when they do). Stroustrop himself says in his book that the STL is a starting point - if it does what you need with acceptable performance, use it. If not, use it as a starting point to make something that performs better in your use case. This is also the underlying philosophy of the STL - most useful in most use cases possible, not "perfect for every need - do not deviate."
Having said that, I do believe that it would be good to just replace our current custom STL-like constructs with their actual STL counterparts. Modern implementations are far better than they were 15 years ago and should require very little tuning to attain good performance in a game. Hell, even dusting the existing ones off so that they behave consistently with the STL would help - most of them are OK but some are just weird.
#9
So when STL did become stable across multiple compilers why wasn't T3D (pre-T3D actually) rewritten to make use of it? Other things to work on with the manpower that was available. That layer was working just fine for what it had to do, so better to spend time on things like shader support, etc. Re-engineering always comes at a cost (time, stability, testing, etc.).
And I guess that's my general personal opinion on these things. If something is working fine, why replace it just because it is old? There may be valid reasons for reworking a section of T3D, such as performance (then benchmark using T3D built-in profiler or something else) or to help the cross-platform effort, but I don't think age or something shiny coming along are valid reasons.
There is so much other work that can be done on T3D that I would personally rather see the community focus on something else. How about someone fix the bugs and implement James' Improved Function Calls Pull Request if we want to see an engine speed increase, as people have reported a noticeable improvement?
And I don't want to discourage you Andrey Syrokomskiy, as you're working hard at improving T3D. Thanks! I just wish your solutions didn't rely on C++11.
- Dave
02/03/2014 (1:17 pm)
Inline assembly, STL-like classes... T3D has a long history that predates a lot of stuff. It was born from a working (and successful) game and went from there. A product of necessity for the time. I'm sure there are people here that remember what Microsoft's STL implementation was like before they started to tack the year onto the end of Visual Studio's name. Yuck.So when STL did become stable across multiple compilers why wasn't T3D (pre-T3D actually) rewritten to make use of it? Other things to work on with the manpower that was available. That layer was working just fine for what it had to do, so better to spend time on things like shader support, etc. Re-engineering always comes at a cost (time, stability, testing, etc.).
And I guess that's my general personal opinion on these things. If something is working fine, why replace it just because it is old? There may be valid reasons for reworking a section of T3D, such as performance (then benchmark using T3D built-in profiler or something else) or to help the cross-platform effort, but I don't think age or something shiny coming along are valid reasons.
There is so much other work that can be done on T3D that I would personally rather see the community focus on something else. How about someone fix the bugs and implement James' Improved Function Calls Pull Request if we want to see an engine speed increase, as people have reported a noticeable improvement?
And I don't want to discourage you Andrey Syrokomskiy, as you're working hard at improving T3D. Thanks! I just wish your solutions didn't rely on C++11.
- Dave
#10
02/03/2014 (5:28 pm)
There is nothing wrong with forking the engine and showing how it could be done. The cross pollination from such an approach would be a good thing.
#11
I agree with Dave that there are bigger issues facing the engine - but on the other hand, having a clean codebase that's a pleasure to work with is a worthy goal in itself. Torque sometimes feels like a house of cards waiting to be toppled. I don't think introducing C++11 or the STL will necessarily fix that, I guess - but lack of the latter just seems like code smell (though at the time it was a reasonable decision).
(Note: I'd really only advocate use of 'auto' in blatant cases of typesystem verbosity like
02/07/2014 (5:05 am)
Quote:Another problem is that the implementation should be reviewed at each platform.Does the STL not have requirements upon, for example, its runtime performance? Like, vectors need to be O(1) random access and all that. Does it vary that significantly across platforms - especially the major ones?
I agree with Dave that there are bigger issues facing the engine - but on the other hand, having a clean codebase that's a pleasure to work with is a worthy goal in itself. Torque sometimes feels like a house of cards waiting to be toppled. I don't think introducing C++11 or the STL will necessarily fix that, I guess - but lack of the latter just seems like code smell (though at the time it was a reasonable decision).
(Note: I'd really only advocate use of 'auto' in blatant cases of typesystem verbosity like
MyTemplateClass<AnotherType> obj = new MyTemplateClass<AnotherType>();That's just absurd. And iterators, too, are a great use case.)
#12
I'm fairly sure that the refactor in compilers to support the new features has had some beneficial side-gains. At least a little improvement in efficiency should have snuck in....
I think it might be worth at least dusting off some of our containers so that they behave more in line with the STL versions. Right now they just cause confusion - I know they threw me off a bit at first. I'm just not sure if it'd be more work to "improve" them or just replace them with STL containers.
02/07/2014 (7:00 am)
They have specifications, but a spec is just a spec - your mileage may vary; just look at Redbook....I'm fairly sure that the refactor in compilers to support the new features has had some beneficial side-gains. At least a little improvement in efficiency should have snuck in....
I think it might be worth at least dusting off some of our containers so that they behave more in line with the STL versions. Right now they just cause confusion - I know they threw me off a bit at first. I'm just not sure if it'd be more work to "improve" them or just replace them with STL containers.
Torque Owner Daniel Buckmaster
T3D Steering Committee
EDIT:
I really am not the biggest fan of C++11. I actually don't mind 'auto', especially when dealing with iterators, but I have yet to think of a use for things like anonymous functions in a large OO codebase like T3D.
That said, I think the main reason T3D is 'stuck in Y2K' is not lack of C++11 adoption, but lack of std:: adoption :P.