RE: [sv-bc] Question on compilation units & compiler directives

In order to prevent wrong conclusions by the reader, this should be
noted in the LRM.

Shalom

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Gordon Vreugdenhil
> Sent: Wednesday, January 25, 2006 6:53 AM
> To: Symons, Tom H
> Cc: Karen Pieper; Warmke, Doug; Brad Pierce; sv-bc@eda.org;
> LaFlamme, Jamie; Mehdi Mohtashemi
> Subject: Re: [sv-bc] FW: [sv-ec] Question on compilation units
> & compiler directives
> 
> Tom,
> 
> Just to bring in a small warning here about language
> expectations.
> 
> SystemVerilog is *very* different than C++ in terms of what
> constitutes class assignment legality.  C++ ensures that two
> files with the same class hierarchy included via #include
> represent
> the same types.  Not true in SV.
> 
> If you have:
>     my_include.svh:
>        `ifndef _MY_INCLUDE
>        `define _MY_INCLUDE
>             class C;
>             endclass;
>        `endif
> 
> and then include "my_include.svh" into two different
> compilation
> units (say "unit1" and "unit2"), you end up with two different
> and
> completely incompatible versions of class C.  Objects of type C
> within
> unit1 are not assignment compatible with objects of type C in
> unit2.
> 
> This behavior in SystemVerilog makes it more than just a
> methodology decision to have class types in packages.  If you
> want a class to be usable across different compilation units,
> it MUST be in a package and be imported or else the resulting
> types will not be the same types.  This severely limits ones
> ability to use `include for class type inclusion unless you
> want just similar behavior in multiple regions of the design.
> 
> Most people on the committees are aware of this kind of issue,
> but since I hadn't heard it raised yet, I just wanted to
> reinforce that the C++ view of "compilation unit" and type
> inclusion does not map into SystemVerilog's `include in a
> way that you might expect.
> 
> Gord.