Zachary Turner wrote:
On Tue, Jul 14, 2009 at 4:42 PM, John Bytheway<jbytheway+boost@gmail.com> wrote:
Zachary Turner wrote:
It's interesting you should say that, because I have had exactly the reverse experience. I find free function overloads much superior to traits classes for simple things like this. For example, I think boost::hash is better than std::hash because it uses a free function and ADL to find the hashes of my classes. The main advantage is the possibility of using enable_if which allows one function overload to apply to many classes. Can you be more explicit about the problems you have had?
The most recent experience I had is in regards to providing custom validators for types in boost::program_options. I actually made a thread about this a day or two ago on this list, which you can probably find in the most recent 20 or 30 threads. But the gist of it is that I wanted to allow the user to specify an integer on the command line, and I wanted to enforce that the integer was within a certain range. Since boost::program_options has built-in support for validation I figured I'd use it. But, validation is enabled by a free-function overload on the type of the parameter. so you can provide validation for ints, validations for Foo's, etc, but you can't provide validation algorithm A for this specific command line option, and validation algorithm B for that specific command line option. It's not hard to just wait until the entire thing has been parsed and then check that each one it's in a certain range, but still, builtin support for validation has been implemented, so it would be nice if it was generic enough to handle a wide variety of validation scenarios.
I don't think there is a single best way to handle customization. It depends upon whether a class template or a function template is being customized, at the least. Neither traits classes nor customization functions are as flexible as policy classes for class templates. A class template can be parameterized with a policy, likely defaulted to something reasonable, which defines the desired behavior once for all uses of that type. Being a policy class, however, the default can be overridden. The same is not true for traits. For function templates, however, a policy class isn't as convenient as the other options because it must be provided for each invocation, even when the default is wanted. A function template could accept a defaulted functor argument, of course, though deviating from the default requires passing the functor for each invocation. I suspect the desired parameter validation scheme requires providing a functor when defining a particular parameter. That's not onerous since each parameter is registered just once. The same approach would be a problem with a hash function, however. That scenario probably is better served by a hashing function object that relies on a policy class to control the behavior of its function call operator (a set-it-and-forget-it approach).
Regarding enable_if, I didn't actually think of that. But is there a reason that if the generic class in question uses a default traits class as I suggested, that a user cannot simply provide a template specialization of that same class that uses the class template version of enable_if to achieve a similar effect?
I was wondering the same. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.