Re: [boost] Pointer or reference in function arguments?

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-10-01 13:02:32

From: "Maxim Shemanarev" <mcseem_at_[hidden]>

On the chance that the moderators to recognize that this has
bearing on Boost code, after all, I'm replying to your question.

> It's not explicitely indicated in the BOOST guidelines what I should
> prefer - pointer or reference when I have to use semantically "out" or
> "in-out" arguments. I know it's better to use "functional" style when we

I use suffixes on formal parameters to indicate direction, though
I can't imagine Boost would choose to enforce that approach.
That helps when reading function signatures and when
implementing/maintaining a function.  It doesn't help when
reading calling code, for course.

> have only one return value, but that's not always desirable for the sake of
> performance and/or resource usage. I'm in doubts about it. One of the
> fundamental rules says that the semantics of a call should be clear itself,
> i.e, if written
> 
> some_very_complex_class v;
> foo(v);
> 
> I should expect that the status of "v" won't change after the call. If it
> can be changed, use
> 
> foo(&v);
> 
> which explicitely tells you about it. In other words, "all reference
> arguments must be const, otherways use pointers". It's a good rule from the

Since I don't subscribe to that approach, I don't expect that "v"
is unchanged in the former call and can be in the latter, though
I understand the perspective.  The function name can often
provide information about the treatment of the argument.

> point of view that when you read someone's code it's more self-documented
> because in this case you don't have to look at the function
> definition/docs/implementation.
> 
> But there's another rule: "Use pointers when and only when it potentially
> can be 0, otherways use references". This rule also looks logical, although

I like to use pointers to indicate optional behavior and
lifetime.  That is, the caller is expected to keep the pointed-to
object alive during the function call or while the object lives
(since ctors should also be part of this discussion).  Then, I
use references for everything else, so I use non-const references
for output parameters.  But, as you pointed out, if you generally
avoid output parameters, this is rarely an issue.  (I also always
put output parameters first in the argument list to allow for
defaulting other arguments.)

Whether there can be any consensus on this matter such that Boost
could specify the approach to take, I don't know.  Boost is
generally reluctant to codify much in the way of style, but
providing some regularity to calling conventions seems a
reasonable place to do it.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;