On 07/12/2004 03:42 PM, Maciej Sobczak wrote: [snip]
Exactly, that was my point. There are third-party APIs (and even operating system interfaces, like file descriptors) where resources are not handled by explicit pointers, but by "handles", which are usually lightweight copyable types.
[snip]
I guess that policy-based smart pointer design + template typedefs would solve this problem (and many others) definitely. :)
I think there might have been talk of getting a policy base smart pointer to do this kind of thing as well.
I guess that nothing much has happened yet because the need isn't that great.
Well, that depends on how you look at it. I'd risk a claim that 95% of programmers would need smart handles more often than, say, 50% of what is currently in Boost, especially considering the fact that smart handle would not be a foreign concept - this is just a smart pointer concept applied to generic resource. Quite common stuff, I think. Of course, your mileages may vary.
[snip] I've been thinking about generalizing it for reflection. For example, for every type which is to be "reflected", the instances of that type would be stored in a reflector handle. The "reflection" (i.e. information on all the reflector handles) of a type, T, would be stored in reflection<T>. This information is similar to that used for garbage collection of cycles; hence, I think the code in: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/mana... could be used.