Re: [boost] in/out parameters,codingstylesandmaintenance[was:classproposal]

From: Chris Little (cslittle_at_[hidden])
Date: 2003-05-02 08:09:04

on 5/2/03 4:54 AM, Joel de Guzman at djowel_at_[hidden] wrote:

> Justin M. Lewis wrote:
> 
>>> Your intent is good. However, you cannot claim that we'll all be
>>> saved from the "trouble of having to hunt down all kinds of
>>> functions", unless, and that's a big unless... *ALL* functions and
>>> function calls are retrofitted with your inout solution. If this is
>>> not done wholesale,
>>> the programmer will still be uncertain as to which functions will
>>> modify his argument. I imagine him faced with a function call:
>> 
>> You're right, I can't claim that this will be used in all code, in all
>> projects, throughout the universe.  I don't think I've ever made that
>> claim, like anything else, it's up to the people writing the code to
>> adhere to coding guidelines.  The POINT here is, you CAN use this
>> library in a project to make your intent clear at the point a
>> function is called.  And, this
>> whole point of retrofitting, am I the only person planning on writing
>> new code ever?  You don't need to retrofit EVERYTHING to put a new
>> idea to use. You can choose to just start using it going forward, or
>> pick it up at the beginning of the next project.  And, while YOU may
>> personally never use it, that doesn't mean no one will.
> 
> No, my point is that you cannot claim that we'll be saved from the
> "trouble of having to hunt down all kinds of functions" with your
> solution. Please read my message again.

I have to agree with Joel.  How many projects don't use any third-party or
internal utility libraries where this idiom wouldn't be used?  People would
still have to lookup unfamiliar functions to decide what how the parameters
are used.

Chris