• Bill Baxter (28/28) Nov 16 2006 The rational for no opAssign in classes clear enough -- when you say
• Stewart Gordon (15/22) Nov 19 2006
• Reiner Pope (10/24) Nov 20 2006 Reference counting is the only safe way to remove the restrictions on au...

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

Stewart Gordon <smjg_1998 yahoo.com> writes:

Bill Baxter wrote:
<snip>
 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.

<snip>

To bypass the restriction that scope object references cannot be 
changed?  If we're going to add something to the language for this, why 
not just remove the restriction?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.

Reiner Pope <reiner.pope gmail.REMOVE.com> writes:

== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
 Bill Baxter wrote:
 <snip>
 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.

 <snip>
 To bypass the restriction that scope object references cannot be
 changed?  If we're going to add something to the language for this, why
 not just remove the restriction?
 Stewart.

Reference counting is the only safe way to remove the restrictions on auto types
(because, if you have a way to specify stack variables, then you get many more
dangling pointer problems, which GC was introduced to avoid in the first place).
Unless RC will be implemented in the language, then allowing opAssign and smart
pointers is a good way to help people manage resources.

Bill mentioned another use of opAssign: expression templates. These have nothing
to do with scoped variables.

Cheers,

Reiner