Re: [pclasses-devel] back to the SharedLib handle problem...

[Christian P. <cp...@se...>]

The Client should not need to access the native handle.
I think current implementation is OK. What i meant with "templatize" the 
handle type was only regarding the SharedLibCache template class.

I don't like to #ifdef the handle types in the headers, gives to many 
problems. P 0.8 did it this way.

Am Samstag 25 Dezember 2004 17:58 schrieb stephan beal:
> We could use traits.
>
>
> template <typename SharedLibImplTag>
> HandleTraits
> {
>  typedef unsigned long handle_type;
> }
>
> Inside SharedLib.ltdl.cpp we define the following:
>
>
> template <>
> HandleTraits<lt_handle_t> // or some internal marker type
> {
>  typedef lt_handle_t handle_type;
> }
>
> And in SharedLib's impl we reference _handle via the traits type.
>
> The problem with that is that client code using SharedLib.ltdl only has
> access to HandleTraits's *default* implementation, because the
> specialization must live in hidden impl code. This means that clients
> won't be able to get at the handle in it's native form. This isn't a
> bad thing, but it means that the handle() function in SharedLib.ltdl
> would still need to return the default handle_type. That means that
> we're still basically stuck with not being able to pass the handle back
> to the client properly (currently requires 2 casts: one to void *, then
> one to ulong).
> Or we could put the traits types in public headers and #ifdef the proper
> specialization(s) in.
>
> One idea might be making a base class for SharedLib:
>  AbstractSharedLib<HandleT>
>  SharedLib : public AbstractSharedLib<ulong>
>  SharedLibLtDl : public AbstractSharedLib<lt_handle_t>
>
> i don't know if this buys us any flexibility, though.
>
> ???