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,487 of 33,346    |
|    Andy Champ to Ivan Godard    |
|    Re: local function as default value    |
|    20 Jul 12 13:43:12    |
   
   From: no.way@nospam.invalid   
      
   On 20/07/2012 19:44, Ivan Godard wrote:   
   > 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?   
      
   At the time defVal() gets called you don't have an S to connect it to   
   - what would be the value of "this" within the defVal function?   
      
   (In the second case defVal gets called from within the second p(...)   
   function and uses its "this")   
      
   You could also get around it by making defVal static, so it doesn't   
   have a "this".   
      
   Andy   
      
      
   --   
    [ 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