Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-13 17:25:16

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
>>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>>> True, but sometimes it is appropriate. Even then, you only need two
>>>> parameters whose order is not obviously dictated by function to
>>>> justify the use of a named parameter interface:
>>>> paint(hue = 1071, luminance = 10)
>>>> vs.
>>>> paint(1071, 10)
>>> again, you could just say
>>> painter p;
>>> p.set_hue( 1071 );
>>> p.set_luminance( 10 );
>>> p.paint();
>> Yes, but it's ugly, stateful, and comparitively easy to misuse. And
>> it's not even the moral equivalent of having named parameters, as far
>> as I can tell. You're worried about "making it possible" to write
>> functions with >5 parameters, but a class with >5 setter functions
>> that isn't really meant to act like an ordinary class but instead as a
>> poor man's substitute for a function with named parameters is surely
>> worse than just having the feature!
> void paint( color const & c );
> has the advantage that you can return a 'color' from a function or
> store it.

Yes, of course. I like the idea of a color abstraction. But often
the parameters don't form a neat little package like "color."

> Of course we have now restated the problem in terms of constructor
> parameters. Does the library support named constructor parameters,
> by the way?

Of course; an example of that usage is exactly what Thorsten was
complaining about in the first place.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at