Re: Registries [2]

Daniel Wallin <[email protected]> writes:

> At 13:51 2003-07-28, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > At 10:20 2003-07-28, Daniel Wallin wrote:
>> >>At 01:10 2003-07-28, David Abrahams wrote:
>> >>>Oh.  The implicit imports I thought we'd handle by having a global
>> >>>converter registration chain for any type and simply tacking it onto
>> >>>the end of each extension's local chain as part of the initialization
>> >>>of the local registration.
>> >>
>> >>Right, but this seems to imply the same implementation that I suggested.
>> >>Because even if module Y is initialized after module X, module X needs
>> >>to know about the converters module Y exposes. So the initialization of
>> >>module Y needs to add converters do module X's registry. Right?
>> >
>> > I think I misinterpreted this, did you mean linking the actual
>> chains together
>> > rather than adding converters from the global chain to the local ones?
>>
>>Yes, I meant essentially that all local chains for a type would share
>>a tail: the corresponding global chain.
>
> Ok, I've been thinking about this.
>
> The biggest problem I can see with this is that we can't eliminate
> duplicate converters, if a module registers a converter for type X
> it will get a duplicate in the global chain. Of course things will
> still work as expected, but overload resolution will suffer in terms
> of performance since we'd need to try more converters before we can
> conclude that there's no match.

Oh, I guess.  I don't really think failed matches have to be fast, but
I also don't really care if you want to use a more-sophisticated
mechanism to optimize them.

> Also, identical converters registered by multiple modules can't be separated,
> so we'd end up with a lot of identical converters for primitive types.
> I guess we could keep all primitive converters in the shared
> library.

I don't see "where they are kept" quite the same way you do, I
think -- it's all one shared memory space.  However, yeah, the shared
lib should register those primitives itself.  That's what
Boost.Python does now.

> This is an issue with automatic importing in general though.

Not sure I see an issue.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01