structs and opAssign -- why not?

Bill Baxter dnewsgroup at billbaxter.com
Thu Nov 16 18:39:33 PST 2006


The rational for no opAssign in classes clear enough -- when you say 
a=b, it means copying the reference, and to do anything different would 
be odd.  Fair enough.

But the reason for no struct opAssign is just this:

"I've never been comfortable with any object in C++ that does something 
other than a bit copy when copied. Most of this other behavior stems 
from that old problem of trying to manage memory. Absent that, there 
doesn't seem to be a compelling rationale for having anything other than 
a bit copy."

Basically "it bugs me, and there's no compelling use case".
I think RAII is a compelling use case.  Expression templates are another 
thing that has been talked about.

At the very least I think D needs to have some sort of reasonable 
solution for smart pointers.  Fleshing out structs seems one reasonable 
way to go about it.

What would this require structs add?
At a minimum I think you need:

   opAssign  - so A=B can be dealt with
   ~this - destructors -  so going out of scope can be dealt with

Also this would be nice:
   opDotAccess - so A.member can be used instead of A.ptr.member.  Not 
strictly necessary I suppose, but myFile.ptr.open() as a standard File 
class API looks bad.  Another option would be an easy way to import all 
the methods from a particular class.  Like:
       alias Class.* *;

More about smart pointers here:
http://www.boost.org/libs/smart_ptr/smart_ptr.htm

--bb



More information about the Digitalmars-d mailing list