home bbs files messages ]

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,139 of 33,346   
   Jonathan Thornburg to James K. Lowden   
   Re: in/out arguments   
   14 Apr 12 23:14:04   
   
   From: clcppm-poster@this.is.invalid   
      
   James K. Lowden  wrote:   
   > Please note, my basic point was that i/o parameters are rare enough, on   
   > the evidence, that they don't merit distinction in the language   
   > syntax.  I would guess parameters are declared 90% by value, 9% output,   
   > and 1% i/o.  That's what I meant by "rarely used".   
   >   
   > By "rarely justified", I meant they are to be avoided where possible.   
   > Here's a bad example:   
   >   
   >        void sqrt( double& value );   
   >   
   > I've worked with people who believed passionately that's more   
   > efficient.  You don't allocate two or three doubles on the stack; you   
   > just use the one you've got!   
      
   I completely agree -- *this* example exhibits what is almost always   
   a poor software design [and its efficiency is unlikely to differ   
   significantly from   double sqrt(double x); ].   
      
   However, if we instead had   
         void sqrt_of_big_vector(std::vector& v);   
   where the vector v is very large (so that copying it would be very   
   slow and/or might be impossible due to the machine not having enough   
   memory for a copy), then this might well be a good software design,   
   and an API which mandated separate input & output vectors would be   
   a poor design.   
      
   I suspect we may be in "violent agreement" about this case as well,   
   and merely disagree about how frequent such cases are.  The point I   
   was trying to make in my previous post is that in some application   
   areas, in-place modifications to things-we-don't-want-to-copy are   
   quite common.  And a function to do such an in-place modification   
   needs the data to be an in/out argument (accessed either through   
   explicit parameters, and/or the implicit  this  argument of a class   
   member function, and/or global variables (ick)).   
      
      
      
   Following up on Christopher Creutzig's comment   
   | I regard the following calls to have in/out parameters and to not be   
   | exotic corner cases of STL:   
   [[...]]   
   |   
   | std::set s;   
   | s.insert(1);   
   some operations (like std::set::insert(), or sorting, or the FFT   
   (fast Fourier transform)) are also usefully *conceptualized* as having   
   in/out parameters, quite apart from any questions of efficiency.   
      
   --   
   -- "Jonathan Thornburg [remove -animal to reply]"   
      
       Dept of Astronomy, Indiana University, Bloomington, Indiana, USA   
       "C++ is to programming as sex is to reproduction. Better ways might   
        technically exist but they're not nearly as much fun." -- Nikolai   
   Irgens   
      
      
         [ 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