D - more or less power than C++?

[Walter Bright]

"Kevin Bealer" <Kevin_member at pathlink.com> wrote in message 
news:dub5c4$2lo2$1 at digitaldaemon.com...
> Constructors and destructors in C++ have become something much larger than
> memory cleanup.  They provide a syntactic tool that plays almost the same 
> role
> as (and complements well with) assertions and contract programming.
>
> For instance, in C++ I can write a mutex class like this (I'll use D 
> notation):
>
> class Mutex {
> ,  void Lock();
> ,  void Unlock();
> ,  bool is_Locked();
> };
>
> ,class MutexHolder {
> ,   this(Mutex x);
> ,
> ,   void Lock()   { assert(! am_locked); x.Lock();   am_locked = true; }
> ,   void Unlock() { assert(am_locked);   x.Unlock(); am_locked = false; }
> ,
> ,   ~this()
> ,   {
> ,       if (am_locked) {
> ,         assert(my_x.isLocked());
> ,         my_x.Unlock();
> ,       }
> ,   }
> ,}
>
> If you insert enough assert() tests, you can virtually guarantee that you 
> either
> have perfect locking, or die (or hang) at the point of the first usage 
> error.
>
> But the ability to check for correct state, or unlock things, in the 
> destructor
> is CRUCIAL to this kind of testing.  I worked for a few years in C 
> language file
> system code that did not have these guarantees.  We were constantly 
> hunting down
> mysterious hangs.  Doing locking via object lifetime is an excellent way 
> to
> enforce a kind of whole-system behavior -- that is what's powerful.
>
> But D can't do this kind of thing, AFAIK.  The RIIA works for a class, but 
> I
> can't nest classes this way.  I can't tell class Foo that it owns Bar in 
> "auto"
> mode.  I suspect that this would interact badly with "dup" if it was
> implemented.  I'm not sure what to do about that, unless there is an 
> "opDup()"
> method (I like this idea, but its another been-discussed idea.).

Is it really necessary to tell the compiler you own a class member, rather 
than doing it by convention?


> If you write a class in C++ to wrap an integer for some reason,
> its only 4 bytes.

So it is with a D struct.

> You can replace a set of integers (this is usually done if you have at 
> least a
> pair of ints) with "managed" ints or int-pairs, that guarantee some 
> property.
> If the guarantee is done via debug-mode-only testing, the class really 
> does turn
> into primitive types in release mode.

debug
{    struct myint
    {
        ... management code ...
    }
}
else
{
    alias int myint;
}

> Unfortunately, if I have a container of D structs, getting one out and 
> calling a
> method, copies the value out - I can't set fields via "container[i].x = 
> 5;" the
> last time I checked.

Can you post an example of this?

> I'm also thinking there is one restriction that may make this easier - if 
> the
> auto class could only be owned by a function scope (as currently) OR 
> another
> auto class - this would fix the unknown-delete-order issue for auto 
> classes,
> because it would mean that every auto class knew it was not garbage (and
> inductively, its children arent garbage) at destruct time.

I'll have to think about that.