
The New C++: Lay down your guns, knives, and clubs - jemeshsu
http://m.theregister.co.uk/2011/06/11/herb_sutter_next_c_plus_plus/
======
SamReidHughes
<tl;dr> C++0x is pretty nice. </tl;dr>

But ultimately, as long as it lacks memory safety, it lives in a mostly
parallel universe from Java and everything else. It's not really becoming more
Java-like. It's becoming more C++-like. C++0x goes in the direction of having
better support for existing C++ idioms.

~~~
lutorm
_it lives in a mostly parallel universe from Java and everything else_

So the top 3 programming languages are Java, C, and C++, with C/C++ together
larger than Java. Maybe it's Java that lives in a parallel universe?

~~~
kleiba
I don't get your point. If A lives in a parallel universe from B, then B lives
in a parallel universe from A.

I think what the grandparent wanted to say is that memory management is a
defining difference between the paradigms of both languages. There are some
people who value the fact that they have full control over allocation and de-
allocation and others who think that these are things the programmer shouldn't
(have to) care about, because they're known to be error prone.

~~~
joe_the_user
The original parent said "Java and _everything else_ ", leaving an implication
that unmanaged memory stuff was marginal. I think that's what the gp is
addressing.

~~~
SamReidHughes
Nope, kleiba correctly interpreted my comment :)

------
cageface
I've always imagined Herb Sutter as a Gandalf-like figure and here he is
looking like a partner in a New York law firm. I guess it is possible to
achieve guru status without a beard.

I can't wait to get support for the "auto" keyword in XCode.

~~~
jpr
Apparently he has had a mustache, so no guru status without facial hair yet:

<http://www.xb360info.com/images/herb_sutter.jpg>

~~~
Luyt
Ha, you should have seen Alex Martelli while he still had a moustache:
[http://images-mediawiki-
sites.thefullwiki.org/05/3/0/3/32378...](http://images-mediawiki-
sites.thefullwiki.org/05/3/0/3/3237892484320994.jpg)

------
ajays
FTA: "the Apache MapReduce clustered data-processing architecture, ... is
written in C++"

Really? Hadoop is pure Java.

~~~
revertts
Yeah, that caught my eye too. I assume they just got Hadoop mixed up with
Google's C++ MapReduce implementation.

------
nl
_Interestingly, C++ was ratified as an ISO standard just as Java failed to get
ISO pick-up after a campaign by Sun_

Actually, even more interestingly, Java failed to become an ISO standard
because Sun _didn't_ want it (at the time they were worried about the
potential influence of Microsoft).

------
wglb
I have a lot of respect for Herb Sutter--his articles on difficulty of
multiprogramming are worth study by all. But there is an element of Kool-aid
in his comments about other languages. Hadoop is written in Java; much of the
world is written in C, and in very restricted versions of C++. I say this as
one who did 10 years in industrial-strength C++ programming.

If you look at C++ without rose-colored glasses, it is a pretty frightening
prospect. _Modern C++ Design_ by Andrei Alexandrescu is a very awesome book,
but the fact that there are surprises in it for Scott Meyers should give the
student pause.

And to all of you who are beginning programming, you will be better off in the
long run if you become proficient in several languages. I predict that in your
successful career you will be ahead if you are able to pick up new languages
rapidly. Time spent mastering C++ might not be the best use of your learning
budget.

------
hendler
"... the Apache MapReduce clustered data-processing architecture ..." I'm not
very familiar with internals of Hadoop - but thought this was mostly Java.

------
DannoHung
Doesn't change the fact that the C++ design is a giant ball of mud.

~~~
CountHackulus
Care to back up that statement? Can you explain how objects and patterns in
C++ make the design worse than objects and patterns in another language?

~~~
cousin_it
Here's a list of what seem to me, in hindsight, to be the biggest mistakes in
the design of C++:

1) Header files. They don't improve your code or your build process in any
way, they just make you retype everything twice and make the compiler
reprocess everything as many times as it's included. There's no reason why
even a low-level language today can't have a module system like Java's, where
everything is typed in and compiled only once.

2) Having exceptions without having garbage collection. Having both of these,
or none of these, would have been OK, but having one and not the other makes
writing exception-safe code unnecessarily difficult. It took people years to
write the first correct exception-safe container class and understand all the
tricky leaks that can happen. See Tom Cargill's 1994 article:
[http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/aw...](http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/aw/meyerscddemo/DEMO/MAGAZINE/CA_FRAME.HTM)
and Herb Sutter's failed answer in 1997: <http://www.gotw.ca/gotw/008.htm> .

3) The template mechanism is too general and not a good fit for many of the
tasks that people are trying to solve with it. Easy tasks like parameterized
container types would've been better solved with a simpler mechanism like Ada
generics (no specialization, no implicit instantiation, only one copy of
object code, possible to compile separately). Harder tasks should be solved
with purpose-built mechanisms, e.g. if you really need lambda, build it into
the language. Faking lambda with templates isn't much better than faking it
with preprocessor macros.

4) Strings should've been built in, and done right. There must be only one
string type (Unicode). All string literals must be instances of that type. No
null-terminated strings anywhere, they're a very bad default. If your
application demands shaving a couple cycles from operations on character
buffers, you can always use custom code.

I'm not asking for garbage collection, multithreading, GUI toolkits or any
other fancy features. C++ could've gotten these five things right and still be
a very good fit for all the bare metal speed hackery that people want.

~~~
sorbits
Not that I am a C++ fanboy, but your list is sort of orthogonal to what I
would list.

 _1) Header files. They don't improve your code or your build process in any
way_

They improve modularity. I have a header for each module which list the
functionality exposed from that module and nothing else.

This avoids leaking implementation details, helper functions, etc. and it
allows me to “ship” the module in binary form (a static or dynamic library).

 _2) Having exceptions without having garbage collection._

As for your example of container classes, the problem (IIRC) is to not leave
the container in an invalid state, when the exception is thrown, e.g. if you
insert a range into a vector, and an exception occurs in the middle of this,
you need to rollback before rethrowing the exception.

Relying on the rules of when objects with automatic storage are destructed
actually makes this easier than not having automatic storage (but instead a
garbage collected heap with non-deterministic behavior).

 _3) The template mechanism is too general and not a good fit for many of the
tasks that people are trying to solve with it_

The C++ template mechanisms gave us STL, something the author said no other
language allowed him to create, and something I am truly grateful for having
been exposed to in my career.

While I don’t particularly like many of the uses of templates in boost, i.e.
the template expressions you refer to (like faking lambda functions) I don’t
consider it a mistake to have introduced a flexible compile-time macro system.
I mean, everything can be misused…

 _4) Strings should've been built in, and done right_

Strings weren’t really “designed”, many compiler vendors did their own string
classes, and the standard tried to adopt sort of a common denominator (I
mention this since your list is issues with the C++ design).

As for having to be built in: I don’t think types beyond the most primitive
stuff needs to be built in, but the language should allow the user (library
supplier) to introduce new types that look and feel exactly like built in
types, that way, we can also get regexps, matrixes, associative arrays, sets,
a.s.o. as types which feel like first class citizens.

~~~
cousin_it
> _[Header files] improve modularity. I have a header for each module which
> list the functionality exposed from that module and nothing else._

Have you seen how Java does it? You annotate your stuff as "public" when you
want to expose it.

> _As for your example of container classes, the problem (IIRC) is to not
> leave the container in an invalid state, when the exception is thrown, e.g.
> if you insert a range into a vector, and an exception occurs in the middle
> of this, you need to rollback before rethrowing the exception._

There are two problems: leaving the container in a valid state, and avoiding
memory leaks. The former is a problem in most languages with parameterized
types and exceptions. The latter is a problem only in C++, because what you
call "automatic storage" makes exception-safety difficult as I pointed out.
Since adding garbage collection to C++ is still a non-starter, I'm gonna go
ahead and say adding exceptions was a mistake. The C way with error codes was
better. With error codes, writing an error-safe Stack class would've been a
task for one day instead of three years. (Granted, the code would've been
longer and less "subtle". I don't care.)

> _The C++ template mechanisms gave us STL, something the author said no other
> language allowed him to create, and something I am truly grateful for having
> been exposed to in my career._

I'm not sure the STL should ever have been made an industrial standard. People
mostly need things like foreach, filter, fold, find, sort... STL's interface
for such operations is too convoluted, you have to write a lot of weird code
that doesn't do anything except make the compiler happy, learn about iterators
etc. The sweet-spot interface (IMO) is by using closures, like Smalltalk does
it:

    
    
        product := 0.
        numbers do: [:each | product := product * each]
    

> _As for having to be built in: I don’t think types beyond the most primitive
> stuff needs to be built in_

Well, you can't help having strings built in, because the language has string
literals, right? They must evaluate to something. All I'm saying is that the
wrong default (making them evaluate to a pointer that points to the start of a
null-terminated string, and having tons of library functions that accept
those) is worse than the right default (making them evaluate to an instance of
a built-in string type).

> _the language should allow the user (library supplier) to introduce new
> types that look and feel exactly like built in types, that way, we can also
> get regexps, matrixes, associative arrays, sets, a.s.o. as types which feel
> like first class citizens._

This generally doesn't work unless your language is extremely syntactically
malleable, like Lisp, and I'm not sure it's an especially worthwhile goal. Can
C++ get regexp literals like in Perl? Map literals like in Javascript?
Actually it doesn't even have array literals, instead it has "initializers"
that aren't even rvalues. I think the sane decision is to give the user a
bunch of built-in types that cover like 80% of the required functionality
(booleans, numbers, strings, arrays, closures, maybe also regexps and maps)
and let them implement the rest as libraries without worrying that their new
type "looks just like a built-in".

------
reedF211
Garbage Collection, Garbage Collection, Garbage Collection, where is garbage
collection?

~~~
X-Istence
Left out, which IMHO is a good thing. The C++ language as it stands right now,
especially with the C++0x additions has provided plenty of new features that
are going to help developers build amazing software with more power.

Not everyone wants or needs garbage collection and it would be a downright
pain to bolt it on now.

Feel free to use one of the umpteen other programming languages that does
provide garbage collection, clearly if you are complaining about that you are
simply using the wrong tool for the job.

~~~
gte910h
C++ has garbage collectors. They're just not standard:

<http://www.hpl.hp.com/personal/Hans_Boehm/gc/>

<http://developers.sun.com/solaris/articles/libgc.html>

[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2005/n183...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2005/n1833.pdf)

------
nuttendorfer
Can somebody recommend a good C++ book without all the new to programming
parts?

~~~
kenjackson
Yes, the following I recommend:

Advanced C++. [http://www.amazon.com/Advanced-C-Programming-Styles-
Idioms/d...](http://www.amazon.com/Advanced-C-Programming-Styles-
Idioms/dp/0201548550)

Any and all Herb Sutter books.

Effective C++, More Effective C++, and Effective STL ... all by Scott Myers.

With those you're 90% set. What you'll need to supplement with thoough is
something that covers the 0x standard.

