RE: [sv-bc] E-mail Vote: Closes 12am PST Nov 17

> >
> > 273 ___Yes ___No ABSTAIN with comment
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=0000273
>
> I had trouble reading the html of Doug's proposal, so my
> criticism may be misplaced. In the case of C unions, I
> believe that "safe" accesses via cooperating members was
> added to support implementation of C++ class inheritance.
> I don't see this as a long term (or even short term) need
> of SV, considering that we have an SV class system as
> part of the current language design. There are also several
> other approaches - albeit more intrusive - to implementing
> derived class hierarchies using unpacked structs and unions.
> The advantage of intruding into the cooperating struct
> layouts is that the owners of the layouts are forced to
> acknowledge explicit cooperation, and therefore breakdowns
> (which are essentially impossible to detect) will be less
> likely to happen in practice.
>
> On the contrary, I see unpacked unions as the proper syntactic
> home for the feature currently documented as "tagged" unions.
> When a class-like hierarchy is built explicitly using tagged
> unions, one gets full runtime type-checking. Short of being
> able to synthesize virtual function calls, I know of no other
> way to safely access a base class.
>
> So my objection is not so much to Doug's revision of
> current unpacked unions. Rather I object to the current
> definition of unpacked unions as too unreliable for
> everyday use. I want to resist the urge to patch a bad
> situation.
>
> However, being new to this community, I don't intend to
> get obstructionist about it. Rather than vote NO, I will
> abstain.
>

Greg,

Interesting comments here!

The main point of this proposal is to give unpacked unions a
semantics as close as possible to C. I expect that the bulk of
the use of these constructs will be done to model high level
system aspects, bordering on pure software construction.
If we stay consistent with C on the characteristics of
unpacked unions, writing such SystemVerilog software will
be a more natural and intuitive process. Reading between
the lines of your comments, it seems like you would agree
with this particular goal. (Though you have reservations
about the use of unpacked unions in general, since in most
cases there are better programming alternatives).

Regards,
Doug
Received on Tue Nov 16 19:56:36 2004