[boost] Re: Re: Policy-based smart pointers revisisted (was: Re:Preliminarysubmission: command line & config file library)

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-01-19 13:08:18

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uiswlmd7q.fsf_at_boost-consulting.com...
> "Edward Diener" <eddielee_at_[hidden]> writes:
>
> > "Fredrik Blomqvist" <fredrik_blomqvist_at_[hidden]> wrote in message
> > news:b0cvd7$4dv$1_at_main.gmane.org...
> >> -snip-
> >> > I thought the C++ template solution by Damian Conway was pretty neat,
> >> -snip-
> >> I thought so too at first, but at a closer look you can see that the
code
> > in
> >> practice only works for integers.. It solves the problem in the
original
> >> thread, but shouldn't be mistaken for a generic solution.
> >
> > It seems as if it should work for any type with a copy constructor.
Perhaps
> > I missed something.
> >
> > Nonetheless I do favor a compiler change such as allowing the "default"
> > keyword to be used instead as Mr. Terekhov suggested in that same
thread.
> > That would be much cleaner and should be easy for any compiler to
handle.
> > This is one case where I would like to see the language updated with
such an
> > easy, transparent solution to the problem. Of course if others don't see
it
> > as much of a problem, they wouldn't be in favor of the solution since it
> > involves the dreaded "C++ language change"
>
> Oh, it's a problem alright, but I'm still not very convinced of that
> solution.  The problem with interfaces that have lots of positional
> parameters is that you forget what the different positions mean.  To
> solve that problem, you need either named parameters or a
> position-independent interface.

Since the C++ language already has embraced positional parameters as its
normal means of passing information to functions, classes, or templates, it
is a little disingenuous to complain about them. Every function call is
essentially a matter of knowing "what the different positions mean". Since
we are stuck with this metaphor, so to speak, we can at least make the best
of it in regard to default parameters with a simple solution.

I wouldn't mind the idea of named parameters so much other than the
adjustment away from what every C++ programmer has previously become
accustomed to using. I imagine the compilers would also get more complicated
as another area for dealing with C++ identifiers would have to be dealt
with. Simply adding "default" in order to invoke the default value for a
particular position is so much easier.

My point is: since we already deal with "positions" in nearly everything,
why not add "default" as has been suggested. If the language evolves to
named parameters or some other means of a position-independent interface for
passing normal parameters, we can consider these other ideas for passing
default values. Keeping the metaphor consistent ( KTMC as opposed to KISS
<g> ) seems to me to be the best idea for now. That's not to say that you or
others shouldn't invent better means, if you think it worthwhile, given what
the language currently offers.