In message <3qd9fa$125e@news.doit.wisc.edu> - khan@xraylith.wisc.edu (Mumit
Khan) writes:
:>
:>In article <3q41i6$i36@keystone.intergate.net>,
:> <scherrey@proteus-tech.com> wrote:
:>>
:>> I took your code and and attempted to replace the int* with my class.
:>>The result was a few compile-time errors which were solved by the following
:>>explicit function declarations:
:>>
:>>inline void destroy( DeleteHole** pointer )
:>>{
:>> (*pointer)->~DeleteHole();
:>>}
:>>inline void construct( DeleteHole** p, const DeleteHole* value )
:>>{
:>> new (p) (const DeleteHole*)(value);
:>>}
:>>
:>
:>Ben,
:>Does Borland OS/2 C++ compiler support explicitly calling a template
:>desctructor? If not, that's the reason why you need the specialization
:>above to deal with it. It does look like a compiler limitation as opposed
:>to HP's STL release.

:>ps. does my example actually work when you add the allocator/deallocator?
:>

 Yep - code seems to work fine now. Thanx much for the help. Meanwhile, I
don't think its a compiler error. Here's the code in HP's STL that gave me
fits:

file defalloc.h
---------------

template <class T>
inline void destroy( T* pointer ) {
 (pointer)->~T();
}

template <class T1, class T2>
inline void construct( T1* p, const T2& value ) {
 new (p) T1(value);
}
---------------

Given my code, HP's template code would resolve to the following:

inline void destroy( DeleteHole** pointer ) {
 (pointer)->~DeleteHole*();
}

Which is clearly a BAD idea! My code has to explicitly dereference the pointer
and then call the destructor for DeleteHole as there is no DeleteHole*
destructor. There are similar ( yet different! ;-> ) issues with the construct
template function.

:>As an alternative to this method, how about wrapping the pointer to class
:>X in another class, say XPtrWrapper, and then storing the wrapper object
:>which will let the compiler manage the construction and destruction
:>automatically?

 Yes - this was my original workaround but not what I'd want to have to live
with. Thanx to your hints, I was able to get a usable workaround but I'm
hoping that it's not going to be the final solution. Of course, I can't quite
think, off hand, how to rework the HP STL code to deal with this issue. Have
you tried putting a pointer to a user defined class in your system to see if
it works? I notice that the HP code has explicit functions for pointers to
built-in types so you won't catch it that way.

//
// Benjamin Scherrey        Proteus Technologies, Inc.
// scherrey@proteus-tech.com       (404) 454-1013v 986-9876f
//