Top D Features I Miss In C++

I've spent the last month or so on a project that, due to factors beyond my control, must be in C++ and not D.

A little of my background first: I used C/C++ as my primary language in the late 90's and early 2000's. Liked it at the time, but then got fed up certain aspects and went looking for alternatives. Long story short, I found D, fell in love with it, and have been using it extensively for years.

Now that I'm back in C++-land (hey, it beats the hell out of writing a whole game entirely in a dynamic service/server-compiled toy from the same jokers folks who brought us the wonderful Flash), I've built up a list of the top things I miss from D when using C++. There's plenty of other great stuff in D that I miss, but these are the far...that are proving to be the most painful to live without in the particular project I'm working on (An iOS/Android puzzle-ish game). Other projects would likely have very different lists, of course.

Incidentally, this also serves as a deeper explanation for anyone who didn't understand the vague heckling of C++ in my previous post.

Top D Features I Miss In C++

  1. Proper module system: One of the main things that drove me away from C++ in the first place. The header-file/text-inclusion hack is a colossal, anachronistic pain in the ass. There are so many problems with this one issue alone, I'm not sure they're even worth listing. But I will anyway because they deserve public ridicule:

    C++'s "Module" System Sucks

    • #ifndef _FILENAME_H_: All the reason you need to know C++'s module system sucks. Retarded hack.

    • Identifiers prefixed with psuedo-module vomit: Let's see... CIwFVec4... CIwGameActorImage... WTF? Can I haz FVec4 and ActorImage, plz? Yea, I know there's namespaces, but not everyone seems to use them. Somehow I have a feeling there's a good reason for that - besides just easier interfacing with D.

    • DRY? What's DRY? Derp derp durrr....

    • Scrambled modules! Let's chop up our module and play "What goes where?!?" Implementation files: non-inlined function bodies, non-member variables (which aren't evil globals in a language with proper modules), and private preprocessor directives. Header files: member variables, inlineable function bodies, public preprocessor directives, member accessibility (public/private), non-DRY duplication of non-inlined function signatures, plus includes and forward declarations that should be private but must be leaked out due to something else in the header needing to use them. Whee!

    • Header files are interface documentation? LIES! Seriously, look at your header files. You're really going to try to tell me that only contains the public interface? Then what's that private: section doing in there? And that forward declaration for an external class? If you want automatic documentation, run a damn documentation generator. They exist.

    • Headers affected by whatever headers were included before it: Hygiene? What's hygiene? And why is this compiling so slow? Durrr...I wonder why?

    • Fuck precompiled headers: Talk about "solving the wrong problem".

    • No RDMD (automatic dependency finding): Every...fucking...source file must be manually specified. I remember to do this about half the time.

    • And the #1 reason C++'s "module" system sucks: What is this, 1970?

  2. Actual properties:

    foo->setX(foo->getX() + 1); // Suck my nutsack, C++

  3. Metaprogramming that doesn't involve a text preprocessor or gobs of excessive template instantiations.

  4. Sane type-name syntax: In C++, how do you spell int*[]* delegate()[]* (Ie, a pointer to an array of delegates which take no params and return a pointer to an array of int pointers)? Wrong! The correct answer is "Fuck you, I'm not attempting that shit in C++!"

  5. Type deduction: Unfortunately, Marmalade doesn't yet support C++11, so I don't even get auto.

  6. Closures, lambdas, nested functions: There's a good reason Qt in C++ requires a special preprocessor. (Yea, I'll care about C++11's features when I can rely on them actually existing in my compiler.)

  7. No forward declarations: Was I wrong before? Maybe this is still 1970?

  8. Actual reference types: And no, I don't mean Foo&.

  9. Non-schizo virtual: C++'s member funcs are non-virtual by default...except the ones that are virtual by default and can't be sealed as final. WTF? WTF indeed. (Yes, I do understand how it works, but it works stupidly.)

  10. Default initialization: Granted, I'd rather be told at compile-time about possibly using non-inited vars (ie, C#-style)...But garbage-initialization? Screw that. Especially for pointers, I mean, fuck, really?! Pain in the damn ass.

  11. Fast compilation: Hooray for the world's slowest-compiling language! Whee!!

  12. Polysemous literals: C++ can barely figure out that 2 can be a float. Gotta babysit it with 2.0f. Great.

  13. Ranges: Fuck iterator pairs.

  14. Named immutables/constants that actually exist in the real code, not just the preprocessor.

  15. Designed by someone who actually fucking understands proper engineering.

Things I'm surprised I don't miss yet (but may still miss later and would undoubtedly miss if my project were for a different domain or maybe even just using different engine):

  • Slices and string/array manipulation: Fuck null-terminated strings, fuck pointer/length pairs, and fuck everything in string.h.

  • Associative arrays: Just works. Any key type. No syntactic bullshit.

  • Scope guards: Also known as "RAII that isn't a contrived syntactical kludge".

  • GC: You can pry manual memory management from my cold dead hands, but that doesn't mean I always wanna fuck with it.

  • Foreach: I'm still convinced foreach(i; 0..blah) is essential for any modern language, but my prior experience with C/C++ seems to have left for(int i=0; i<blah; i++) irreparably burned into my brain.

And ok, to be perfectly fair to C++, let's turn things around a bit...

Things from C++ I miss when I go back to D:

  • .......
  • Ummm.....
  • Not a fucking thing.

UPDATE (2012-09-12): Added "RDMD" to reasons C++'s module system sucks. Can't believe I forgot that before, that's a big one.

1 comment for "Top D Features I Miss In C++"

  1. (Guest) German Diago
    2014-12-11 06:28

    Well. I can see you love D. I like it the most together with Rust maybe, but both after C++, for the following reasons:

    1. Top reason: it is really, really practical: lots of libraries, good performance, very usable if you know learn good style (C++11/14).

    2. GC: Well, when I don't want it, it is annoying.

    3. Type system: non-uniform -> polymorphic vs structs. Two worlds, bad for generic programming. For me these 2. and 3. are the big mistakes. Even if 2. allows nice things, yes, but when you don't want it (embedded), it hurts. I know about @nogc, but it is still designed for a GC in general. 3. is directly a bad choice, in my opinion, because the type system should go more in the direction of type-erasure a la boost.any.

    Best D points: immutability, a reasonable level of compatibility with C and C++, threading looks good, pure looks nice, and CFTE is really great, I wish C++ had a general solution for CFTE, especially, even I went to whine to the std proposals for C++, but I think it is not practical.

Leave a comment