Re: [Boost-users] 'standard' free functions for operators, etc

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2006-06-22 22:30:07

>
> In other words, if you have an operation F, and two type aliases X and Y
> that both resolve to 'int' and you want F to have different semantics when
> applied to X and Y, you are effectively not using the C++ type system. You
> have imposed your own "logical type system" that is based on names (X and
> Y)
> and not types.

I understand, and to "effectively not using the C++ type system" I would add
a subtle twist:
"not effectively using the C++ type system" either :-).

Yet there is lots of code out there that does this.  So, with regards to
intrusive_ptr, I guess the answer is that that kind of code is not worth
considering when designing intrusive_ptr.  Is it worth considering for
the_next_boost_thing<T> ?  Maybe it depends on the thing, but much of boost
is generic, so I think it does make sense to talk about
the_next_boost_thing, even out of context.

Note also that things like map<> allow the predicate to be specified,
instead of using a free map_less(T, T) and assuming map_less is always the
same, for a given type.
Now I understand that map is a different situation than intrusive_ptr - I'm
definitely stretching things a bit.  But I'm looking for reasons to use one
technique over the other (and also instead of, say, virtual functions /
runtime polymorphism, but I think I understand most of the differences
there).  Obviously passing in a predicate/policy is the way to go when it is
reasonable to expect different policies/predicate used *on the same type*,
and intrusive_ptr is probably a case where different policies don't make
sense.  Is that enough to make it better? ie:

- a policy based add_ref for intrusive_ptr would allow it to be used in
those rare cases where there is a 'type-overlap' or a 'lack of strong
typing'
HOWEVER,
- a policy based approach would *also* allow different add_refs for a single
type (ie 'logical' or 'strong' type), which would be senseless and
*disasterous* when the type really only has one way of doing add_ref,
THUS
intrusive_ptr chooses free functions, over a policy-based approach

ie we thought about a policy-based approach, but specifically wanted to
*enforce* one-add_ref-per-type, or
we didn't even think about it (at least not consciously), it was just the
natural and obvious thing to do

Anyhow, looking at it that way maybe teaches me something....

Tony