What will day to day C++ development be like in a few years? What C++0x features will change C++ development the most?
In what order should I concentrate learning these new features?
+22
A:
Lambdas, because they finally introduce reasonable means of harnessing the benefits of functional programming.
Dario
2010-05-16 16:59:55
And because they demonstrate the sad result of stuffing fashionable features into 30 years old language.
ima
2010-05-16 18:05:03
Switching C++ from "lasting value" category to "trying, but can't keep up"
ima
2010-05-16 18:05:49
<irony>Stuffing fashionable features into 80 years old languages has given us Haskell and F#</irony>
Dario
2010-05-16 18:14:06
Cheap. What 80 years old language is Haskell backwards-compatible with?
ima
2010-05-16 18:21:10
ima
2010-05-16 18:24:35
C++0x isn't backwarts compatible either.
Dario
2010-05-16 19:10:55
Splitting hairs like this shows you perfectly understand being wrong at the key point.
ima
2010-05-16 19:31:02
Maybe it just shows something about the seriousness of this discussion. Admittedly, the C++0x's lambda syntax is weird - as is Python's, Lua's, VB.NET's - , but that has not been questioned. We aren't talking about the motivation of their introduction or the principles of programming language evolution (to which most/all (modern) languages are subject), but their usefulness for future C++ programming. And they **are** useful, mainly because they finally provide us with functionality that lay in the nature of C++ (see how functional the STL is built) but couldn't be replicated sufficiently.
Dario
2010-05-16 19:49:41
@ima: so you're saying that because of a slightly quirky syntax (which adds expressiveness by allowing you to choose whether to capture by value or reference), we're all doomed, C++ takes a big step backwards and the world is going to end? Can't say I agree. I fail to see how "C++ with lambdas and a non-ideal syntax" can possibly be *worse* than "C++ without lambdas, but which already had a non-ideal syntax for every other feature in the language"Seriously, complaining about syntax in a discussion of C++? What's the point? C++ wasn't exactly an example of syntactic clarity to begin with
jalf
2010-05-17 14:59:04
+13
A:
Range-based for-loops.
for (int x: numbers) std::cout << x << " ";
Yay!
FredOverflow
2010-05-16 17:01:27
@Inverse Some range that you can iterator over. For example, an `int[]` or a `std::vector<int>`.
FredOverflow
2010-05-17 17:33:37
I assume you can iterate through int[5], but not through int*.But then I also assume you *can't* iterate through C strings. Will C++ strings at least allow iterating?
luiscubal
2010-05-17 21:56:14
Why would you ever want to use an `int*` in C++? And of course you can iterate through `string`, it defines a range by its `begin()` and `end()` methods.
FredOverflow
2010-05-17 23:13:00
At least `BOOST_FOREACH` supports iterating over zero-terminated char arrays. I don't think there is any technical reason why it couldn't be supported natively, if they have chosen to.
visitor
2010-05-18 11:09:03
@visitor: Technical reason, no. But design reason, yes. `char*` is not a string, it is a pointer. Maybe it points to the first character in a null-terminated string, but maybe it points to a single char, like its type suggests.
Dennis Zickefoose
2010-05-18 18:50:30
@luiscubal @Fred @visitor @Dennis: To be clear, iterating over c-strings should be fine. They are arrays (of the type `const char[N]`), and ranged-based for-loops are well-defined for arrays.
GMan
2010-08-10 18:04:47
@GMan few people store C-style strings in that type, though. Most people store strings as char*s.
luiscubal
2010-08-16 20:59:59
@Dennis Zickefoose True, but this is foreach we're talking about. Would it make sense to use foreach on a pointer to a single char? No. But it *would* make sense to apply it to a char* string.
luiscubal
2010-08-16 21:01:04
@luiscubal: That's not my problem. I'm talking about a string literal which has the type `const char[N]`. If you want to store a pointer to the first character, that's fine, but my comment isn't intended to apply to that anymore. I mean `for (char c : "asd")`, no more no less. And hell, `char* s = "asd"` is deprecated anyway, *at least* use `const char*`.
GMan
2010-08-16 21:11:28
@luiscubal: Like I said, its a design decision. Sure, it makes no sense to pass a pointer to a single character to a range-based for statement. But that doesn't change the fact that the compiler can't tell the difference between the two, and C++ is a strongly typed language. Besides, it makes no sense to *have* a pointer to a null terminated character array in the first place. If you're not dealing with a literal [which GMan is correct in stating the ranged-based for statement will handle appropriately], you should have a container of some sort.
Dennis Zickefoose
2010-08-17 01:23:25
@GMan Just curious. Since C strings are null-terminated, "abc" is actually const char[4], right? So that means a foreach applied to it would also be applied to the '\0' char, right?
luiscubal
2010-08-19 11:03:29
*Exactly* what I'm looking for when I need to declare a loop using iterators.. ahh.. no longer having to constantly type `std::vector<std::basic_string<TCHAR> >::const_iterator` every time I want to loop through a vector of strings.
Billy ONeal
2010-05-16 17:45:41
typedef is somewhat less friendly to the next guy who reads your code, though, and has to keep looking up what your typedefs mean...
Jeremy Friesner
2010-05-16 19:14:05
how is `typedef std::basic_string<TCHAR> tstring` not friendly to the next guy?
Idan K
2010-05-16 19:20:32
@Idan K: The problem is more having to typedef every and each STL container you want to iterate over. And writing generic code to handle this type is tedious. The `auto` keyword will remove all that.
paercebal
2010-05-16 19:25:26
“overuse” … well, I don’t know. I certainly intend to use it *extensively*. Don’t know that that’s “over”using it, though.
Konrad Rudolph
2010-05-16 20:03:14
@paercebal: Or, you could just typedef the container a few lines before you use it.
rlbond
2010-05-16 21:33:47
@paer Absolutely, I prefer `auto x = *it` over `typename std::iterator_traits<Iter>::value_type x = *it` anyday.
FredOverflow
2010-05-16 21:48:04
@Idan one typedef isn't so bad. Several hundred typedefs, and it takes the next guy a week of tediously grepping through your header files before he can even begin to understand what is 'really' going on in your code.
Jeremy Friesner
2010-05-16 22:52:55
@rlbond : My current code is more than full of `typedef` lines written **only** for loop iterations, and **nothing** else. I contemplated the use of a macro `#define fordef typedef` just for the sake of sick humour. And don't forget the `typename` as correctly commented by FredOverflow. For these reasons (and for metaprograming reasons, but mostly these reasons), I welcome this addition of the `auto` keyword.
paercebal
2010-05-16 23:04:41
Overuse how, exactly? That'd imply that there was some kind of cost to it, some kind of disadvantage... Which there isn't. It's no less clear than the ridiculous number of layered typedefs we have today.
jalf
2010-05-17 15:01:16
I'm really looking forward to using `auto` instead of those lengthy typedef giants, mostly in STL context. Still I'm sure people will use `auto` even in much more trivial places, where the meaning would be much clearer if the full type was typed out. `auto mynum = 4; auto another = mynum*1.f;`
Alexander Gessler
2010-05-17 15:57:04
`auto` also seems like it could make changed to code easier. As in.. want to change from a `map` to a `hash_map`? If your iterators are all auto, it should be a one-line change.
Brendan Long
2010-05-18 01:01:29
I already overuse `auto`. Not just for iterators, but in any iterator-like situation where functions return some unspecified type that you just pass around without really caring about, like `size_t` or `a type convertible to bool`. Also, once or twice with function pointers.
Dennis Zickefoose
2010-05-18 04:47:01
You can assign lambda functions to `auto` variables only because their type has no name that you could write down :)
FredOverflow
2010-05-18 09:20:52
+2
A:
Regular expressions as a standard library - you know you need them.
ablaeul
2010-05-16 17:21:57
So what? Moving boost functionality to the standard is not any kind of paradigm shift that will have massive impact, which is what the question was _about_.
John
2010-05-17 08:36:37
@John: good point, and I agree. Regardless of how awesome regexes are, putting them in the standard library isn't going to have a huge impact *because we already had them in boost*
jalf
2010-05-17 15:02:45
+1
A:
this is a great article about new features Explicating the new C++ standard (C++0x), and its implementation in VC10
The auto keyword For automatic data-type deduction (at compile time), depending on initialization.
The decltype keyword For deducing data-type from expression, or an auto variable
The nullptr keyword Null pointer is now promoted, and is been awarded a keyword!
The static_assert keyword For compile time assertions. Useful for templates, and validations that cannot be done using #ifdef.
Lambda Expressions Locally defined functions. Inherits features from function-pointers and class objects (functors).
Trailing Return types Mainly useful when templated function's return type cannot be expressed.
R-value references Move semantics - resource utilization before temporary object gets destroyed.
there are also described new features of Microsoft's new compiler
TGadfly
2010-05-16 17:29:12
for_each was in C++98 too, but you had to use it with a named function or a function object.
Turnor
2010-05-16 17:37:32
So it's not `for_each`, but the usage of `for_each` with a lambda, that you're highlighting?
Mike DeSimone
2010-05-16 20:33:39
Just to be a stickler, `auto`'s type is determined by *initialization*, not assignment.
GMan
2010-08-10 18:06:13
A:
what day to day C++ development will be like in a few years
I wonder how much day-to-day C++ development will still be happening in 5 years. It'll still be around of course but on niche platforms of course, compiler support for the new standard could take years to arrive. And as for legacy projects, updating them might never happen. In 5 years, how many new projects on mainstream platforms will be using C++?
Edit: I see the C++ fanboys are out in force. I like C++. But the fact is it's mainly used on legacy projects, or new projects using legacy code-bases, or niche platforms. None of those mean a totally clean upgrade path to a new standard.
John
2010-05-16 17:29:20
"Years to arrive" -- that's why the vast majority is already supported in the two most common compilers, MSVC and GCC.
Billy ONeal
2010-05-16 17:43:48
@ ONeal - Not to mention the fact that Boost has libraries for most of what's in C++0X.
wash
2010-05-16 18:04:42
We've got a huge amount of code written in C++. It works. We see no need to reinvent the wheel. And since our new projects build on the old, we'll still have most of our new development on C++ five years from now. Things don't change fast in huge, complex systems, especially when it comes to things like languages which have zero visibility to the customer.
Mike DeSimone
2010-05-16 20:36:17
@Billy, try reading my post. "BUT ON NICHE PLATFORMS..." Like games consoles...
John
2010-05-17 08:34:50
@Mike... but are you looking to make sure all those massive projects work on a new standard?
John
2010-05-17 08:35:32
C(++) won't die out in the next 5 years, realize that all the fancy platforms you think will replace C/C++ are actually written in those languages under the hood. And what about operating systems such as, you know, Windows, UNIX? How "niche" is that.
wump
2010-05-17 14:09:23
-1 because it doesn't really seem to 1) have anything much to do with the real world (where C++ is still heavily used, and certainly will still be heavily used in 5 years), and 2) because it has nothing to do with the question asked.
jalf
2010-05-17 15:04:11
@John: I did read your post. You didn't specify only on niche platforms -- you said you think C++ development will continue only on niche platforms. That's got nothing to do with the statement that the standard will take years to arrive. GCC supports almost every platform imaginable and it supports C++0x --- and as a result I'm confused about the years to arrive statement.
Billy ONeal
2010-05-17 16:11:50
@John: No, but gcc has a nasty way of not staying put. It's more of a "dragged kicking and screaming" model; I'm not bragging.
Mike DeSimone
2010-05-18 02:55:11
John
2010-05-25 15:24:44
@John: Actually, it does. PS2 is a MIPS processor, and GCC supports that platform.
Billy ONeal
2010-05-25 16:34:17
+13
A:
Unicode support. No more cobbles and hacks to get correct handling of unicode characters -- now the entire unicode standard is natively supported by the language.
Billy ONeal
2010-05-16 17:47:21
+23
A:
I personaly think that move semantics (and rvalue references in general) are the most important change, on par with threads/locks/atomics. Everything else is, more or less, simplification of syntax or standardization of common third-party solutions -- we can write functors when we need lambdas and we have numerous regex libraries. Even for the lack of atomic operations there were some solutions, but there were NO move constructors/move assignment operators.
Being able to move objects changes the whole perception of the language to me. Even though we had RVO and the swap-to-temporary trick to emulate some of it already, it's hard to imagine how the life changes when this is part of everyday life. It's not just ofstream("log.txt") << "Hi!";, or the so much faster STL algorithms, it's a whole new way of passing data between functions.
Cubbi
2010-05-16 18:59:48
And a whole new generation of programmers having no clue, what they/others are doing and why it doesn't work.
tstenner
2010-05-16 19:10:17
+1 - rvalue references allow a whole slew of important constructs and methods that were previously impossible.
Noah Roberts
2010-05-16 20:17:40
You are right that move semantics is a really good feature, but Boost.Move provides a good even if incomplete emulation of C++ move semantics.Note the library is just now under review.
Vicente Botet Escriba
2010-05-16 23:07:05
+2
A:
We switched to 2010 about a month ago. The two most common things we've used are auto and lambda. Rvalue references have allowed me to do many things that were not possible before, but in day-to-day use they are not AS used as lambda and auto.
Noah Roberts
2010-05-16 20:21:22
A:
Concepts. At last, we'll be able to type-check templates before instantiating them, and when we instantiate them incorrectly, we'll get sensible error messages. Whoops! The C++0X committee couldn't agree and eventually tossed them out. Ah well, wait for C++1X...
Norman Ramsey
2010-05-16 22:47:31
A:
auto in the for loops, and lambdas for the algorithm, I'll start a massive using of for_each.
Nicola Leoni
2010-06-14 14:35:14