

9 reasons to start using C++11 - Tatyanazaxarova
http://www.cpprocks.com/2012/05/07/9-reasons-to-start-using-c11/

======
haberman
Pretty much everything in C++11 sounds extremely cool and useful. It seems
like the committee did their homework; from what I can see all of the new
features are well-designed and thought through. Lots of things that were
verbose or inefficient before are fixed, and as a result the language will be
more expressive.

But I just have this nagging worry that C++ is going to collapse under its own
weight. C++ was already the most complicated language in common use IMO
(except possibly Perl); with C++11 there are more keywords, more constructs,
more variations. I just hope this doesn't make C++ seem totally unapproachable
to beginners, or too hard to keep up with for people who are already using it.

~~~
JoeAltmaier
I'd have liked better ptr features. The auto-cleanup is good. Is it flexible
enough to do other things like: auto-close (a file ptr); auto-deref (a ref-
counted thing); auto-unlock (a critical section) etc?

~~~
mkl
All of these can be done in a class's destructor, which is called when the
object is deleted, e.g. when a shared_ptr's ref-count reaches 0 (i.e. there
are no references to it left). To express observation (and break cycles) there
is weak_ptr, and to express ownership there is unique_ptr.

IMO the new pointer stuff is excellent, and relieves the large majority of the
memory management burden.

~~~
reddit_clone
There are some boost macros which will run clean up code at the end of the
scope if you prefer. They are not pretty. But they work. (This is a life saver
in a long function with multiple exit points)

------
CrLf
What I would like to see is a (convincing) list of why use C++ (in new
projects) at all.

In my opinion (and experience) when you need the performance advantages of
C++, you are usually within the domain where C is good enough (and perhaps a
better choice for its simplicity). When you need the features of C++, you are
probably better off with something like Python (not specifically, but in the
same "league").

Seeing how easy it is to use a higher-level language combined with C for
critical sections, I just don't see the point of C++ anymore.

Disclaimer: I don't really like C++. The only pleasant experience I had with
it involved ignoring the STL completely and using Qt (<http://qt.nokia.com/>).
I like C though.

~~~
norswap
C is good and simple but C is not expressive. There are a whole hosts of
situation where code has to be duplicated or slightly modified. For instance,
it's really hard to do good generic data structures in C without ending up
with casts everywhere. Polymorphism is even worse.

For me, that really is the edge that C++ holds over C.

~~~
CrLf
Like the old saying, "you can write cobol in any language".

Polymorphism and "good generic data structures" (in the sense you are
implying) are not a necessary requirement of elegant and maintainable code. It
is part of the problem that programmers have taken OO concepts as the end-all
of good code, and must apply those concepts everywhere even if that means
implementing them from scratch at the cost of (unnecessary) complexity.

Large systems have been written in C. Many large open-source projects use C.
There is no evidence that these are less maintainable (in general) because of
language choices.

Some of these graft OO concepts onto C. GTK is noticeable for this (although
it doesn't seem to be too bad for application developers, I'm afraid for those
tasked to maintain the libraries themselves).

Procedural programming is not a sin (if "procedural programming" exists at all
today, as most of the simplest object concepts have become common practice and
are now though as an integral part of it).

~~~
cygx
_Like the old saying, "you can write cobol in any language"._

As far as I know, there is no such 'old saying'.

However, _The determined Real Programmer can write FORTRAN programs in any
language._

------
webreac
Of course, if you are a C++ programmer, you should migrate to C++11 as soon as
possible.

But do not forget that the improvements given by C++11 do not void all the
reasons to not use C++ at all. Avoid C++ if you can.

~~~
okamiueru
As has been said a million times, C++ covers applications that are not really
suited for any other language. This applies to C as well.

As much as newer languages come about, in the end, you are working with a Von
Neumann machine, of which both C and C++ are well suited for.

The only problem with C++ as far as I can tell is that you need to know a lot,
not to make mistakes. There are too many ways to do things, that if you don't
know what you are doing, you are probably going to do things wrong. However,
once you _do_ know, and use libraries like Boost, I think it is difficult to
come up with a reason why not to use C++ for lower level programming, with
performance requirements.

~~~
webreac
The problem is that the prerequisite does not apply only to you, but also to
all your team. It is ok to use C++ for lower level programming with
performance requirements if all the development team knows very very well C++.
Even if you fill these conditions during initial development of a project,
during the maintenance years, you always happen to have a not so well educated
developer. C++ use is a very narrow market.

~~~
okamiueru
Code practices and code reviews help with getting beginners up to speed and
not clutter the code base. If you remove all experienced developers with
inexperienced ones? Surely this will cause problems in any language.

Also, I'll have to disagree with C++ being a narrow market. Just the market
where C/C++ is almost required (high performance or low level) is large enough
as it is.

Then there is the discussion of which language is _more_ suited for a given
task when you are doing higher level stuff that doesn't have high performance
requirements. It might be wasted resources to put people with high knowledge
of C/C++ to that kind of tasks. As for the language itself, in terms of
productivity; _if_ the developers are experienced, I don't see any problem
with it. With help from Boost and/or Qt, it is as easy as writing python
(almost, sometimes :) ).

------
option_greek
Unfortunately as the number of new projects involving C++ keeps going down,
the fields in which C++ jobs are available are getting narrower every year.

Almost all middleware is now written in Java. C# took over the frontend
development on Windows. New openings in C++ seem limited to quant fields (bank
backends on linux) and driver development.

~~~
NickPollard
And Games. AAA game dev (for PC and Console) is almost entirely C++, with some
embedded scripting languages (normally Lua, for performance reasons).

------
k4st
One of the reasons I like C++ is that it lets you throw away type safety and
still maintain it through abstraction. This sounds awful, so let me explain.

In one project, I implemented an EDSL for performing a destructuring bind on a
string (CFG production, actually). The types of the components of the pattern
determined what the pattern would actually match.

This was all done in a previous version of C++, so I didn't have variadic
templates available. I also didn't want to heap allocate the internals of
patterns.

What I did was to store an array of void pointers and a function pointer as
private fields within a pattern class. When constructing the pattern, pointers
to the things to which parts of the string to be bound were put into the
array, thus throwing away their types. BUT, the function pointer pointed to a
static method in of a class template, which only operated on the array of void
pointers in a type-safe way, precisely because it was compiled with the
knowledge of the types.

I use this type of subversion when appropriate, and it's often a very
convenient solution to an otherwise tricky problem. Such a thing would either
not be possible--or be incredibly inconvenient--in C. It's often very useful
to treat different stuff uniformly, knowing that your abstractions can
maintain type safety.

------
simias
Is there a resource somewhere listing which compilers support which features
of C++11? Or do all major compilers already support the new standard?

Portability is probably the main reason I'm concerned about switching my
codebase to the new standard...

~~~
nonsequitur
C++11 support in common compilers:
<http://wiki.apache.org/stdcxx/C++0xCompilerSupport>

~~~
simias
Thanks to you both, that what I was looking for.

------
cageface
C++ is very much a mixed bag but the new features in the C++11 standard do
help a lot. The "auto" keyword and range-based for loops alone have
decluttered my code quite a bit.

The new smart pointers make me nervous after the auto_ptr fiasco but they seem
to be working fine in my code so far.

I'm looking forward to trying out the lambdas as soon as they hit in XCode.

~~~
okamiueru
The BOOST_FOREACH has helped declutter my code a lot as well. After getting
used to it, I feel it expresses intent better than a for loop with auto begin-
end.

------
toemetoch
3 questions before moving to C++11

\- which architectures is the author discussing when he talks about
performance gains, what are the ISA requirements and numbers?

\- what compilers are supporting it?

\- why is it good to have "magic" happening in the background? E.g. reason 4
is not something I'd promote.

~~~
JamesLeonis
I can answer 2 and 3

2\. Apache maintains a list of which compilers support what.
<http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport>

3\. The auto keyword isn't supposed to be magic. Rather it's for catching
complex types that aren't easily to discover, such as the returns of template
functions and iterators, and making it easier on the programmer by not forcing
the typing out of long types. The type is resolved at runtime (as best as I am
able to tell) and can help clean up some of the messiness of template
programming.

~~~
pja
No, the type implied by an auto declaration is resolved at compile time.

~~~
JamesLeonis
DOH! My mistake! Thanks for the catch.

------
tseabrooks
As a long time C++ / C programmer I love every feature here... except one. I
really abhor the new auto keyword. Perhaps it's personal taste (I also dislike
the "Var" in JS). It really seems to make the code harder to follow with only
minimal advantages (that I can see / use/ etc).

~~~
16s
While I understand the reason for auto, and see the benefit in less typing,
etc, I still do it the old-fashioned waytoo. I prefer be explicit.

------
johnx123-up
Any good IDE and references?

