Re: registering "class converters"

David Abrahams wrote:
> Daniel Wallin <[email protected]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Daniel Wallin <[email protected]> writes:
>>
>>[snip]
>>
>>>>Thus, the converter used for classes registered with class_ could be
>>>>something like:
>>>>
>>>>  void* converter(
>>>>      void* src
>>>>    , backend::class_ const* class_
>>>>    , holder_installer const& installer)
>>>>  {
>>>>      std::pair<void*, void*> x = make_lua_instance(class_);
>>>
>>>                                     ^^^^^^^^^^^^^^^^^
>>>This is the part I don't understand.  Why not pass that from the
>>>backend as part of the aforementioned function<...>?
>>
>>What I said above and: optimization perhaps? IMO not allocating memory
>>if we don't have to is a Good Thing, if it doesn't complicate things.
>>Maybe I'm wrong and it does complicate things, but I don't see it yet.
> 
> 
> You lost me.  What memory allocation are you referring to?

The allocation that produces the holder that is passed to the backend.

   function<void(std::auto_ptr<instance_link>)>
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It is likely that a dynamic allocation is already taking place in the
backend, when creating the xxx instance and the holder could be stored
there. Luabind does this, and IIRC so does BPL.

>>>We could detect dereferenceable types automatically at the point of
>>>wrapping the function doing the return.  Why not?  Then optional<T>
>>>could be returned!
>>
>>I don't think I like that. Dereferencable is too weak. 
> 
> 
> Why?

Maybe I'm not understanding what you want to use dereferenceable for, but..

Having a get_pointer() overload for T implies that T is a smart pointer,
and from that we decide that we should just copy and store the smart
pointer by value in a holder. Thus we are deducing copyability from
get_pointer. Doing the same thing from dereferenceable seems dangerous
because it's less explicit. Any type can have a dereference operator,
without being copyable. This is true for get_pointer() as well, but it
seems less dangerous.

>>Why not get_pointer() instead? 
> 
> 
> That's OK too, probably... but why?
> 
> 
>>That's what I'm doing now:
>>
>>   if has_get_pointer<T>
>>       use smart_pointer holder generator
> 
> 
> I dont' understand what "use" means here.

It means, generate a holder type that holds the smart pointer by value.
Generate a function that can be passed to the backend, and when invoked,
installs this holder in an instance.

>>However, my point was that if we have a function:
>>
>>   std::auto_ptr<X> f();
>>
>>And want to look for a converter in the registry, and use
>>type_id<std::auto_ptr<X> > to do the lookup, someone has to register
>>this type. 
> 
> 
> I don't see the problem; can't you register it at the point that f is
> wrapped?

Yes, you could. You could do something like:

   if (has_get_pointer<T>)
       backend.register_holder_converter(type_id<T>());

Maybe that's better..

-- 
Daniel Wallin



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php