[boost] Re: Re: Re: Re: BIL and boost::any

30 Jan 2005


      christopher diggins wrote:
...
----- Original Message -----
From: "Jonathan Turkanis" <technews@kangaroologic.com>
...
...
...
if (has_copy_ctor(i) && has_dtor(i)) {
   manual_ptr<AnyInterface> p = new_copy(i);
}
The problem here is that there's no portable way to tell whether a
type has an accessible destructor or copy constructor.
Could this not be done using by constructing static functions at
compile-time which call:
...
...
boost::has_nothrow_copy<T>::value
boost::has_trivial_destructor<T>::value
These traits require special compiler support (e.g. they always return false on
VC7.1) and don't query the correct properties (e.g. for a class to have a
*trivial* destructor, it must not declare a destructor, among other things).
...
...
I don't think Boost.Any ever assumes that user defined types are
default constructible.
Yes, I didn't mean to make it sound that way.
Okay.
...
...
...
then I would like to know how to create new interface
types which do that. I would like to be able to create a new
interface types, which interject new functions into the function
tables. I think this ability (to inherit from interface types and
interject new functions into function tables) should be part of the
interface functionality.
There are two problems:
- it's hard to see how to allow users to customize the interface
infrastructure,
since it's macro-based. There's just no place to stick policies
I agree, it is a hard problem, but not overcomeable.
...
- some of this functionality can only be made available for a subset
of the
classes whose instances a user might want to bind to an interface.
Different
user actions trigger different subsets of functionailty. It's hard
to see how to
make this into an extensible framework.
I have some ideas on how to do this, but it will have to wait until
my next post.
Okay. I look forward to it ;-)
...
...
The template-based IDL will make this stuff easier.
Agreed.
...
...
I showed above how the first two are useful at run-time. size_of()
is useful when writing code which is type-checked at run-time. It is
important for making dynamically typed algorithms more efficient.
The other two, I can't think of applications yet.
Could you give an example?
Of size_of?
Yes.
...
FuBar(null n) {
  if (n.type_info() == typeid(int)) {
    cout << extract<int>(n);
  }
}
I would rather say:
FuBar(IAnything n) {
  if (n.type_info() == typeid(int)) {
    cout << extract<int>(n);
  }
}
Yes, null looks a little funny here.

BTW, it should be

    target_type(n) == typeid(int)

Jonathan