I believe we have discussed making things like this illegal in the past, but I cannot find any text in the LRM that makes it illegal. I don't think this is particularly useful, but there is currently nothing that makes it illegal. -----Original Message----- From: Francoise Martinolle [mailto:fm@cadence.com] How about this : typedef class c; module top; c#(3) v_pos; ===> is this legal c #(.p(3)) v_named; ===> is this legal endmodule class c #(parameter p = 0); endclass or would we require an intermediate typedef just like we do for the example below: some_class::T myLocalVar; // illegal typedef some_class::T myT; // legal Francoise ' -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Friday, November 21, 2008 10:56 AM To: Mark Hartoog Cc: Francoise Martinolle; sv-ec@eda.org Subject: Re: [sv-ec] forward typedefs Mark, you didn't address the named association -- but if you agree that the rest that is legal, I'm assuming that you wouldn't want to exclude that. It would be pretty irregular to do so. One edge case (which I think follows directly) is based on the LRM statement that a forward type is incomplete until the final definition is seen. So, for example you can't directly refer to a type within a forward class using "::" (though we did explicitly allow such references in a further typedef). I think that a type defined by a specialization of a forward parameterized class is also incomplete. Example: typedef c; typedef c#(1) some_class; some_class::T myLocalVar; // illegal typedef some_class::T myT; // legal class c #(int p = 1); typedef bit[p:0] T; endclass myLocalVar is illegal since "some_class" is incomplete until the body of "c" is defined. Gord Mark Hartoog wrote: > I agree with Gord that your original case should be legal. I also > think you can use parameter pass by value and default parameter values. > > For the case raised by Gord: > > typedef class c; > typedef c d; > c c_0; // should be legal > d c_1; // Should be legal > c #(9) c_2; // should be legal > d #(7) c_3; // should be illegal > class c #(parameter p = 0); endclass > > You can use a forward typedef to define a new type, but the type 'd' > is the class 'c' with default parameter values. You cannot override > those parameter values when you use 'd'. > > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > Francoise Martinolle > Sent: Thursday, November 20, 2008 6:48 PM > To: Gordon Vreugdenhil > Cc: sv-ec@eda.org > Subject: RE: [sv-ec] forward typedefs > > > > > If we assume it is legal to do this, can we only use positional > association for the parameter values? > > typedef class c; > > typedef c#(1,1) c_1_1; > typedef c#(.q (1), .p(2)) c_2_1; // is this legal > typedef c#(,1) c_0_1; // can you use default values > > class c #(parameter p = 0, q = 0); > endclass > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Thursday, November 20, 2008 7:39 PM > To: Francoise Martinolle > Cc: sv-ec@eda.org > Subject: Re: [sv-ec] forward typedefs > > > This was discussed at some point though I don't recall if it was > through the reflector buried in the wider discussion or just in a > meeting. It certainly wasn't specified in the LRM. > > My recollection was that Mark and I agreed that it would be legal to > have a forward specialization as in your example. > I think that there was some disagreement as to whether the implicit > default specialization using just the name should be allowed. Example: > > typedef class c; > typedef c d; > class c #(parameter p = 0); endclass > > I was somewhat opposed to considering this as legal although it is > more symmetric to allow it. My argument against is mostly one of > readability in terms of intent for a forward type "c#()" used as a > forward is more obvious as to intent. > > Gord. > > > Francoise Martinolle wrote: >> Can you create a class specialization of a class for which we only >> have a forward typedefs? >> >> Is this allowed? >> >> >> typedef class c; >> >> typedef c#(1) c_1; >> >> class c #(parameter p = 0); >> endclass >> >> In mantis 2211, we discussed the usage of :: for incomplete typedefs >> and we speicifed the >> >> following text: >> >> >> A forward typedef shall be considered incomplete prior to the final >> type definition. While incomplete forward >> >> types, type parameters, and types defined by an interface based >> typedef may resolve to class types, use >> >> of the class scope resolution operator (see 8.22) to select a type >> with such a prefix shall be restricted to a >> >> typedef declaration. It shall be an error if the prefix does not >> resolve to a class. >> >> Example: >> >> * * >> >> *typedef *C; >> >> C::T x; // illegal; C is an incomplete forward type >> >> typedef C::T c_t; // legal; reference to C::T is made by a typedef >> >> c_t y; >> >> * * >> >> *class *C; >> >> * * >> >> *typedef *int T; >> >> * * >> >> *endclass* >> >> >> -- >> This message has been scanned for viruses and dangerous content by >> *MailScanner* <http://www.mailscanner.info/>, and is believed to be >> clean. > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Nov 21 09:14:40 2008
This archive was generated by hypermail 2.1.8 : Fri Nov 21 2008 - 09:14:51 PST