Thread overview | |||||
---|---|---|---|---|---|
|
November 17, 2006 structs and opAssign -- why not? | ||||
---|---|---|---|---|
| ||||
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 |
November 20, 2006 Re: structs and opAssign -- why not? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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. |
November 20, 2006 Re: structs and opAssign -- why not? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | == 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
|
Copyright © 1999-2021 by the D Language Foundation