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

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-01-30 15:16:41

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

> You mean it should be defined in the global namespace? Defining stuff in 
> the
> global namespace *causes* clashes.

Sorry, I meant "not a member function".

> As a result, a more general treatment, like Thorsten's, is needed.

I see.

> I prefer clone(), since it is an established name.

I agree now.

>> AnyInterface i = AnyObject;
>> //...
>> 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

> Also, it's important to note that adding more than a tightly controlled 
> handful
> of functions to interface tables can lead to code bloat, even when these
> functions are not used.

Yes, this is a good reason to leave it up to the user to decide.

>> Both pieces of code above are extremely useful, especially if we want
>> interfaces to have the same expressive power as boost::any.
>
> 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.

>> I am
>> currently redesigning my Object class in the OOTL, and if I have the
>> two above functions, it means that my objects no longer need any
>> special macros. (Remember OOTL_DEF_OBJECT?).
>
> Okay, I'm open to suggestions on how to implement this.

Next email.

> I'll certainly implement cloning, one way or another. I'm not yet 
> convinced of
> the value of default construction, though.

I don't have any use cases at the moment but I also don't care that much 
about default constructible for the time being.

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

> 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? Ummm... next email.

>>> Even when reflection is added, you'll only be able to query the 
>>> functions of
>>> the interface; you won't be able to bind the underlying object to an
>>> interface discovered at runtime -- unless this functionality is
>>> built into the class of
>>> the bound object.
>>
>> I realize that, but code like:
>>
>>   int x = extract<int>(null);
>>
>> would surprise the reader that it works.
>
> It wouldn't work. I was suggesting null as the name of a type, not an 
> object.

Yes, sorry.

>> The names that I like:
>>
>> IEmpty
>> IAnything
>> IUnknown
>> INull
>
> I'm not sure the name matters much, because it would usually be left
> unspecified:
>
>     template<typename Interface = null>
>     class any;
>
>    std::string s = "hello";
>    any<> a = s;
>    any<iterator> it = s.begin();

What about code like:

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);
  }
}

Whatever, this is trivial stuff, I don't really care that much.

> Also, while I've been using the microsoft interface naming convention for
> example interfaces, it violates the Boost guidelines for library classes.

Shucks, maybe Boost should update its guidelines ;)

best,
CD