Boost logo

Boost :

From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2004-11-22 06:53:28


Joel wrote:
> Joel de Guzman wrote:
>
> Re: defaults handling:
>
>> Here's another possibility: declare the defaults in the
>> foo_keywords class:
>>
>> struct foo_keywords
>> : boost::keywords<
>> name_t
>> , value_t
>> >
>> {
>> static string default_(name_t) { return "duh"; }
>> static int default_(value_t) { return 123; }
>> };
>>
>> With this approach, all default extraction is lazy.
>>
>> Admitedly, it's more verbose. However, like in straight c++,
>> the defaults are part of the interface, not the implementation.
>> IMO, foo_impl's body is not a good place to place the defaults.
>> I imagine that in many (all?) cases, you'd want the implementation
>> to be hidden. Yet, doing so will also hide the defaults.
>> With this approach, the defaults can be placed in header files
>> as part of the interface.
>
>
> Hi,
>
> Hmmm. I wonder why I got no response. Am I not making sense?
> I think this solution is doable. You still get a compiler error
> when a default is not available when unsupplied by the caller
> and IMO, it is superior because the default handling does not
> clutter the function implementation.

I agree that it would be nice. But there are several problem with this.
First, I think you'd need to explicitly declare the return type of those
functions somehow, because the result actually has to pass through
operator[].

Also, it's a bit limiting since you don't have access to the argument
tuple. For instance:

   void f(int width, int height = width);

Or worse:

   template<class T>
   void f(T first, T second = first);

For the second one, foo_keywords would definately need a metafunction
that can determine the type of the default given the argument tuple.
Doing this with the current library is very simple:

   template<class P>
   void f_impl(P const& args)
   {
       f(args[first], args[second | args[first]]);
   }

-- 
Daniel Wallin

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk