RE: [sv-ec] Re: [sv-bc] operators and data type compatibility rules

From: Francoise Martinolle <fm_at_.....>
Date: Fri Sep 15 2006 - 12:31:55 PDT
 Gordon,

The behaviour you describe for the conditional operator is not correct
with respect to classes.
It currently says:

For all other cases, the type of first expression and second expression
must be equivalent.

You are saying that the type of the first expression and second
expression must be assignment
compatible with the destination.

for unpacked structs and arrays, assignmnt compatibility and equivalence
are the same. That is not 
true for class datatypes.

Francoise
    '

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Friday, September 15, 2006 12:40 PM
To: Arturo Salz
Cc: Francoise Martinolle; sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-ec] Re: [sv-bc] operators and data type compatibility
rules



Arturo Salz wrote:

> Gord,
> I believe the LRM does say that:
>
> If the elements match, the element is returned. If they do not match, 
> then the default
> 
> un-initialized value for that element's type shall be returned.


Right - the question was what "element" means for class handles.  I
think that was at the core of Francoise's question.

> The thing to notice is that when two handles are used in the 
> conditional operator then the operator does a *handle comparison* not 
> a deep compare of the object's properties - this BTW is no different 
> from if( handle1 == handle2 ). Thus, if the handles are the same then 
> the operator returns that handle, and if they are not the same, the 
> operator returns null. Perhaps all that's missing is a note that 
> details how class handles are handled.


I agree.

We're in agreement on the behavior; I do think the LRM needs to word
this more carefully for handles.

Gord.
--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
Received on Fri Sep 15 12:32:09 2006

This archive was generated by hypermail 2.1.8 : Fri Sep 15 2006 - 12:32:16 PDT