Three Unlikely Successful Features of D

Nick Sabalausky a at a.a
Tue Mar 20 18:59:27 PDT 2012


"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
news:mailman.933.1332286692.4860.digitalmars-d at 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! :)




More information about the Digitalmars-d mailing list