|
Boost : |
From: John Torjo (john.lists_at_[hidden])
Date: 2003-08-05 13:02:45
>
> I might not have followed the discussion to deeply, but it does look to me
> like John is entirely right. Traits can fundamentally do one customization
> per type. That's not going to be enough if you have the same type
> representing multiple handles, as is the case with many C APIs. For
example,
> sockets and file descriptors might be both integers. Or, a variety of
> handles can come in the disguise of a void*. In Windows, if you #define
> STRICT, they use a trick to give different flavors of HANDLEs different
C++
> types (nothing fancy, it's all casts). Still, they forgot to do that for a
> couple of handle types (which were that? HBITMAP? HINTERNET? I can only
say
> HGEEITSBEENALONGTIME). So then after a team I was working with built a
very
> nice and sweet "smart handle" class using traits, we simply couldn't use
it
> because of this particular issue.
Indeed, but what about a wrapper for each time of handle, with a conversion
operator()?
I have used it a couple of times.
Something like:
struct hbitmap_wrapper {
hbitmap_wrapper( HBITMAP h);
operator HBITMAP() { ... }
...
};
Then in code, instead of HBITMAP, use hbitmap_wrappers.
Best,
John
>
> With a trait, you can only establish one way of dealing with int and one
way
> of dealing with void*. With a policy, you can define at the exact
> granularity that you want how exactly your handle maps to a type and how
it
> is manipulated - and that policy will be part of the object type. I'm not
> sure that the inheritance-based approach is superior or not, it sure would
> be worth some discussion.
>
> For more reference on traits, here are two articles that might be of
> relevance:
>
> http://www.moderncppdesign.com/publications/traits.html
> http://www.moderncppdesign.com/publications/traits_on_steroids.html
>
>
> Andrei
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk