Re: Registries

At 23:18 2003-07-14, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> >> Well, yeah, or type_info comparing, depending on how cooperative
> >> the native support for RTTI across shared libs is.
> >>
> >> > In that case we have the same problem of unique ID's with the
> >> > conversion registry as well.
> >>
> >>I don't think I understand what you're saying here.
> >
> > I'm saying that this has very little to do with people sticking
> > everything in the global namespace, and more to do with our
> > inability to generate unique id's for types. We would only need
> > different cast-graphs if there are type id conflicts, just like we
> > need to isolate the conversion registries if there are conflicts.
> > Or am I missing something?
>
>Sort of; at least you're boiling this down to "unique typeid
>generation" when it's not really that simple.  What makes a type ::X
>in module A different from a type ::X in module B?  If they're defined
>differently and A/B are in the same "program" (the term "program" is
>still undefined w.r.t. C++ and shared libs), there's an ODR violation.
>
>Even if we had a way to generate a unique ID for types, it would
>almost surely be based on their names, wouldn't it?

I guess so.. But all problems with this disappear if we have local registries
or scopes, correct?

> > Right. I don't have any answers to those, it all seems really
> > complicated and I can't really see any clever solutions to any of
> > it.
>
>I think there are some basic facts that limit how much we can expect
>to do.  Once we explore those, I think it will simplify things.
>
>* Extension modules have to be linked to the same langbinding library
>in order to share any type/conversion information.
>
>* On most Unices, that means they get no isolation for ordinary link
>   symbols.  Under glibc static data members of class templates will
>   usually not be shared unless the first library loaded is linked to
>   the other one, but I wouldn't want to try to take advantage of that
>   quirk.  So on Unix, that means we don't have worry about unique IDs
>   beyond what typeid() provides.
>
>* On Windows, unless the programmer has decided to link them together
>   (there are often good reasons to do it) those extension modules have
>   completely isolated link symbol spaces.  I think the registry
>   scoping scheme solves the problem of type IDs here, though I think
>   we'll need something more-sophisticated than we've discussed so
>   far.  Please ask me detailed questions if you don't see immediately
>   how registry scoping helps.

Because if two modules expose a type which would cause a collision the
converters would be registered in the modules local scope?

>I'm actually thinking that in addition to C++-style outward searching
>through scopes for converters we need something like using directives
>and declarations for converters.  When a module wants to interact with
>another module from an unrelated package it should be able to "use"
>the entire module or any type within it, which would bring all the
>converter registrations from the other module into its own registry.
>
>Thoughts?

Sounds good. But is it really necessary to have outward searching, or even
scopes at all? Can't we just have a flat hierarchy of modules that always
need to explicitly import types from other modules?

It would simplify converter lookup a great deal.

void init_my_module()
{
   register_module("my_module"); // register this modules conversion 
registry in
                                                 // the shared library
   using_module("second_module"); // import entire module
   using_<A>("third_module"); // import one type

   module(..)
   [
     class_<B, A>("B")
   ];
}

That would mean we wouldn't have any central converter registry at all, but 
rather
a central registry of converter-registries.

This makes the system sensitive to ordering though, but I don't know if 
that's really
an issue.

>P.S. Are lua extensions built as shared libs?

Well, there isn't any standardized extension system. But I think there are some
third party code that allows you to load a module from a shared library with a
function call from lua. I blame this for my lack of knowledge on shared 
libraries. ;-)

---
Daniel Wallin



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1