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