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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-01-30 18:06:04

christopher diggins wrote:
> ----- Original Message -----
> From: "Jonathan Turkanis" <technews_at_[hidden]>

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