Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-05 10:44:26

Hi Thorsten,

2008/12/5 Thorsten Ottosen <thorsten.ottosen_at_[hidden]>:

> It has been advocated in other context as well, e.g. by scott meyers. The
> author of the bimap library was, initially, against it, citing some of the
> same sources as you do. He ended up being very happy with the members IIRC.
>
> The discussion in [*] and other places is not great IMO.

Apparently there are groups of people that prefer either of the
approaches, but I wouldn't like the review to become an ideological
discussion on general style guidelines like this one.

> template <typename V, typename C, typename E, typename T>
> void change_constraint(constrained<V, C, E> & c, const T & new_constraint)
> {
>    constrained<V, C, E> tmp(c.value(), new_constraint, c.error_handler());
>    c.swap(tmp);
> }
>
> this seems *very inefficient* compared to only changing the constraint.

You can't simply change the constraint if the current value does not
conform to it.You have to check that and eventually copy the value and
the constraint, call the error policy for them and assign them back.
In most common cases this seems not much more efficient than copying
the whole object and swapping it (considering the typical case when
one or both of the policies are empty or have trivial copy).

Having said that, I agree with you at this point -- implementing
change_constraint as a member might allow for more efficient
implementation for some cases. This is an argument that might convince
me to make it a member and I will investigate this possibility. But in
general I still prefer writing non-members if there's no apparent
reason why not to do so.

> (b) The second claim is that free-standing functions break apart monolothic
> classes. That may be, but you don't have a monolothic class (you're not even
> close).

So how many functions that are unnecessarily members of a class must
the class have to call it monolithic and to un-member those functions?
:P

> And then finally my point, that the boost namespace is poluted with names
> that makes it near impossible to find the right function, and so, by making
> it a member that task is trivial.

Note that this function is in constrained_value namespace and does not
pollute boost namespace. It is not that hard to find it, your editor
may also help when you type '::' (although I agree that typing an
object's name and '.' may be slightly more convenient).

> In conclusion: making something a non-member is rarely a good idea.

In contrast: making everything a member is rarely a good idea. ;-)

Best regards,
Robert