Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-01-30 14:28:39

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

>> Cloning must be introduced at some point. I've been trying to find a
>> way to make cloning just another function, but am becoming convinced it's sui
>> generis. Since Thortsen uses cloning for his Smart Containers library, I
think I'll
>> just borrow concepts and machinery from him.
>> I'm not sure what you mean by "clone(interface_value)", though.
> I meant Clone() should be a global function instead of a member
> function to avoid namespace clashes.

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

> I am not sure I understand what you mean by making cloning as just
> another function.

I'm not sure what I mean either. I guess I was hoping that a natural and elegant
treatment of cloning would appear magically. :-)

> I also don't think Clone is unique. Clone is
> essentially a call to the copy constructor of the object,

This doesn't work for polymorphic classes. For instance, you might be given an
object as a pointer or reference to an abstract class. More generally, you
typically want to call the copy constructor of the *most-derived* class, but you
may be given a pointer or reference to a base class. And you might want to call
a member function clone() even if the static type has an accessible copy

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

The same problem exists for destructors, but there is a built-in language
mechanism to solve the problem: the virtual destructor. So we adopt the
convention that an object of a class without a virtual destructor should never
be passed around as a pointer to a base class.

> So I would propose (renaming Clone to new_copy):

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

> 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. With the smart pointer templates, the
burden is on the user: you can't bind a dynamically allocated object to a smart
pointer unless the static type of the object has an accessible destructor or or
unless you're using shared_ptr with a custom deleter.

Similarly, we need a way to put the burden on the user for clonability. Daniel
James suggested having a special clone function which could be declared in an


> also:
> AnyInterface i = AnyObject;
> //...
> if (has_default_ctor(i) && has_dtor(i)) {
> manual_ptr<AnyInterface> p = new_default_ctor(i);
> }

Here, again, unless you know how to determine whether an object has a trivial
default constructor, we'd have to put the burden on the user. E.g.,


This case doesn't seem as useful as clone, IMO.

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.

> 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

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

>> You could determine this stuff (to the extent the language allows)
>> at the time of binding, and make it available at runtime.
> Do you mean by adding functions to the class?

I meant you could determine the results of a bunch of boolean traits, and store
them as flags in the interface table. However, I didn't understand why you
wanted this information.

> I want to automate the
> process somewhat and remove my dependence on my stupid
> DEF_OOTL_OBJECT macro. If you don't provide this functionality within
> interface,

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

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

The template-based IDL will make this stuff easier.

>> However, most of this stuff is
>> useful only at compile time.
> 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?

>>>> I'm thinking of adding a template boost::interfaces::any, which has
>>>> (I think boost::interfaces::null might be a better name for
>>>> IAnything.)
>>> How about IUnknown? It will be especially meaningful when
>>> boost::interfaces allow dynamic introspection.
>> 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.

> The names that I like:
> IEmpty
> IAnything
> IUnknown
> INull

I'm not sure the name matters much, because it would usually be left

     template<typename Interface = null>
     class any;

    std::string s = "hello";
    any<> a = s;
    any<iterator> it = s.begin();

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


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