[sv-bc] $typename issues

This feature request came in through the sv-bc, so I don't think
$typename was ever intended to be used on classes; they have a dynamic
cast function that be used to achieve some of the same functionally to
compare types. This is an inherent problem with multiple committees.

 

In any case, I have some comments below based on my recollection of
discussions of this feature. 

 

A general comment is that we can no longer assume character for
character file comparisons between two implementations because of random
stimulus and dynamic threading issues. There has to be some more
intelligence on the part of the reader to understand semantic
equivalence.

 

> -----Original Message-----

> From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-

> stds.org] On Behalf Of Vreugdenhil, Gordon

> Sent: Thursday, June 22, 2006 7:23 AM

> Subject: Re: [sv-bc] parameterized structures

> 

> There are other problems with $typename.

> 

> Here are a few issues that are easy to identify:

>    1) "22.2 c)" says that anonymous types receive a system generated
name.

>       The format of that name is not specified.

[DR>] There are two camps here. One is that since you did not name the
type, you should not make any decisions based on the generated name of
the type. The other camp says that other tools need to be able to
correlate types the source text.

 

 

>    2) "22.2 e)" does not define the exact form of printed values for

> enums.

[DR>] See my general comment. But an unsized, unsigned decimal number
would be my choice

 

>    3) "22.2 f)" says that types are prefixed with their scope name.
Is

> that the

>       full hierarchical path or the lexical path (ie. like %m)

[DR>] I would think you would want to use the path that makes the type
unique, then that is the full hierarchical path of the type.

 

>    4) "22.2 g)" says that array ranges are represented as unsized
decimal

>       numbers.  What happens with associative or dynamic arrays?

[DR>] I would assume a dynamic array is just "[]" and an associative
array is "[$typename(index)]". What are the other choices?

 

>    5) Are non-equivalent named types from different compilation units

>       (ie different $unit scopes) distinguishable from each other?

[DR>] It sounds like $unit needs to be replaced with a system generated
package name. Then they would be distinguishable.

 

>    6) Are type parameters named by the type parameter?  Are they

> structurally

>       expanded?  If I have:

>          typedef struct { int a; } T1;

>          typedef T1 T2;

>       Does $typename(T2) yield "T1" or the struct form of T1?

[DR>] The struct form of T1. This is what 22.2 a) says

 

>    7) The sentence "Thus $typename can be used in string comparisons
for

>       stricter type comparison of arrays than with type references."

> implies

>       that no non-equivalent types ever have the same string.  This

>       interacts with (5) above.  It also implies that exact form is

>       important -- including spaces, etc.  This needs a precise

> specification.

[DR>] I agree that within an implementation, the form needs to be
consistent, and this should be specified in the LRM

 

>    8) The form for structs and enums is not explicitly defined.

[DR>] Duplicate of issue 7)

 

>    9) Class types are not addressed.  Are they printed just by name or

>       as in an expanded "struct" like form?

[DR>] I think just by name would be sufficient. In fact, the same should
be sufficient for unpacked structs and enums. There's no need to include
their contents. That would make a lot of this much simpler.

 

>   10) Self-referential class types are not addressed.  If classes are

> printed

>       in expanded form, self-referential types have an infinite print

> form.

[DR>] A good reason for not expanding them

 

>   11) In terms of specializations, do you get the name of the location
of

> the

>       specialization or a name that is unique to the specialized type?

>       example:

>           C #(1) c_1;

>           C #(1) c_2;

>       Is it true/not true that $typename(c_1) == $typename(c_2) ?

>   12) Are matching types supposed to have the same string?  I.e. if
two

> types

>       match, is one guaranteed that the $typename form is identical?

[DR>] The LRM says yes, with the exception of the builtin fixed sized
types.

 

> 

> 

> I've attached the above to 1511.

> 

> At this point $typename appears to be very underspecified in

> the LRM and is not implementable in a manner that would be

> consistent across vendors without significant clarification.

> 

> Gord.

> 

> --

> --------------------------------------------------------------------

> Gordon Vreugdenhil                                503-685-0808

> Model Technology (Mentor Graphics)                gordonv@model.com