Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-27 15:03:44

Oleg Abrosimov <beholder_at_[hidden]> writes:

>> You're not saying what you mean by "reuse." We think reuse is very
>> possible with the Parameter library, so it's quite unclear what you
>> might be referring to.
> libraries are all about reuse. boost::parameter is not an exception of
> course.
> By reuse I mean configuration reuse in client code.

By "configuration" I take it you mean something equivalent to

> Not reuse of
> boost::parameter library in other libs.
> Consider:
> foo(width = 2, height = 1);
> // ... some code ...
> foo(width = 2, height = 3);
> vs.
> TFooParam p;
> p.width = 2;
> p.height = 1;
> foo(p);
> // ... some code ...
> p.height = 3;
> foo(p);
> // p is reused here

That's also possible with the parameter library; p would be an

> The drawback in such a scenario is reduced visibility, because of 'p'
> can be initialized too far from the second call of 'foo'.
> But in practice most common scenario is to initialize 'p', call
> 'foo(p)', then modify 'p' slightly and call 'foo(p)' again. It means
> that visibility is preserved.

Is that common? For what interface?

>>> - ambiguity with other language constructs
>>> (it is very important drawback. As I realized from parameter docs,
>> You're not being specific enough here either. I can't imagine what
>> ambiguity you mean.
> consider:
> void new_window(char const* const, int = 10, bool = true);
> int main()
> {
> int width;
> bool titlebar;
> new_window("alert", width=10, titlebar=false);
> return 0;
> }
> call to new_window can not be translated unambiguously by reader in
> presence of named params. I expect that compiler will complain, but
> reader can be fooled by such a call, especially if we change it a bit:
> int main()
> {
> new_window("alert", width=10, titlebar=false);
> return 0;
> }
> What is a 'width' here? parameter name? or some variable in global scope?

Oh, sure, Fred Bertsch's problem. Because of that we instituted a new
naming convention (and associated macros for defining keyword
objects). Now that would read:

  new_window("alert", _width=10, _titlebar=false);

>>> great effort should be made to make such an ambiguity possible.

Why would we want to make an effort to enable ambiguities?

>>> It would be better IMO to eliminate this efforts in implementation
>>> and the ambiguity in one shot - provide special may be auxiliary
>>> structure - like syntax to use parameters)
>> It's unclear what you mean.
> I mean that significant amount of work should be done to allow named
> parameter syntax that can be ambiguous as was shown above.

Why should it?

> The idea I was trying to explain is simple - May be it is possible
> to find a way to achieve both goals - unambiguity and reduce of
> efforts required to enable named params usage.

I think a suitable naming convention is enough. Or you can use
qualification to refer to parameter names.

>> IMO the implementation complexity doesn't matter as long as it works
>> and gives comprehensible feedback when misused. Do you inspect the
>> source code of your compiler and complain about its implementation
>> complexity?
> We are living in very different worlds. and it is good for you. I'd
> be happy if I can say the same as you've said here. Not many of as
> are paid for libraries writing. My job is application
> programming. It is always done in a high time pressure.

That's why you need libraries that work reliably.

> I'm writing several functions per day. Most of them are used only by me
> to implement other functions. I _can not_ spend time to implement named
> params for each function that I wrote.
> It is completely impractical.

I agree in principle that it makes little sense to use named
parameters in all your internal interfaces.

But note, defining a parameter-enabled function hardly takes any time
anymore, since Daniel W. created the new macros described in It's almost the
same as writing down the function would be if there were a built-in
language feature.


Dave Abrahams
Boost Consulting

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