C++17

[H. S. Teoh via Digitalmars-d]

On Wed, Jan 27, 2016 at 12:16:58AM +0000, Atila Neves via Digitalmars-d wrote:
> On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:
> >"With C++xx, there's little benefit to switching" is a very common
> >sentiment among current C++ programmers. And it's probably true.
> 
> It's not true.
> 
> After failing to convince my coworkers to use D, I wondered about
> this. I actually thought, myself, that C++14 is good enough and nearly
> like writing D. I was wrong.
> 
> I've recently spent about 2 or 3 months writing C++14 at work. I ended
> up complaining a lot. Most of the time because I'd written a bug that
> wouldn't have happened in D. The rest was usually due to something
> supposedly simple taking an inordinate amount of work.

This reminds me of the time when I wanted to make a "trivial" change to
an old C++ project of mine. This was after I had become acquianted with
D, and gotten used to built-in AA's. I noticed that C++14 finally
officially had hashtables in the standard library (which is worth a rant
in itself -- who has ever heard of a modern programming language that
has no standard hashtable implementation until how many decades
after?!), and was eager to finally try it out in my code.  It would be a
simple task, I thought; simply plop in the new standard hashtable at a
strategic point in the code to serve as a cache, and performance should
improve. Right? Right??

Many hours later, I was tearing my hair out trying to resolve stupid
issues like:

1) You cannot instantitate a hashtable template without also specifying
   a hash function. WAT?! No built-in hash function??! Well, yes there
   is, except...

2) The standard hashtables have no standard hash function for structs.
   You have to write your own.  WAT??!

3) After you have a hash function, you have to create the hashtable with
   an explicitly-attached hash function -- it's not a template
   parameter, it has to be a function object passed to the hashtable's
   ctor. Which means passing around the hash function everywhere all
   over the code, wherever there's the need to create a hashtable.
   Arghh...

I'm pretty sure with a "little" more effort I could have made it work...
but seriously, that was several *hours* compared to the 2 seconds it
takes in D to add an AA to your code.

You people who think there's still enough reasons to stick to C++ crack
me up.  Do you have any idea what on earth you're talking about?!


[...]
> The penny really dropped when I wrote D again for the 1st time after
> weeks and weeks of C++14. It was night and day. Suddenly my thoughts
> started getting to converted to code all that faster, with fewer bugs
> to distract and annoy me.

Exactly!!!! If that project of mine had been in D, it would have taken
me at the most 5-10 mins to code, test, and debug the new code change.
With C++, it took several hours and it still hasn't gotten off the
ground yet.  This isn't some isolated incident or unfortunate
coincidence either.  C++ is full of convoluted idioms and needlessly
complex paraphrases to shoehorn modern programming techniques onto a
decrepit and dying ancient core. Make one mistake and you're faced with
either a memory leak, an untraceable pointer bug, an off-by-1 bug, or
some other kind of nasty, hard-to-debug problem. Oh, right, we're not
supposed to touch malloc/free or new/delete anymore, we're supposed to
wrap those in "safe" library abstractions. And we're not supposed to
used naked pointers anymore, it should be one of those fancy black magic
pointer wrappers that do ref-counting or some such. Ergo, convoluted
idioms and needlessly complex paraphrasis for what, conceptually, ought
to have been a straightforward 5 lines of code, that comes out in C++ as
50+ lines or more.


> Don't get me wrong: I vastly prefer C++14 to C++98 or plain C. But
> even modern C++ needs this:
> 
> https://en.wikipedia.org/wiki/Erase%E2%80%93remove_idiom
> 
> Which is, quite frankly, ridiculous. Do you know how you split a
> string in C++? You install boost, that's how.
[...]

The fact that boost is required to write anything non-trivial in C++
without reinventing the square wheel or pulling all your hair out, is a
sign that something has deeply gone wrong with the language. Yet its
proponents continue to stab themselves with knives and revel in the
pain, since C++ is, after all, still superior, especially over that
pathetic failure called D. "I can't write D code in the same painful,
bug-prone, productivity-killing way as I write C++ code, so D sux!"

I suppose it's too much of a sacrifice for C++ coders to write code in
less painful, more bug-free, and more productive ways. After all, what
about the job security??!

(And lest you think I'm just a rambling lunatic, here's another ex-C++
coder who sees it the same way:
http://bartoszmilewski.com/2013/09/19/edward-chands/ )


T

-- 
If you compete with slaves, you become a slave. -- Norbert Wiener