----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
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