Subject: [sv-ec] RE: FW: Neil's comments
From: David W. Smith (david.smith@synopsys.com)
Date: Fri Apr 11 2003 - 23:16:01 PDT
He Neil,
See comments below.
Regards
David
-----Original Message-----
From: Neil Korpusik [mailto:Neil.Korpusik@eng.sun.com]
Sent: Friday, April 11, 2003 11:06 AM
To: david.smith@Synopsys.COM
Cc: sv-ec@eda.org
Subject: Re: FW: Neil's comments
1. Wrap-around situations in Annex C, Linked Lists
It appears that the C++ STL package doesn't allow for this wrap-around
situation. The following quote comes from page 153, "The C++ Standard
Library, A Tutorial and Reference", Josuttis, 1999, Addison Wesley.
"Iterators must refer to valid positions, the beginning of a
range must have a position that is not behind the end, and you must not
try to remove an element from an empty container."
I'm not sure if you intentionally deviated from the C++ STL or not, but
what we now have in System Verilog is a new semantic. Deviating like
this is probably not a good idea since the System Verilog List package
is modeled after the C++ STL package.
Even if the response to this will be that it is "too late" to change it
now, I want to go on record saying that it is a bad idea.
DWS: You guessed correctly.
2. Annex C, next() and prev()
I just reviewed some documentation on the C++ STL list iterators. It
appears
that the intent is for the System Verilog iterators to behave in a
similar
fashion. The mechanism used to determine when you have reached the end or
the beginning of a list is to compare the iterator with the iterators
that are returned by start() and finish().
Given that this is how a user is intended to use the System Verilog
List package I can accept the fact that calling next() while at the end
of the list is not defined. I would however like to have the description
of
next() and prev() updated to reflect this fact. Simply not stating the
behavior in this situation could easily lead to a lot of coding errors.
3. C.4.2, last sentence, typo
"... element in the list:"
"... element in the list." <--- corrected
DWS: Fixed in LRM-250
4. Annex C, method calls in the examples
It appears that the intent was to have all method calls within these
examples in bold text. There are a few exceptions to this style.
C.4.3, last sentence, i1.eq
C.5.6, last sentence, numbers.front
C.5.10, for loop, 1st.finish
C.5.10, for loop, p.neq
C.5.11, for loop, p.neq
DWS: Fixed in LRM-251
Neil
> From: "David W. Smith" <david.smith@synopsys.com>
> To: "'Neil Korpusik'" <Neil.Korpusik@eng.sun.com>
> Cc: <sv-ec@eda.org>
> Subject: FW: Neil's comments
> Date: Thu, 10 Apr 2003 21:42:03 -0700
> MIME-Version: 1.0
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>
> Neil,
>
> Here are Arturo's response to Items 40 and 41 of Neil's review.
>
> No change coming from them.
>
> Regards
> David
>
> -----Original Message-----
> From: Arturo Salz [mailto:salz@Synopsys.COM]
> Sent: Thursday, April 10, 2003 6:53 PM
> To: David W. Smith
> Subject: Re: Neil's comments
>
>
> No. The first item doesn't need an example.
>
> The second item next() doesn't specify what happens when doing next on
> the last item. This could be implemented with wrap-around or it could
> return the same (end-of-list), but basically it's not defined.
>
> Arturo
>
> ----- Original Message -----
> From: David W. <mailto:david.smith@synopsys.COM> Smith
> To: 'Arturo Salz' <mailto:Arturo.Salz@synopsys.COM>
> Sent: Thursday, April 10, 2003 3:07 PM
> Subject: Neil's comments
>
>
> Can you decide if you want to do anything about these?
>
> 40. Annex C
>
> Some of these methods discuss a wrap-around condition. It would be
> nice to have an example that shows this in detail (e.g. C.5.14).
>
> 41. Annex C, page 326, C.4.1
>
> I assume that the next() method stops at the end of the list and won't
> wrap-around. The text doesn't state the behavior in this case.
>
> Thanks
>
> Regards
> David
This archive was generated by hypermail 2b28 : Fri Apr 11 2003 - 23:14:29 PDT