Boost logo

Boost :

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:


> 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

> The template-based IDL will make this stuff easier.


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


Boost list run by bdawes at, gregod at, cpdaniel at, john at