Re: [boost] Re: Traits-based design and ODR

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-30 19:56:33

> "Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
> news:009901c1efea$b3c34870$10b387d9_at_TimeMachine...
> [snip]
> > I may be using too many ambiguous terms here because I don't have a
> concrete
> > example, but I hope you see what I am getting at. I don't expect all
types
> > other than the pointee type to be eliminated for the interface, as
Dietmar
> > aims for, but by reducing them to the minimum set this could mitigate
the
> > situation.
> >
> > Is this a possibility?
>
> I'm sorry Phil, but I cannot follow. My view might be limited and
> simplistic, but to me, interfacing libraries is, when all has been said
and
> done, a matter of agreeing on compatible types. I believe that whether you
> do that by using templates, typedefs, house-baked types, or opaque
handles,
> is a secondary issue. Maybe I misunderstood you, but all you say doesn't
> really make agreement on types easier.

What I was trying to suggest, though perhaps only half-heartedly, was that
we may be able to reduce the number of types we have to make agreement on by
pushing them into runtime policies when we send them across interfaces.
For example, do the checking and storage policies need to be exposed in the
type on the interfaces?. And perhaps the ownership policy is only of
significance when the choice is destructive copy. Surely interface consumers
do not need the particular flavour of reference counting exposed to them.
It's not about converting from one choice to another - it's about
encapsulating those choices after they have been made - but only paying for
that encapsulation when we need it - ie when sending across an interface.

> In interfacing code, agreement on compatible types must be there. If we
all
> are on the same page on that, great.

I think I'm on the same page but reading between the lines ;-) . I'm
probably missing something, but I can't see why we need to agree on _all_
types and that they must _all_ be compatible - not if the smart_ptr is
capable of maintaining it's own "policy state".
Imagine a smart pointer where most of the policies were decided at runtime
by providing them to the constructor, like so (very generalised so I don't
have to get my smart_ptr facts right):

smarter_ptr<MyType, InterfaceSensitivePolicy> myObject( new MyType, new
InterfaceNeutralPolicy1, InterfaceNeutralPolicy2 );

Now the interface need only agree on the pointee type and, for sake of
argument, whether the pointer is of a destructive copy variety (a la
std::auto_ptr - but perhaps we would just use std::auto_ptr in that case and
reduce that template parameter too). There are probably other policies that
must remain exposed so we force the interface consumer to deal with them
(like conversion, perhaps - or does this drop out anyway).
Given such a design we can then write conversion constructors that accept
smart_ptrs and initialises the internal run-time policies with the static
policies of the source (maybe this could be done by holding the whole
smart_ptr inside the outer smart pointer...?)

> Then I'll come with the argument that
> policies don't make that agreement harder to reach in any way. Better yet,
> if you need, that agreement on compatible types can be much finer-grained,
> more typesafe, less prone to errors, and more efficient when using
policies
> as opposed to any other technique that's been discussed here.

I think I pretty much agree with what you say here - it was the just the
premise that that was all based on that I wasn't in entire agreement with.

> Nothing
> demeaning here, but to me it's hard to compare something that's clear how
it
> works, with a pie-in-the-sky design that takes compile-time stuff, puts it
> in runtime stuff, magically takes it back to compile-time stuff, and is
> somehow more advantageous in ways that are not told nor proven.

Admittedly my originally suggestion was a bit "pie-in-the-sky". I hope I
have fleshed it out a little. A more usable example is something that will
have to go on my weekend to-do list (which is already in danger of raising a
"full queue" event!)
To clear up one possible misunderstanding here, though: I am not proposing
that we "magically take it back to compile-time stuff" one we have it across
the interface. I don't think that would be possible for a start - and we
have probably already paid for it by then anyway (and we would pay more if
we could convert it back, I think).

As to the ways in which a reduced parameterisation of smart_ptrs in
interfaces is advantageous I think that is one thing that Dietmar did bring
out several times.

> Now I hope this post piqued your debating interest :o).

Indeed it has, you terrible man ;-)
You have me up into the early hours again doing this :-o
The least I can do is pique back...

Regards,

[)o
IhIL..