From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-01 08:35:59
Kevlin Henney wrote:
> >Something is still unclear. If the number of individual values a type can
> >hold is the only criteria for "widening", then is T* -> shared_ptr<T*>
> >conversion widening? After all, shared_ptr<T*> can hold all pointer values
> >out there, plus it holds reference count, so the total number of values is
> The number of legal values is, in principle and in practice, smaller:
> T o;
> boost::shared_ptr<T> p(&o);
> boost::shared_ptr<T> q(new T); // OK
You previous definition did not say anything about "legal values", and as far
as bits are concerned, two pointers above are absolutely the same. It's the
wider context -- such as memory allocator -- which distinguish between the
validity of the values. And since that context is beyond type system, I'm
still don't think you've given complete definition of "widening".
> However, there is more to conversions than just narrower vs wider (see
> >If that's widening conversion, then constructor of shared_ptr<T*> need not
> >be explicit, but that would be really unsafe. You say windening conversion
> >often loose information, and in this fact you can easily loose information
> >that pointer is allocated on stack, or that it's "this" pointer.
> Information loss is not the deciding criterion for whether a conversion
> is narrowing or widening :-)
I mean to say that, according to your definition, this is narrowing
conversion, but yet it looses important information outside type system, and
that can lead to bad results.
> Another distinction that needs to be made is that not all conversions
> fit into the widening/narrowing model. Some conversions are better
> considered as reinterpreting or translating conversions (eg lexical_cast
> and reinterpret_cast). These are useful where some notion of subtyping
> is not applicable, eg between int and string, as opposed to where one
> is, eg between numeric types.
Good, is T* -> shard_ptr<T*> conversion widening, or not? Or it does not fit
into the model?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk