This is now Mantis item 2245. Neil Arturo Salz wrote: > I see your point and I tend to agree with you. > > > > Actual arguments are not part of a method. As the pseudo-code in my > previous message shows, arguments are evaluated in the caller – before > making the method call. Hence, using “this” either explicitly or > implicitly (i.e., your f1 is essentially x=this.a) should not be > allowed. The intent of the LRM statement was to use the **static** scope > for resolution of constants. I’d be willing to add this to the LRM if > other agree. > > > > Arturo > > > > ------------------------------------------------------------------------ > > *From:* danielm [mailto:danielm@aldec.com.pl] > *Sent:* Monday, January 21, 2008 1:07 AM > *To:* 'Arturo Salz'; sv-ec@eda.org > *Subject:* RE: [sv-ec] dynamic vars should be forbidden as defaults > > > > OK - I understand yours example - it is fine for me - thanks for > explanation. > > > > > > But what about my code - is it legal or not - the LRM doesn't forbid > below (case f1,f2). > > > > class C; > > int a; > > static int b; > > function f1(int x=a); > > endfunction > > function f2(int y=this); > > endfunction > > function f3(int z = b); > > endfunction > > endclass > > > > IMHO only the 3rd (f3)should be allowed - because defaults are assigned > before the function call - so only statics are known at that moment. > > > > > > > > DANiel > > > > ------------------------------------------------------------------------ > > *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com] > *Sent:* Saturday, January 19, 2008 12:20 AM > *To:* danielm; sv-ec@eda.org > *Subject:* RE: [sv-ec] dynamic vars should be forbidden as defaults > > Daniel, > > > > The segment you highlighted refers only to name binding – not to lifetime. > > > > So considering the following code: > > > > int a; > > class C; > > function void f1(int x=a); > > // ... > > endfunction > > endclass > > > > initial begin > > bit a; > > C c1 = new; > > c1.f1(); > > end > > > > The method call could be “conceptually” implemented as: > > > > initial begin > > bit a; > > C c1 = new; > > int temp = $unit::a; > > c1.f1( temp ); > > end > > > > Note that the argument binds to the variable in $unit– the “a” in the > declaration – and not the “a” in the scope of the call. > > That is what that statement indicates. > > > > Arturo > > > > ------------------------------------------------------------------------ > > *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of > *danielm > *Sent:* Friday, January 18, 2008 7:19 AM > *To:* sv-ec@eda.org > *Subject:* [sv-ec] dynamic vars should be forbidden as defaults > > > > LRM says that: > > 1800-2005: 12.4.3 Default argument values: > > "The default_value is an expression. The expression is **evaluated in > the scope containing the subroutine** > > **declaration** each time a call using the default is made." > > > > The problem arises when we use that rule for dynamic|automatic variables > - ie for class propeties: > > class C; > > int a; > > static int b; > > function f1(int x=a); > > endfunction > > function f2(int y=this); > > endfunction > > function f3(int z = b); > > endfunction > > endclass > > > > IMHO only the 3rd (f3)should be allowed - because defaults are assigned > before the function call - so only statics are known at that moment. > > > > > > Similar case may be also spotted in example with no classes: > > module top; > task **automatic** t(int a = 1, int b = a); > $display(a,,b); > endtask > > initial t; > endmodule > > > > > > In above case a is an automatic variable and doesn;'t exists at the > moment when defaults should be assigned. > > > > DANiel > > > -- > This message has been scanned for viruses and > dangerous content by <http://www.mailscanner.info/>*MailScanner* > <http://www.mailscanner.info/>*, and is > believed to be clean. * > > * > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. * -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 23 14:09:09 2008
This archive was generated by hypermail 2.1.8 : Wed Jan 23 2008 - 14:09:31 PST