Re: [boost] [smart_ptr] shared_ptr template type

Subject: Re: [boost] [smart_ptr] shared_ptr template type
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-07-15 08:34:01

Zachary Turner wrote:
> On Tue, Jul 14, 2009 at 4:42 PM, John
> Bytheway<jbytheway+boost_at_[hidden]> 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_at_[hidden]
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.