To use or not to use C++0x features

views:

464

answers:

+10 Q:

To use or not to use C++0x features

Possible Duplicate:
How are you using C++0x today?

I'm working with a team on a fairly new system. We're talking about migrating to MSVC 2010 and we've already migrated to GCC 4.5. These are the only compilers we're using and we have no plans to port our code to different compilers any time soon.

I suggested that after we do it, we start taking advantage of some of the C++0x features already provided like auto. My co-worker suggested against this, proposing to wait "until C++0x actually becomes standard." I have to disagree, but I can see the appeal in the way he worded it. Nevertheless, I can't help but think that this counter-argument comes more out of fear and trepidation of learning C++0x than a genuine concern for standardization.

Given the new state of the system, I want for us to take advantage of the new technology available. Just auto, for instance, would make our daily lives easier (just writing iterator-based for loops until range-based loops come along, e.g.).

Am I wrong to think this? It is not as though I'm proposing we radically change our budding codebase, but just start making use of C++0x features where convenient. We know what compilers we're using and have no immediate plans to port (if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform). Otherwise it seems to me like avoiding the use of iostreams in 1997 just because the ISO C++ standard was not published yet in spite of the fact that all compilers already provided them in a portable fashion.

If you all agree, could you provide me arguments I could use to strengthen my position? If not, could I get a bit more details on this "until the C++0x is standard" idea? BTW, anyone know when that's going to be?

+7 A:

Theoretical but not practical disadvantages of using C++0x:

Makes it harder to port to different compilers.
Not adhering to any published standard.

Practical advantages of using C++0x:

Makes your daily lives easier, hence more productive.

It's a debate between what's theoretically right, and what's practical. If your team has any intent of actually doing something with this code, the practical should outweigh the theoretical tenfold.

Thomas 2010-07-02 12:01:28

Particularly if you're absolutely certain (as you seem to be) that you're not going to port this code to a system whose compiler doesn't (yet) understand it. I can sympathise with the "standards are good" thinking of your colleague (possibly a little *too* well :P) but if there are no actual negative consequences, it's just an unnecessary hindrance.

shambulator 2010-07-02 12:13:03

Theoretical, but unlikely, disadvantage of using C++0x: Due to bugs in the two implementations you are using, or changes in the proposed standard, you code may be trapped on specific versions of gcc/msvc. Example: If you had done this about 7 months ago and heavily used concepts. See Also: Visual Studio 6.

KitsuneYMG 2010-07-02 12:32:34

If things are removed from the standard, but are already implemented in compilers, they will probably be made into an optional compiler extension instead of being removed altogether. So it is, as you say, a theoretical but unlikely disadvantage.

Thomas 2010-07-02 12:45:39

You don't need to worry to much about features being added/removed now since March FCD they've frozen features and only working on corrections/adjustments to the draft standard.

snk_kid 2010-07-02 13:03:46

Thanks for the response! I had a hard time choosing between your answer and jalf's but both were very informative. I tend to agree on the practicality side but also would agree with jalf that we should avoid the exotic features which are prone to change or be taken out.

2010-07-02 14:31:25

@Thomas An example of non-extension-able code: MSVC6 allows istringstream objects to be returned by value. Since the standard does not, the only way to fix the code I had was to create macros. Luckily they only used this in a `mk_stream(std::string)` type function which only returned an `istringstream`.

KitsuneYMG 2010-07-10 09:20:03

+3 A:

We had the exact same problem so we compromised. We took the C++ 0x TR1 release and then only took the portions that we knew we wanted to use. Sounds like a lot of work, but so far it's worked out well. We're using the regex libraries, tuples, and a couple of others. Once the standard is ratified, then we'll migrate to the full C++ 0x. This obviously isn't the best solution but it was one that has worked well for us.

nathan 2010-07-02 12:02:59

+1 Thanks nathan for an example to which we can compare. I'm looking for a similar compromise: just go with the FCD features already becoming available, not the more exotic ones that could undergo further revisions.

2010-07-02 16:30:32

+7 A:

One thing you don't need to (mostly) worry about now is features being added or taken away because the working draft reached "Final Committee Draft" (FCD) back in march. Feature-wise should be frozen, standards committee will not accept any-more proposals for C++0x.

Downside is it's still a draft and not finalized yet, the standards committee are in the phase of making corrections and adjustments before finalizing and publish the ISO standard (expected release to be march 2011). That could mean minor syntactic or semantic/behaviour changes which could make your code not compilable or not work correctly once you compile with a compiler that is more standard compliant than the one you're using at the time you wrote the code.

You'll probably have to wait sometime for compilers like VC++10 to get update with any corrections/adjustments made.

snk_kid 2010-07-02 12:58:13

Thank you, pointing out the FCD is a great idea! I think perhaps that might allow me to win over some people in this debate if we selectively choose what C++0x features we can use.

2010-07-02 14:38:28

+9 A:

I'd make the decision on a per-feature basis.

Remember that the standard is really close to completion. All that is left is voting, bugfixing and more voting.

So a simple feature like auto is not going to go away, or have its semantics changed. So why not use it.

Lambdas are complex enough that they might have their wording changed and the semantics in a few corner cases fixed up a bit, but on the whole, they're going to behave the way they do today (although VS2010 has a few bugs about the scope of captured variables, MS has stated that they are bugs, and as such may be fixed outside of a major product release).

If you want to play it safe, stay away from lambdas. Otherwise, use them where they're convenient, but avoid the super tricky cases, or just be ready to inspect your lambda usage when the standard is finalized.

Most features can be categorized like this, they're either so simple and stable that their implementation in GCC/MSVC are exactly how they're going to work in the final standard, or they're tricky enough that they might get a few bugfixes applied, and so they can be used today, but you run the risk of running into a few rough edges in certain border cases.

It does sound silly to avoid C++0x feature solely because they're not formalized yet. Avoid the features that you don't trust to be complete, bug-free and stable, but use the rest.

jalf 2010-07-02 13:32:40

Thanks jalf for the advice! I will take it and see if I can convince my co-workers to selectively use certain features of C++0x. To provide a little background, I'm in a team that's reluctant to use the standard library over their own handrolled collections. Part of the reason is that they hate the iterator syntax. Slowly more and more people have come to use them as they realize there's no good reason not to do so, but there's still a lot of complaint about the syntax involved in, say, an iteration-based for loop. I don't mind since I typedef everything and syntactical redundancy doesn't

2010-07-02 14:40:53

[...] bother me so much anymore (only logical redundancy), but it might help get more people on board with using C++ properly if we just had, say, auto.

2010-07-02 14:41:34

@stinky472: There's no reason whatsoever not to use C++0x if you know that you have a compiler that supports it. Remember that C++0x can offer many performance enhancements and other things that C++03 can't. It's true that theoretically, a feature might get changed. But the cost of changing it when you update and the standard is finished is much less than the cost of not using rvalue references, auto, decltype, variadic templates.

DeadMG 2010-07-02 18:00:26

+1 A:

If you intend to make your system open source within a not-too-far future, then that's an argument for not using too many bleeding-edge features. A production system running Debian or Red Hat won't necessarily have a bleeding-edge compiler installed.

You said

if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform

but that a compiler exists for a platform doesn't always mean that it's installed/used/wanted, especially on production systems.

If, on the other hand, you intend to do all the compiling yourself, this is not an issue.

Lajnold 2010-07-02 13:48:47

+1 Thanks Lajnoid and I didn't consider linux distros. We may want to support other distributions that might be limited to older versions of GCC. I'll have to raise that point as a legitimate issue for consideration, but I hope we can use some of the basic C++0x features soon instead of waiting years before we can benefit from it.

2010-07-03 11:59:36

ansaurus

tags:

views:

answers:

To use or not to use C++0x features

related questions