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