On Nov 22, 2004, at 12:16 AM, 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.
But on the other hand, with this method you don't have the ability to make the defaults depend on the other parameters passed to the function. In the BGL, we have lots of dependencies between parameters where we'll build, e.g., a property map based on the vertex index parameter (which may be defaulted) and the value type of a weight map (which may be defaulted). This approach also forces me to name the result type, which can be rather annoying. Doug