Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 32,488 of 33,346    |
|    =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All    |
|    Re: local function as default value    |
|    20 Jul 12 13:45:36    |
   
   From: daniel.kruegler@gmail.com   
      
   Am 20.07.2012 20:44, schrieb Ivan Godard:   
   > The following seems reasonable:   
   > struct S {   
   > int defVal() { return 0; }   
   > void p(int i, int j = defVal()) {}   
   > };   
   > but gets:   
   > error: a nonstatic member reference must be relative to a   
   > specific object   
   > void p(int i, int j = defVal()) {}   
   > and similar on other compilers. This seems odd to me: if "p" is to   
   > be called there must be an "S" value to be "this" at the call site,   
   > which could be used as "this" for "defVal" too. Presumably the same   
   > would apply to a local data member used as a default as well.   
   >   
   > Yes, I know there's an easy workaround:   
   > struct S {   
   > int defVal() { return 0; }   
   > void p(int i, int j) {}   
   > void p(int i) { p(defVal()); }   
   > };   
   > but why is it necessary?   
      
   IMO the current restrictions make sense. Keep in mind that default   
   arguments are simply expressions that will be used instead of the   
   actual function call. Now consider the call expression   
      
   s.p(0)   
      
   for some object s. This has the same semantics like   
      
   s.p(0, defval())   
      
   but there is no free function defval in sight, so the compiler is   
   right to reject you code upfront.   
      
   You argument that the compiler could use the object expression that is   
   used to invoke function p should be considered cautiously. IMO it much   
   more complicates the mental model of the translation of the call by   
   the compiler. The situation would also become more complicated, if we   
   consider default arguments of a constructor   
      
   struct S {   
    int defVal() { return 0; }   
    S(int i, int j = defVal()) {}   
   };   
      
   Would you really want that the compiler translates this to executable   
   code?   
      
   I don't think that your suggested language extension would solve more   
   problems than it introduces.   
      
   HTH & Greetings from Bremen,   
      
   - Daniel Krügler   
      
      
   --   
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
    [ comp.lang.c++.moderated. First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca