
Why I haven't given up on C++ - DmitryNovikov
https://josephanders0n.github.io/2016/02/12/why-i-haven-t-given-up-on-c.html
======
taneq
C++ is a language that's easy to code badly in, but that doesn't mean it's
hard to code well (portably, maintainably, effectively) in.

IMO it's a language that well suits pragmatic programmers who are willing to
cherry-pick the most convenient and productive features for their projects and
leave the rest alone.

It's a terrible language for those of us who compulsively try to be clever and
use every little nook and cranny of the language they're using. They get lost
out in the dark scary corridors and spiderwebs, and then say "C++ sucks"
instead of "what the hell, don't go out there unless you really NEED variadic
templates today."

Edit: And it's easy to get yourself in really weird pickles if you don't know
what not to do, (static initialization order, I'm looking at you!) I've found
my WTF-per-minute rate has dropped dramatically over the years as my coding
style has improved.

~~~
DanielBMarkham
Yes. C++ used to be my favorite language. I still like it a lot, but I no
longer love it.

The trick, in my opinion, to C++ was what you were _not_ doing. Coding in such
a rich language means making a lot of decisions up front about limiting
complexity. That turns out to be a good thing.

The reason it's not my favorite anymore? Because the language designers seem
hell-bent on continuing to make it more and more feature-ful. Over time, it's
creating a huge, diverse codebase, all with the title "C++ code" on it, but
all vastly different in nature and scope. That ain't a good thing.

STL is a good example. On its own, STL is a good thing. Greatly needed in the
language. But now that its implemented, its basically its own system. You
could solve world hunger with STL (I am being factitious to make a point)
Remember the criticism Microsoft always had, that they couldn't build anything
that did just a few things? Everything had to be able to do everything? C++
has that, only worse.

I like the language. I really do. I don't know if I've given up on it --
unless I wanted to tweak the hell out of something or was writing lower-level
code the answer is probably "yes" \-- but it seems to be heading in a
direction that is not good for the maintenance programming community. It's
great for really smart people who love complex things, but no so much for the
poor schmuck coming in 10 or 15 years later. It's become a monster.

~~~
CyberDildonics
I'm not sure why you say that about the STL - you didn't give any examples.

Having worked with it a large amount at this point it seems to me to be mostly
very well designed and focused on fundamentals of the parts of a program that
are both common and non trivial.

Some things are messy (like hashing) some things are missing (like
serialization) and some things would be incredible to have (like thread local
heap allocation, lock free concurrent data structures, some sort of dynamic
stack allocation, the functionality of something like capnproto, shared memory
and memory mapping...), but in general it seems like it covers the
fundamentals well.

------
zelos
_Right now, C++ is less portable than Java..., that really have this ‘write
once, run everywhere’ thing._

As someone who's currently rewriting a massive Java project in C++ _so we can
port it to other platforms_ , this made me laugh.

It reminds me of that physicist joke about spherical cows. "Assume a working
JVM..."

~~~
reacweb
I have the migration studies for a big software base containing C++ code, Ada
code and Java code (around 30% each). The migrations were from HPUX to
RedHat4, then to RedHat5, then to RedHat6.

Each time, more than 90% of the migration workload was on the C++ code.

~~~
z92
Maybe that's because C++ was used mostly for system level calls, and low level
jobs.

~~~
qb45
One advantage of Java is huge standard library with basic support for
important OS-specific things like filesystem, threading, GUI, time, etc. You
don't get all the bells and whistles of your OS, but you can write portable
code which works and does some simple things expected to be possible
"everywhere".

C++ only recently is starting to go there.

------
hellofunk
I've been having so much fun writing functional programs in C++14 after
spending 2 years writing exclusively Clojure code. It was amazing to me that I
could return to C++ and use most of the same idioms and styles that I'd gotten
spoiled by in Clojure. The ability to pass and store anonymous functions, with
captures when desired, is so useful, and doing this is easy in C++11/14\. It
has really changed my appreciation of the language. The algorithm library for
doing things like map, reduce-style expressions is also wonderful. C++ is a
rapidly moving target and they are not resting on the past.

~~~
swah
This could be a blog post ;) What compilers do you use?

~~~
hellofunk
I use clang. There are a number of good c++ bloggers out there, so not sure
I'd add anything worthy to the mix.

~~~
swah
I meant the "write C++ like Clojure" part! That transition ain't common,
AFAIK.

------
IshKebab
I do like C++, but I do find myself more and more finding bugs that would have
picked up in another language.

"Huh. I'm pretty sure Rust would have picked me up on that bug."

Here's an example. I accidentally wrote this:

    
    
        while (getLine(pc, buffer, sizeof(buffer) > 0))
    

Which compiles fine. Stricter languages could detect this bug.

~~~
mpweiher
Most likely two bugs. The bracket one, and the fact that sizeof(buffer) will
give you the pointer size, not the buffer size if buffer is a pointer rather
than an array.

~~~
eddyb
The first one would be caught in Rust as it has no integer -> boolean
automatic conversions (similar to Java).

The second one could only arise with unsafe pointers in Rust, as safe code
uses slices, combining the base pointer and the element count in a single
value.

~~~
masklinn
> The second one could only arise with unsafe pointers in Rust, as safe code
> uses slices, combining the base pointer and the element count in a single
> value.

OTOH the point here is to pass a preallocated but "uninitialised" buffer to
the callee, which Rust wouldn't allow with slices, unless you created a slice
from a raw allocation (I don't know if that's defined behaviour, though I
guess you could do that safely by passing in a Write rather than the slice
itself, but then you're Write-ing to a slice which has… interesting behaviour)

------
JanneVee
I've given up on finding another C++ programming job for the foreseeable
future. The problems I have is not with the language itself it is the other
C++ programmers I have issues with. Not to say that I don't think the language
doesn't have issues. With proper care you can work around the issues and avoid
overcomplicating the code. But occasionally you have other C++ programmers who
just makes things too complicated and don't realize that they have done so.

~~~
nmeofthestate
In my personal experience, C++ suffers from a surfeit of programmers who don't
have a perspective on just how unproductive C++ is, and fall into the trap of
considering themselves as an elite based on the complexity of their language
of choice. I'd recommend C++ programmers learn how other languages have moved
far beyond C++ in usability, because that will help them in writing C++.

~~~
CyberDildonics
Can you give an example of a language that goes beyond C++11/14 in both speed
and usability, including tools?

------
inDigiNeous
It's easy to bash anything, to find only bad things in something. And to let
go, give up and get frustrated and write blog posts like this.

Sure, most of this stuff is correct, like the header madness, but still C++11
especially is pretty nice these days. There just isn't any other way to do
cross-platform, performant code, while having the compatibility with all the
C/C++ libraries out there.

I feel C++11 could use some kind of new approach, like "Lean C++11" which
drops all the legacy crap that is holding back adaption for new developers,
who now have to go through maybe 15-20 years of legacy coding styles in order
to find the modern way of doing things.

But this would break backwards compatibility, so maybe better focus on Rust or
something else that is set to do things correctly.

I still like C++, although it is more difficult to write in. Add in a
scripting language like Lua to C++ and you have a very performant and nice
stack of scriptability and close-to-the-hardware stack that feels super
powerful.

------
rsp1984
_Most C++ IDEs have problems, probably because C++ is a difficult language to
fully parse. I’ve only ever used Visual Studio and KDevelop._

That's me, about seven years ago. Then I tried Qt Creator. Now I'm an
evangelist. It just works. It parses all your code in seconds and you get
autocomplete and syntax coloring that's very close to perfect. The interface
is as clean as it gets. And yes, you can use it without ever touching Qt (the
framework) at all.

The only thing is, try to avoid versions > 3.2.2 since they are a bit buggy.

Edit: fixed typo.

~~~
kozukumi
I want to use QT Creator but I find some things frustrating such as finding
out how to change compiler options in a reliable way. Sometimes it is
QMAKE_CXXFLAGS or some other option in the .pro file. In every other IDE it is
a tick box in project settings. Yes yes I know a tick box sucks but it sure
makes things easier to remember how to do rather than yet another cryptic bit
of text in a config file, I have enough of that anyway.

~~~
RotsiserMho
This can be avoided by using CMake as QtCreator supports it as a project type.
CMake isn't exactly a bastion of simplicity however.

~~~
kozukumi
To be honest I am just very lazy and would appreciate a simple GUI to make the
build and project files. I guess Visual Studio has made me lazier ;)

------
AnthonBerg
C++ is fool's gold.

Its complexity is inefficient and this gives the sensation of power and
accomplishment, when all we have done is waste energy on translating abstract
thought into a fragile foam of symbols. Then finally there is a sad degree of
orthogonality between the meaning and structure of said foam and our original
thought. But it sure feels like we did something. We slaid that dragon good
eh!

------
fenesiistvan
Brian Will says that that whole OOP concept is bad (not to say about C++ which
is OOP in the ugly way):
[https://www.youtube.com/watch?v=QM1iUe6IofM](https://www.youtube.com/watch?v=QM1iUe6IofM)

------
abhi152
I am interested on your views about Portability. While Boost and STL are
portable in terms of static compilation Boost gives you very painful bugs at
runtime :(. I also would like to know why you say that Java is portable on
paper ?

~~~
RotsiserMho
I've used parts of boost extensively on embedded platforms and cross-platform
projects without ever encountering painful runtime bugs. What issues did you
have?

------
hellofunk
My own take on the original article that this author is responding to:

>C++ IDEs suck. Big time.

I find Xcode quite a pleasure to use. The autocompletion, debugging, the quick
moving around the interface, splitting files side-by-side.. I haven't used
other IDEs besides emacs, but nothing about Xcode is getting in my way.

>It’s an unmanageable language.

Compared to a dynamic language or a weakly-typed language (I'm looking at you
C, and a few others), I'd say the strong typing of C++ alone helps in code
manageability. And, unlike Swift or Clojure or other languages, I find putting
an API in a header file and an implementation in a translation unit really
helps me reduce time later on. It's an automatic API summary without needing
to review your implementation. When I move on from one part of a program to
another, I don't want to study my source code just to remember what the access
is. Just show me the header. I miss header files in other languages.

>It’s a counterproductive language.

and

>STL sucks.

The tools in the STL are serious time-savers. Sure you can choose not use them
or implement your own, but in either scenario, you will likely spend a lot
more time writing code than working on your actual problem or idea. In that
regard, I'd say C++ and its standard library are very productive. And all the
new multithreading and async primitives in C++11/14 take this productivity to
a new level.

>namespace stupidity

Without namespaces, you have to work harder to name your stuff and to debug
name clashes. Every good language that I've worked with uses namespaces. I
consider them a requirement for any language that will handle a large project.

>The language sucks. It sucks because it’s so complicated.

C++ is probably the most complicated language I will ever use. I'm not sure
why that makes it suck, though. Unlike many other languages, where it is wise
and expected that you can keep the whole language in your head and understand
entirely how it works, C++ is a different thing altogether. Nobody on this
planet probably understands 100% of C++ -- including its creator, who has said
that he gets maybe 80% there. In C++ you can use a small and ordinary part of
the language and choose to go to the complicated stuff only if you really
_want_ to, but rarely do you _need_ to. Yes, complex metaprogramming is mind-
bending in what you can do -- and also, you cannot do a lot of it any other
language. But you don't have to do any of that, and most people probably
shouldn't, until they want to have some fun and really see how deep C++ can
go. And a lot of the most complicated stuff that was important to understand
in the past is no longer required reading for new programmers to the language,
since the latest standards handle many things for you automatically. I.e. just
writing "new" or "delete" and deciding when and how to do so are no longer
required and actually discouraged thanks to smart pointers.

~~~
wallacoloo
> I find putting an API in a header file and an implementation in a
> translation unit really helps me reduce time later on. It's an automatic API
> summary without needing to review your implementation. When I move on from
> one part of a program to another, I don't want to study my source code just
> to remember what the access is. Just show me the header. I miss header files
> in other languages.

`make doc` (maybe as part of your build process even), then view the
autogenerated API documentation. This is at least a feature or extension of
most languages. C++ even has a number of documentation suites (e.g. Doxygen,
IIRC).

Furthermore, if you're using a "good" IDE, I would expect it to be able to
provide you the same basic information you get from header files (i.e. method
signature & names). It could at the very least have a "collapse function
implementations" hotkey to allow you to view a source file as if it were
essentially a header file.

I don't know, the fact that it's somewhat trivial to actually generate a .h
file _given_ a .c or .cpp file (look up LZZ - Lazy C++; it's not maintained,
but it did exactly this) makes them seem pretty much useless to me.

------
hathym
C++ is the new Cobol

~~~
jacobush
Nah, PHP is the new COBOL

~~~
osullivj
Nah, Java is the new COBOL. Billions of LOC that will never be replaced,
running on arcane infrastructure. In this case the arcane infrastructure isn't
mainframe hardware or OSes, it's J2EE bean containers, XML configged ORMs, and
Ant build systems.

~~~
jacobush
You are right, of course. Maybe PHP is the new VB?

------
raverbashing
"I agree it’s complicated, but that’s not necessarily a bad thing. You really
don’t need to understand the whole thing to start using it. And when you’ve
been using it for a while and start to understand the intricate details, it
becomes very, very powerful."

To be honest, this is a corporate sales pitch. It's trying to justify the
injustifiable

It doesn't need to be full of "features" that most people don't use. Granted,
some of them are needed regardless

C++11 and 14 have simplified some parts, which is good. Still, a lot of other
languages do more with less complexity

Some things that are painful

\- String formatting in STL is a joke

\- "Smart pointers" are still an add-on and clunky to use

\- No reflection. Manual setup of getters/setters/copy constructors

~~~
autoreleasepool
What's wrong with std::string though?

~~~
hellofunk
Compared to how strings are handled in many other languages or libraries,
std::string is pretty limited. It works, though, and I use it. But when you
have to do something basic like a trim, you find yourself wondering why it's
not included.

~~~
CyberDildonics
[https://github.com/imageworks/pystring](https://github.com/imageworks/pystring)

