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

From: Hoeffner, Detlef (Detlef.Hoeffner_at_[hidden])
Date: 2002-04-30 08:02:40

This topic is important in particular for software projects with more 
than one team member. What I understand from Dietmar's postings are 
the following things:

1) It is worth providing and using policy smart pointers.
2) It is not acceptable to use an explicit type declaration including
   all template parameters in interfaces for code that uses the
   smart pointers.
3) For a type there should be a default smart pointer type that might be 
   defined e.g. through the provider of the class. This smart
   pointer type might be a concrete template instantiation of the 
   policy based smart pointer type. Important is that the average user 
   of this smart pointer should not be bothered with questions which 
   policies are required for a smart pointer. In the average case a
   default smart pointer for each type should be somehow available.
   If this is achieved through typedefs and a naming conventions, 
   through type traits or through a template specialization is another
   question. Important is that there is a standard way to provide a
   default smart pointer for a type.

Regards

Detlef

-----Original Message-----
From: Andrei Alexandrescu [mailto:andrewalex_at_[hidden]]
Sent: Dienstag, 30. April 2002 04:38
To: boost_at_[hidden]
Subject: [boost] Re: Traits-based design and ODR

"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.

In interfacing code, agreement on compatible types must be there. If we all
are on the same page on that, great. 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. 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.

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

Andrei

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost