RE: [sv-ec] A question about copy constructors

It's a good thing this week's not too busy... next week will be
different...

Comments below.

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, January 19, 2007 12:00 PM
> To: Arturo.Salz@synopsys.com; sharp@cadence.com; paulsen@cadence.com;
sv-
> ec@eda-stds.org; Rich, Dave
> Subject: RE: [sv-ec] A question about copy constructors
> 
> 
> >From: "Rich, Dave" <Dave_Rich@mentor.com>
> >
> >As far as "correctness" is concerned, the current LRM has no
> >restrictions on what the handle on the RHS of the constructor could
be
> >pointing to, other than in must be assignment compatible to the
handle
> >on the LHS. Null certainly fits within these rules, and the LRM
mentions
> >no need to generate an error.
> 
> Making a copy requires accessing the non-static members via the
handle.
> Accessing non-static members via a null handle is illegal.  So the LRM
> says that this is illegal.  If you wanted it to be legal, the LRM
would
> have to say that this special case is *not* illegal.
[DR>] But the null class has no non-static members, so it does not
access anything. What is the dynamic class type of a handle that points
to null, the null class, which has no members.
> 
> As an aside, the LRM does not say that accessing via a null handle
> produces an error (unless this has been changed).  The result is
> indeterminate, and implementations can issue an error.
[DR>] agreed. But Arturo was suggesting that copying a null handle would
be an error.
> 
> 
> >But I suspect people are more interested in what the *desirable*
> >behavior should be. If we take an analogy from C, malloc(0) returns a
> >null pointer and is not an exception case. I don't believe that this
> >will be a problem for debug as most people want to do a deep copy,
and
> >the shallow copy will be at the root of that deep copy, if at all.
> 
> If the user wanted the original (possibly null) object, they would use
> the original object.  They are asking for a new object, initialized to
> the value of the original object.  They expect to get an object.
[DR>] And do get an object, the null object.
> 
> The user may have wanted some fields of the new object to start out
the
> same as the original object as a default, but to overwrite some fields
> with different values.  If the new returns a null, those overwrites
will
> be illegal.
[DR>] The user will most likely need to check for nulls in either case.
> 
> You can make a definition that this special case returns null, but I
> think Arturo is right that this is probably a user error, and they
would
> like to know about it sooner rather than later.
[DR>] Then why not make null dereferences a compulsory error?
> 
> Steven Sharp
> sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.