Plans for migration to C++11?

[DoxaLogos (JG)]

I saw a post on the mod portal asking contributors about OpenXcom's tech choices back in 9/2014, but I couldn't see any responses to it.  The topic of my interest is C++11 support.  I know at my company we're seriously considering migrating to it, particularly for a new platform.  Full support for it is almost here from a GCC perspective(I think regex is due in 5.0), but I don't know how far along MSFT Visual Studio is (I don't use it myself, because we use GCC/CLANG and some other commercial C++ compiler for embedded systems).

So... are there plans for migrating OpenXcom to C++11? 

I'm certainly be interested in helping out with it, because it's kind of low level migration at first (like use "auto" in some places - iterator declarations for example) and can be done incrementally.

[volutar]

Will it instantly make oxc even better, less buggy, and more multiplatform?
I see no point of doing that.
Because it won't make it anyhow better, less buggy or more multiplatform. On opposite, it will cause more bugs (due to auto ambiguousness) attract unexperienced c# programmers, and lessen porting capabilities. If someone can't help project will C++, he won't help either way.

[DoxaLogos (JG)]

I fail to see why continuing to support the standard language makes it less portable or less multiplatform, so long as the compilers support it.  My experience has always been the exact opposite time and again for the last 20 years (going beyond just C++).  Overall, same goes for the STL, that it has proven more maintainable and less buggy then everyone rolling their own container or some widget.   If you feel that auto is problem, simple make it part of your coding standard as not allowed and enforce it. There's more to C++11 than just the auto keyword.   I also think your comment about "instantly" better is unrealistic.  Refactoring code to  improve it always takes effort, the question is it worth it?

[volutar]

The answer is: no it doesn't worth it, and obviously will increase problems, not just because of auto.
Just look at the list of platforms: https://openxcom.org/downloads-milestones/
Are you sure all of them are supporting C++11 nicely?

[DoxaLogos (JG)]

The answer is: no it doesn't worth it, and obviously will increase problems, not just because of auto.
Just look at the list of platforms: https://openxcom.org/downloads-milestones/
Are you sure all of them are supporting C++11 nicely?

Again, depends on what their compiler is.  The only one I'm not sure of it is Windows (I stated that I don't use VC++).  But for the majority on that list, those are built with GCC or CLANG which are very close to having full support.  The only way to be 100% is to have each one tested.

[volutar]

What's the point of bothering with "migrating" to C++11? Is C++ not good enough? It doesn't allow implementing some good features, or perhaps C++11 allows for better logging/backtracing/debugging?

I see SOME points of migrating to SDL2, despite all troubles like problems with shading/lighting and FPS. It will allow better input support (for touch devices), better OpenGL integration (which is long-way achievable and desirable target).

But what's the point of migrating to C++11? How exactly it gonna make OXC better?

[DoxaLogos (JG)]

Well, since you asked, the one thing that comes to mind is C++11's move semantics.   Depending on how much OXC uses STL containers, the codebase could see a significant performance increase without changing the code that uses the STL containers.  Again, I won't say "instantly" here either, because every time I've moved up in versions of compilers (open source & commercial), it has found bugs in my code because the new compilers tend to get "stricter" in supporting the C++ standard.    Measurements would have to be made of course, to see if the performance improvement is worthwhile. 


Anyway, I've got my answer - no C++ 11.  If that's what the developer team wants, I can live with it

[Yankes]

Anyway, I've got my answer - no C++ 11.  If that's what the developer team wants, I can live with it

If you want know what developer team think about this, you should ask SupSuper or Warboy1982, if I recall correctly they were more neutral to this than volutar.

[DoxaLogos (JG)]

If you want know what developer team think about this, you should ask SupSuper or Warboy1982, if I recall correctly they were more neutral to this than volutar.

Okay.  That is why I started with the question on the forums in the "Development" section. I've seen them respond in the forums before.  Is there a better way to ask?  Please, understand, I'm not being a "smart alec" in asking.  I really don't know.

Either, way, I'm not here to push the C++11 agenda or stir up trouble, just offer some help in the effort to migrate if they had plans to do it. I certainly don't want to distract them either in their efforts to implement TFTD feature sets.   Til then, I'll find other ways to contribute

[Yankes]

Okay.  That is why I started with the question on the forums in the "Development" section. I've seen them respond in the forums before.  Is there a better way to ask?  Please, understand, I'm not being a "smart alec" in asking.  I really don't know.

Either, way, I'm not here to push the C++11 agenda or stir up trouble, just offer some help in the effort to migrate if they had plans to do it. I certainly don't want to distract them either in their efforts to implement TFTD feature sets.   Til then, I'll find other ways to contribute

My point was that you too fast go to conclusion what developers wants. volutar is many times right, but he don't represents developers and that was his personal opinion. And my personal opinion is that C++11 would be great for OXC, and don't need any big effort to start using it (modern compiler and `--std=gnu++11` switch).
And again asking is always good think, I wanted you to avoid wrong conclusion, sorry if that was phrased to hard

[Warboy1982]

personally i'm not averse to it, and given that it wouldn't actually require any major adjustments to the codebase it's feasible, however:
granted we'd gain access to some "useful" new additions, like float/binary conversion and auto, but as it stands, we don't NEED those strictly speaking, and there are ways and means to achieve the same ends in standard C++, meaning there's no imperative, only incentive. given that i'm somewhat of a novice to C++ in general, and would have to go back into learning mode to take on all the new C++11 stuff, it seems my efforts would be better spent sticking to what i know, and learning the new standard with a different project STARTED in C++11.
to put it in very simple terms: it seems like more effort than it is worth, and there's little to no difference in the final outcome, albeit with an increased likelihood of me introducing bugs that i never even thought were possible.
that, coupled with as of yet un-proven multiplatform compilability makes it fairly difficult for me to endorse such a shift. it's bad enough when there's an issue with a library like yaml and we have to wait for the upstream fix to trickle down, i can only imagine waiting for a compiler fix would be equally if not more frustrating. at least with standard C++ we KNOW it's proven and portable.
i know this may not be the answer you're looking for, and it's entirely plausible that my opinion may change in time. but i have to look at this in terms of practicality and return on investment. as it stands, the investment exceeds the return, making it impractical.

[DoxaLogos (JG)]

personally i'm not averse to it, and given that it wouldn't actually require any major adjustments to the codebase it's feasible, however:
granted we'd gain access to some "useful" new additions, like float/binary conversion and auto, but as it stands, we don't NEED those strictly speaking, and there are ways and means to achieve the same ends in standard C++, meaning there's no imperative, only incentive. given that i'm somewhat of a novice to C++ in general, and would have to go back into learning mode to take on all the new C++11 stuff, it seems my efforts would be better spent sticking to what i know, and learning the new standard with a different project STARTED in C++11.
to put it in very simple terms: it seems like more effort than it is worth, and there's little to no difference in the final outcome, albeit with an increased likelihood of me introducing bugs that i never even thought were possible.
that, coupled with as of yet un-proven multiplatform compilability makes it fairly difficult for me to endorse such a shift. it's bad enough when there's an issue with a library like yaml and we have to wait for the upstream fix to trickle down, i can only imagine waiting for a compiler fix would be equally if not more frustrating.

Perfectly reasonable concerns, particularly if you're not familiar with the language additions.

at least with standard C++ we KNOW it's proven and portable.

Correction: "at least with C++ 03/C++98 we KNOW it's proven and portable."  C++ 11 IS standard. C++14 IS standard.  Hate to nitpick, but it implies the later revisions are not standard and they are.  And for the most part, backward compatible to C++03/C++98.  This actually helps moving forward, because like Yankes said earlier, "turn the C++11" switch on and you can still code against the older standard.  You should see some performance improvement by moving up with the std::move semantics now built into the newer STL.  How much improvement, I would not know.

i know this may not be the answer you're looking for, and it's entirely plausible that my opinion may change in time. but i have to look at this in terms of practicality and return on investment. as it stands, the investment exceeds the return, making it impractical.

Again, my original question was are there plans to migrate to C++11? I think you've answered it    It's cool. Thanks for the kind and well-reasoned response.

[Yankes]

How much improvement, I would not know.

I yesterday compiled using C++11 and I didn't see any speed grain, this is probably because OXC computations aren't focuses on types that could grain from `std::move`. I know places where it improve speed but they are far between to made difference.

[DoxaLogos (JG)]

Cool, good to know.