
Stroustrup on next-gen C++: I didn't want to let go of my baby - cpeterso
http://www.theregister.co.uk/2012/12/13/stroustrup_on_c_plus_plus/
======
blub
The idea of languages adhering to some sort of standard and not being owned by
a corporation rings true.

I can see this first hand with Objective-C, where Apple evolves the language
as they see fit. The joining of such different paradigms as Smalltalk-style OO
and C was fragile in the first place and can barely sustain the new
functionality.

Another example is C#. No matter how nice the language becomes, it will always
be the MS language for me, and I don't trust MS when it comes to APIs and
languages - they shuffle things around for no reason, cancel projects, etc.
And then you're screwed.

~~~
meaty
I think the notable exception to that rule is Go.

Go is imported by Google, not exported by them.

It's also got good funding, a large number of well known core team members
(who won't let it die) and a good license which protects the users in the
future.

~~~
dbaupp
Could you explain the "imported" comment? (I don't know much about the history
of Go, and it looks a lot like Google is exporting it.)

~~~
meaty
Google don't really prescribe what happens with Go from what I can see. It's
left up to the Go team who's focus is to produce a general purpose language
and the community who want a stable product that fills their needs as well.
Google take the stable release and use it internally. Therefore Google import
it from the community project.

Some other notable organisations develop everything internally and then
release it to the public i.e. they export it. For example C#.

~~~
olaf
> who's focus is to produce a general purpose language

More a "solve Google's specific problems" language, general Google purpose

~~~
dualogy
Um, nope? What exactly is google-specific about it? Nothing from what I can
tell. It's as general-purpose as C or Python or JS etc etc. In fact, it's
basically C, slightly redesigned from scatch for this decade rather than the
one 30 years ago...

~~~
kibwen
It's not dictated by Google management, but it's definitely directed by Pike
et al to address the concerns of companies developing software at Google's
massive scale.

As an example, C++ and Java programs at Google were taking more than half an
hour to compile. This is why Go's semantics were chosen with speed-of-
compilation in mind:

* Strictly acyclic module hierarchies (greatly simplifies compile-time name resolution)

* No generics (specialization has a compile-time cost)

* Unused imports are a fatal compilation error (to avoid having to parse unnecessary files)

All three of these decisions are somewhat contentious; Pike admits as much in
many of his talks. But they were chosen because of the challenges of writing
software at Google's scale. It is in this roundabout way that Go "belongs" to
Google, in the sense that it addresses problems that Google has and
prioritizes the best solutions to those problems, whether or not those
solutions are at odds with the needs of non-Google users.

------
nicholassmith
Stoustrup is right, there's many dark and really dank corners of C++ and
people start poking around in them and bringing them into production code and
that's just bad for everyone. It's like tigers, tigers are awesome and it's
great that our ecosystem has developed to support them, but you don't put a
tiger in your house.

I do C++ dev work for a living, I enjoy it. The language can be a nightmare,
but as long as you're sensible and frugal with what you're using it's no worse
than anything else. The trick is to really, really think about whether a
specific feature is worth taking into a more complex direction with some of
the edgier C++ functionality, or sticking with more core, basic,
understandable code which might trade off performance.

I should probably say I've not done any 'proper' C++ development for a while,
mostly we build with Qt and that abstracts a lot of the headaches away into a
nice toolkit.

~~~
betterunix
"as long as you're sensible and frugal with what you're using it's no worse
than anything else"

That is part what makes C++ worse: the fact that being a C++ experts primarily
means knowing what not to do.

~~~
nicholassmith
Being an expert in any language means knowing what not to do, more than
knowing what you should do.

~~~
betterunix
Really? When someone says they are an expert in Java, they do not mean that
they are well-versed in what sort of Java statements have unexpected,
undefined, or indeterminate behavior. Even more so when someone calls
themselves an expert in Lisp, Haskell, Scala, and other high-level languages.
We are not talking about maintainability or style, we are talking about just
being able to solve basic computational problems without having your program
abort. In addition to this entire book on what not to do, books on advanced
C++ programming (like the "Effective C++" series) are loaded with things you
shouldn't do:

<http://www.semantics.org/cpp_gotchas/index.html>

C++ also encourages programmers to do "bad things," where other languages
discourage such code. In Scheme, arguments to functions are evaluated in an
undefined order, and so such arguments should never have global side effects;
but Scheme discourages global side effects in general. In C++, arguments to
functions are also evaluated in an undefined order...but global side effects
are encouraged and widely used in C++, and it is easy to inadvertently create
a situation where this becomes a problem (e.g. one argument might resize a
vector, when the other is an iterator to that vector -- both common, both
encouraged, but a pretty bad combination). C++ makes the most dangerous ways
to do things the easiest and least verbose: pointers to access arrays, fixed-
width integers, floating point numbers, etc.; other languages make such
dangerous things more verbose and force programmers to be explicit when they
try to utilize such constructs.

------
nnq
Out of curiosity, if one wanted to "re-learn modern C++" after years of Java,
Python, Ruby, where could he start from? (something like a "crash course") Is
Stroustrup's "Principles and Practice Using C++" any good for this purpose?

~~~
dkarl
Principles and Practices is a book for people who have not programmed before.
Unfortunately, the book you want is the fourth edition of The C++ Programming
Language, which will not be available until April:
<http://www.amazon.com/dp/0321563840>

~~~
nnq
yep, I'll probably order it when it comes out ...though it's definitely not a
"crash course" :)

------
happywolf
I tend to think the new C++ is apt for a new project with no historical
burden. We can always use the more modern features. However this may not hold
true for existing projects with a number of developers

~~~
meaty
Except that's not how it works. The realistically high skilled C++ people are
far and few between so you end up with a shit crock cludged together out of
vaguely bastardised MFC'ish code, knotted with Win32 and ATL and Boost with a
load of "features which were too dangerous to use" removed.

C++ has such a bad legacy, it's going to be really hard to shake off the bad
old days.

Perhaps in time when the newer generations actually have been using C++11 for
a while, but not for at least 5-10 years if you ask me.

~~~
wslh
Beyond the complexity of C++ I think one of the biggest problems with it is
the lack of self sufficient standard libraries. There was always something
extra that needs to be done. For example, simple things like converting a
string to a number involves more thinking and knowledge (using string streams)
that what is really necessary.

~~~
ksherlock
c++11 includes std::string/number conversion.

eg:

int stoi(const std::string& str, size_t *pos = 0, int base = 10); std::string
to_string(int value);

<http://en.cppreference.com/w/cpp/string/basic_string>

~~~
wslh
But it's 2012! it's late.

------
rplacd
> “A lot of people look at C++ and want to understand every dark corner. This
> is what you do if you want to be a compiler writer, but most people should
> look at what is the easiest way to write a good solution for their problem,"
> said Stroustrup.

Ha! So even Soustrup agrees C++ is inevitably subsetted by its users.

> “I try to focus on things that lead to correct programs fairly easily. I
> emphasise the use of constructors to establish invariance, to acquire
> resources, destructors for cleaning up, copy operations, and the new [C++
> 11] move semantics that allow you to move an object out of one scope and
> into another one very cheaply," he added.

Keeping the rest of the quote here - now I'm looking for a more abstract and
more inclusive notion about what constructors and destructors do.

------
robot
what an ugly baby that is...

------
popee
Whata possessive father :-)

