Hi Masaharu,
Once again, I am impressed by your incredible efficiency!
> It was nice to meeting you at ROOT workshop.
>
> About auto_ptr and member function template, I made some progress.
> As far as the class template is interpreted and the member function
> templates are described within the template class definition, cint
> now correctly instantiates member function templates. There are 2
> member function templates in auto_ptr. Cint5.14.31 can interpret this.
>
> template<class X>
> class auto_ptr {
> public:
> template<class Y> auto_ptr(const auto_ptr<Y>& y) { ... }
> template<class Y> auto_ptr& operator=(const auto_ptr<Y>& y) { ... }
> };
Wonderful!
> Now, if I understand correctly, you want to use precompiled auto_ptr
> and instantiate member function template afterwards, which means member
> function template is interpreted. Looking at the auto_ptr definition, I
> could not think of ways to do so. Problems are
Yes. I think this is needed so that, for example, you can return an
auto_ptr from a compiled function. (This is a very natural idiom for
functions which return a 'new'ed pointer that the user is responsible
to delete; if you return an auto_ptr instead, such functions can be
used to create temporary objects which can be used transparently in
expressions without the user worrying about deleting them).
Here's an example of how/why one might want to do this, without any
real class members:
class X: public Base1 {};
class Base1: public TObject {};
auto_ptr<Base1 *> FactoryFunction() { return new X; }
and in CINT:
auto_ptr<Base1 *> p = FactoryFunction();
auto_ptr<TObject *> localobjs[10];
// localobjs is a polymorphic list of resources I own to be cleaned up
// appropriately. I'm not using an STL container here because they don't
// work well with auto_ptr :(
localobjs[2] = p;
where the assignment will want the templated operator=. (And the
'return new X' used the copy-constructor template, but that one
happened in compiled code so CINT doesn't care).
Of course, the problems you note immediately arise, and I don't see any
workarounds either, other than compiling in the template as needed,
since a native compiler is really needed to avoid the private member
issues.
Perhaps CINT can be smart enough to do this:
1) Keep a list of known linked-in instantiated template members for
each class.
(perhaps with some known-to-be-useful versions (like that for derived
classes like above) specifiable in a LinkDef ahead of time)
2) When an unknown one is needed, create a very simple temporary C++
code file that simply instantiates the needed template function in
object code. It knows the header the template came from, of course, so
this should be as simple as:
#include "templateheader.h"
template <> auto_ptr<TObject *>(auto_ptr<Base1 *>&);
3) compile with the native compiler, load in, and add to its list.
I would probably not have 2 and 3 invoked automatically, but only upon
user request (which does nothing if the function is already linked in,
and which should be callable from a macro), with CINT giving an error
message otherwise.
Do you think this would be possible? I note it only really helps if
you've got shareable libs (otherwise you have to specify all your
instantiations to CINT at LinkDef/makecint time), but most people using
CINT have and use that anyway, so...
George
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:18 MET