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