Subject: RE: [sv-ec] Err-5
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Nov 21 2003 - 08:53:15 PST
Looking at the most recent copy of the built-in package proposal and the
comments by Doug and Ray, I believe this should be redone as as "The
Standard Package" and called std. This will allow us in the future to
add other "built-in" packages without having one that is special and
uses the :: name. In general we should just remove all reference to
built-in and define these classes, types etc in the std package.
What I'ld really like to see is the actual package declaration in this
section (or a normative appendix). This would include all the built-in
types and classes including full prototypes for all the methods. For
cases where the effect can not be directly expressed in SV then
italicized text should be used.
In a subsequent email, I will be voting against the current errata;
however, I will vote for it when we have a name for it. The full-text
would be nice but is not required to get my vote.
jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: David W. Smith [mailto:David.Smith@synopsys.com]
> Sent: Thursday, November 20, 2003 7:12 PM
> To: 'Arturo Salz'; 'Warmke, Doug'; 'Ryan, Ray'; 'sv-ec@server.eda.org'
> Subject: RE: [sv-ec] Err-5
>
>
> Greetings,
> So, the process to resolve this is that when it is discussed
> at the meeting
> (Monday) a motion can be made to modify the proposal to name
> the package
> (pick a name, I personally like fred but std is probably more
> meaningful).
>
> One other comment. The correct term for the scope at the top of the
> compilation unit is the compilation-unit scope as defined in
> Section 18. We
> should try to use this and "compilation unit" (instead of unit of
> compilation) consistently since they are presented as
> specific defined terms
> in Section 18.2.
>
> Regards
> David
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
> Behalf Of Arturo
> Salz
> Sent: Tuesday, November 18, 2003 9:23 PM
> To: Warmke, Doug; 'Arturo Salz'; Ryan, Ray; 'sv-ec@server.eda.org'
> Subject: Re: [sv-ec] Err-5
>
> Doug,
>
> You are correct about C++ being in a state of transition and
> std:: being the
> new namespace where standard utilities reside.
> As I wrote in my earlier message, a named package is a plausible
> alternative.
> I have nothing against such an approach. The current proposal takes a
> slightly
> different approach, one that has been in use for some time.
>
> Arturo
>
> ----- Original Message -----
> From: "Warmke, Doug" <doug_warmke@mentorg.com>
> To: "'Arturo Salz'" <Arturo.Salz@synopsys.COM>; "Ryan, Ray"
> <Ray_Ryan@mentor.com>;
> "'sv-ec@server.eda.org'" <sv-ec@eda.org>
> Sent: Tuesday, November 18, 2003 8:25 PM
> Subject: RE: [sv-ec] Err-5
>
>
>
> Ray wrote:
> I'd prefer the built-in package to have a name (rather than
> 'he who shall
> not
> be named'). This is just a preference - there is nothing
> technically wrong
> with the null name.
>
> Arturo wrote back:
> That is a plausible way to define it. However, that would be
> incompatible with
> other mainstream languages such as C++ and Java. Plus,
> the committee did
> approve this form.
>
> Doug writes:
>
> Arturo, this isn't strictly true with C++.
> Right now the language is in transition.
> It is possible to use types defined in the "std" library
> (aka STL) without qualification, but that is deprecated.
>
> Consider the STL class "vector". In the future,
> it will be necessary to qualify all references to a type
> such as vector. One can either refer to the type with a
> fully qualified name, such as "std::vector", or one can
> employ "using" syntax to import the visibility of
> "vector" from the "std" (dare I say it? package!)
> into the current scope.
>
> As I mentioned in the SV-BC meeting (and I did hear the groans!),
> I don't see what is wrong with naming the built-in namespace "std".
> It has precedent in both C++ and VHDL. That could connote a lot
> to SystemVerilog users.
>
> I will be interested to hear details of why you think this proposal is
> incompatible with C++. (I don't know much about Java, unfortunately).
>
> Regards,
> Doug
>
>
>
This archive was generated by hypermail 2b28 : Fri Nov 21 2003 - 08:54:09 PST