
Why not C++? - cronjobber
http://lambda-the-ultimate.org/node/5313
======
pmarreck
C++ is still plenty viable, but if you like avoiding bugs, John Carmack seems
to have come to the conclusion that using a functional style (which is not
exactly _encouraged_ by C++) is advantageous:
[http://gamasutra.com/view/news/169296/Indepth_Functional_pro...](http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php)

"My pragmatic summary: A large fraction of the flaws in software development
are due to programmers not fully understanding all the possible states their
code may execute in. In a multithreaded environment, the lack of understanding
and the resulting problems are greatly amplified, almost to the point of panic
if you are paying attention. Programming in a functional style makes the state
presented to your code explicit, which makes it much easier to reason about,
and, in a completely pure system, makes thread race conditions impossible.

"No matter what language you work in, programming in a functional style
provides benefits. You should do it whenever it is convenient, and you should
think hard about the decision when it isn't convenient."

------
jcoffland
C++ is still a fantastic language. It's hard to learn to use it effectively
but once you do you have one of the most powerful programming tools available
under your belt. The two main points to using C++ effectively are 1. you must
protect allocated resources with smart pointers and 2. threads should only be
used to exercise multiple CPU cores and never as a way to work around blocking
IO.

That later point is a little more complicated/subtle and took me years of
threaded programming to learn and accept. When adhering to these two rules,
C++ is safe and extremely powerful.

~~~
allcentury
Any reading you'd recommend regarding your second point? I've never heard that
about C++ before.

~~~
stefs
i think this is strange. i'm not a c++ programmer, but the evented frameworks
(node.js or vert.x) are doing it the other way round: use threads _only_ for
IO (or computation so heavy it's practically blocking). the complete opposite.

~~~
misframer
libuv (used by Node.js) uses epoll, kqueue, etc. for network I/O. It uses a
thread pool for all file operations.

~~~
stefs
ah, well - when reading "blocking io" i first thought about the file system.
so does my point still stand? using a threadpool for disk IO does go against
"threads should only be used to exercise multiple CPU cores and _never as a
way to work around blocking IO._ "

or am i still not getting this?

------
justinsaccount
I had this to say about c++/go recently:

Working on a c++ project: I feel stupid... and nothing works.

Working on a golang project: go is stupid... but everything works.

My issue with c++ is someone needs to write a "c++: the good parts" I may end
up with rust, but right now I look at the documentation and some rust code and
it's a bit overwhelming.

Go may be stupid in a lot of ways, but for the most part it's pretty obvious
how to accomplish something.

~~~
philbo
It's not exactly the same, but the closest thing to a "C++: The Good Parts" is
Scott Meyers' "Effective C++", imho.

~~~
bloodorange
Unfortunately, there are no updated versions of his books for C++14 or 17.

I owe a lot to the books though.

~~~
santaclaus
Effective Modern C++ covers C++14, and specifically points out where it
differs from C++11 (I'm thinking about the discussion of decltype, here).

------
jacques_chester
Summarising how I usually seeing these discussions go:

The usual argument goes that C++ is bad because of the problems of C.

The counter-argument is that "nobody does that in modern C++".

The counter-counter argument is that:

1\. there's a _lot_ more not-modern-C++ than there is modern C++.

2\. there seem to be dozens of not-really-smoothly-interchangeable notions of
what "modern C++" is, because the language is so vast, and there have in fact
been several overlapping generations of "modern C++".

3\. It still requires conscious and vigilant effort, over and above the
baseline the language gives you, to not introduce game-over security or
reliability flaws.

The counter-counter-counter argument is that these are true of every language.

Which, being not strictly and completely true in the particulars, is where the
whole thing degenerates into personal reflections about $PET_LANGUAGE, hair-
pulling, personal insults, blog posts about monads at twenty paces etc etc.

~~~
MAGZine
> 2\. there seem to be dozens of not-really-smoothly-interchangeable notions
> of what "modern C++" is, because the language is so vast, and there have in
> fact been several overlapping generations of "modern C++".

Everyone I've talked to understands modern C++ to be C++11 or newer.

~~~
titanomachy
C++11 _adds_ to the language, but is there a strong consensus on what parts of
pre-2011 C++ are _not_ allowed in "Modern C++"? I have seen C++ code
advertised as "modern" that still uses naked pointers, for example, while
others claim that all pointers should be reference-counted. There is no
agreed-upon algorithm that answers the question "is this source file written
in valid Modern C++?", because there's no agreement on what that means.

------
quchen
Cached version: [http://webcache.googleusercontent.com/search?q=cache:UB-
yaeW...](http://webcache.googleusercontent.com/search?q=cache:UB-
yaeW3LgcJ:lambda-the-ultimate.org/node/5313+&cd=1&hl=en&ct=clnk&gl=de)

~~~
marxidad
It's ironic that they use PHP.

~~~
21
Which is written in C, and all the major C compilers today are written in C++.

The circle of life :)

------
zoul
While I admire the amount of thinking that went and still goes into C++, for
me the question is opposite: why ever C++? It seems to me that trying to
improve a language by ecosystem or convention will always be worse than using
a language already designed around what we have learned and what has changed
since C++ was born.

If somebody _really_ needs to have the performace or be that close to the
hardware, they can still probably find a better language today (Rust, Go?).
But all others will certainly be better served by more modern, higher level
languages. Just reading the examples in the PDF makes my head hurt.

~~~
CJefferson
My main argument against Rust is the existence of D.

Over the years several languages have been the 'C++ killer'. For quite a long
time it was D, and I know several people who converted. Then the standard
library split in two, and the language got fairly unusable for a while. Now
things have calmed down with D 2.0, but it's not clear it will still be around
in 10-15 years time.

Similarly with Rust -- at the moment it seems to be a one company product
(Mozilla). What if they get bored of it? Will my Rust code still work in 10
years time?

~~~
x0x0
I asked about this and some Rust folks were kind enough to mention that
Dropbox is one company that publicly has a large Rust deployment. Further, I
think the main (huge?) advantage of Rust is it was designed to allow in situ
replacements of pieces of a large c++ codebase. This really is a killer
feature for lots of folks who simply can't afford to rewrite tens of millions
of lines of tested c++.

previous discussion:
[https://news.ycombinator.com/item?id=10890310](https://news.ycombinator.com/item?id=10890310)

------
jokoon
The only thing that has always been behind, and might still be for a couple of
years, is the include system, which causes huge delays when compiling and
linking, even when editing one single file.

When I make edits and hit build, the old C include system kicks in and it's a
very long process. I'm using C++ but precompiled headers are not a standard
(many details will prevent you to use them) and there are not decent ways to
reduce build time to bearable ranges.

I'm sure this is the main point that makes C++ so unattractive. If you're a
programmer, having shorter code-write/build/test/repeat cycles is important if
you don't want to lose focus on what you're doing. I don't know if build
delays are specific to C++ or specific to microsoft, but if modules were
available in some beta form I would try them ASAP. Even platform specific
techniques would interest me...

So yes, I'll love C++, but not only the ABI and build configs are not easily
solved by CMake, but build times will never make C++ attractive enough. It's
not not realistic to pretend you can be really productive with C++.

~~~
santaclaus
Modules were just put into a TS so hopefully we'll get them in C++19. I would
_love_ to have them now, however.

------
sehr
cache

[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://lambda-
the-ultimate.org/node/5313)

------
dman
Site is down so I cant comment on content from the article.

As a working programmer here are some things that I consider to be C++ virtues

a. Control over memory layout

b. Control over allocation policies

c. Deterministic deallocation of objects on scope exit

d. Generics and specialization of generics

I am always mystified how many languages miss out on item a.

------
timwaagh
I clicked the title and it provided a great answer. something about mysql not
connecting. i thought it answered the question until i googled it. a better
title would be 'why not php'.

------
cyber1
Because we have Rust!

------
Gratsby
LOL... why not PHP.

