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

Gord,

I presume you are suggesting that we treat this as a C: (void *) a ==
(void *) b , where a and b are pointer types (class handles).

But, if we did go that way, the result of the comparison will always be
false - with one exception: when both handles are null in which case the
result is still the same (ie null). 
The I would suggest we simply rewrite 
	a = cond ? b : c;
as
	a = null;

So what's the advantage of removing the restriction?

	Arturo

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



Francoise Martinolle wrote:

>  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.

I understand that.  I am suggesting that the LRM should be modified
to only require assignment compatibility in the case of classes.

Gord



> 
> 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

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com