"H. S. Teoh" <hst...@quickfur.ath.cx> wrote in message news:mailman.933.1332286692.4860.digitalmar...@puremagic.com... > On Tue, Mar 20, 2012 at 06:58:31PM -0400, Nick Sabalausky wrote: >> - Type inference > > Yeah I forgot about this one. Being able to write: > > auto veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); > > is a big boon over C++ or Java's stuttering verbosity: > > VeryLongNamedClass veryLongNamedObject = new > VeryLongNamedClass(veryLongArguments); > > Plus, it's immensely useful when dealing with Range templates... can you > imagine the horrifically long typenames you'd have to type you have to > explicitly specify the type of a long chain of functional expressions > involving 15+ std.algorithm and std.range templates? > > >> - alias > > This, together with static ifs and templates, make for awesome tricks > involving templates that would've been an utter bear to pull off in C++. > > template innerKeyType(T) { > static if (is(T U : U[K], K)) > alias innerKeyType!K innerKeyType; > else > alias T innerKeyType; > } > innerKeyType!(int[string[char[byte]]]) innerKey; > >
Yea, C++'s STL *needs* type inference and alias. At least the new spec has "auto". Don't know about other stuff though. > [...] >> - Built-in associative arrays that support nearly any type as a key > > This is actually quite buggy right now... but that's merely an > implementation issue. :-) Heck, I just love that I can use a string, or an int, or make my own struct work as a key, etc. Actually, over just the last 24 hours I've been making a lot of use of AAs with int keys. (AA's make it *so* much easier to avoid poor time complexity in a lot of things.) Many langauges (like Haxe, for example) will have hashtables, and may even have them templated (or otherwise generic) on *value*, but the keys will be string-only. Which is still very useful, but it also misses out on many other use-cases. > My new AA implementation, for example, > already correctly supports AA's with AA keys, which can be arbitrarily > nested. So you could have something like int[string[char[byte]]], and it > does lookups correctly based on the contents of the AA's you pass in as > key. > Crazy stuff :) Actually I've been meaning to ask what the main benefits of your new AA implementation are. I know there's the benefit of just simply having it be implemented in the library. And you mention using AA's as AA keys here. Are there any other, umm, "key" points? > >> - All the niceities of ctors compared with C++'s ctors > > C++ ctors are a royal pain in the neck. I remember in the early days of > C++ when you can still call the base class ctor in the body of the > derived class ctor... nowadays you have to contort ctor code into a > horrible ugly mess just to get your ctor to do things right. Plus, the > C++ standard requires fields to be initialized in declaration order, > which is needlessly restrictive and basically makes ctors even more of a > pain. > > I ended up using just stub ctors for a lot of my code, and doing the > actual initialization after the object is constructed. Which is very bad > OO style, I agree, but the pain of working with C++ ctors just pushes me > in the wrong direction, y'know? > Yea, that's what I've been planning on doing with the C++ stuff I have coming up. Don't even want to bother with C++'s ctor limitations. Just make an init() member and be done with it. Actually, that seems to be turning into more and more of a common C++ idiom though, from what (little) I've seen. > >> - Scope guards (And even finally: I head somewhere C++ doesn't even have >> finally: Is that true?!?) > > Yes, it's true. I don't know about C++11, but certainly the previous > standard has no finally clause, leading to horribly unmaintainable and > ugly code like: > > Resource r = acquireResource(); > try { > doSomethingDangerous(); > } catch(...) { > r.release(); > } > r.release(); > Haxe also lacks finally! Which I always found rediculous. So yea, I'm intimately familiar with that idiom. I've used it myself far more than I would like. And even *that* still doesn't work if you don't catch *every* exception (and then rethrow the ones you don't care about? Ick!). I've seen C++ programmers swear off exceptions because of this, and I can't blame them at all. Exception systems *need* a finally. > (Yes, yes, I know, RAII and all that... which leads to inventing > ridiculous classes which make no sense in terms of OO, just to wrap > resource handles.) > Yea, if I wanted to write Java-style code, I'd just use Java (and at least not have to deal with header files). > >> - GC > > For all the warts the current GC has, the fact that D has a GC at all > makes things like array slicing possible, and *fast*, which leads to all > the other niceties of slicing. > I used to do indie game dev in C/C++ and I feel downright spoiled now with tossing in a "new" whenever appropriate and not have to worry about cleanup (and even that wouldn't be *too* bad...in certain cases...if there were at least scope guards). > >> - Name any of D's metaprogramming features > [...] >> Alias in particular is a much bigger deal than it seems since it's >> seemingly trivial but can be *incredibly* helpful with templates *and* >> with importing. > > Definitely. Using alias and static if in a recursive template is one of > the hallmarks of the awesomeness of D templates. > I'd say one of the hallmarks of D's metaprogramming is the enormous *decrease* in the need for recursive templates in the first place ;) With C++'s templates, it would appear that you have to use recursion and helper templates for damn near anything. > >> Actually, looking at this list, I'm now starting to get a little worried >> about an upcoming C++ project... No doubt I'll be trying to reinvent a >> lot >> of D in it. Probably in ugly hackish ways. > [...] > > #include "dmd.h" > > ;-) > Heh, yea. :) > > -- > Don't modify spaghetti code unless you can eat the consequences. Hah! :)