Hello Richard,
Thank you for reporting this. I've been trying to solve this
for several days.
First, this kind of member template specialization was not
supported by Cint. So, it is obvious that this has a problem.
Second, when I comment out the part you pointed out in the
dictionary, my g++ (RedHat6.2 Linux) still complains that there
is no matching template. I am trying to figure this out by reading
ANSI/ISO C++, however, things are pretty ambiguous to me.
Could you point out which part of C++ standard explains about this
kind of template specialization?
Thank you
Masaharu Goto
>Date: Mon, 25 Jun 2001 21:02:12 +0200 (CEST)
>From: "Richard B. Kreckel" <kreckel@ginac.de>
>Reply-To: Richard.Kreckel@Uni-Mainz.DE
>To: Masaharu Goto <MXJ02154@niftyserve.or.jp>
>Subject: Here comes the next one...
>
>Dear Masaharu,
>
>As I mentioned, the new GiNaC cannot be used with Cint right now. The
>`unsigned' bug was the first problem on the way of making it work
>again. Thanks a lot for fixing it! Now, I encounter a problem with
>the combination of template specializations and namespaces. When I remove
>these problems manually in the generated G__*.C file I get very close to
>a running system again! The problem can easily be triggered by the given
>header file:
>
>namespace canig {
>
> class ABC {
> public:
> ABC() : tinfo_key(0) {}
> unsigned tinfo() const { return tinfo_key; }
> private:
> const unsigned tinfo_key;
> };
>
> class foo : public ABC {
> public:
> foo() : tinfo_key(1) {}
> unsigned tinfo() const { return tinfo_key; }
> private:
> const unsigned tinfo_key;
> };
> class bar : public ABC {
> bar() : tinfo_key(2) {}
> unsigned tinfo() const { return tinfo_key; }
> private:
> const unsigned tinfo_key;
> };
>
> template <class T>
> inline bool is_exactly_a(const class ABC & obj)
> {
> const T _t; return _t.tinfo()==obj.tinfo();
> }
> // specialization:
> template<> inline bool is_exactly_a<foo>(const ABC & obj)
> {
> return obj.tinfo()==1;
> }
>
>}
>
>It is effectivly a hand-made typeof scheme, using templates for an
>intuitive syntax. The specialization is necessary for obtaining good
>performance. The general case is a fallback. But inside the
>specialization it turns out that `foo' is not properly declared as
>`canig::foo':
>
>static int G__canig_is_exactly_alEfoogR_0_0(G__value *result7,G__CONST char
*funcname,struct G__param *libp,int hash) {
>G__letint(result7,105,(long)canig::is_exactly_a<foo>(*(canig::ABC*)libp->para
[
0].ref));
> return(1 || funcname || hash || result7 || libp) ;
>}
>
>Can this easily be fixed? Thank you very much so far!!!
>
>Best wishes
> -richy.
>
>PS: By the way, you are more than welcome to include GiNaC in the list
> of applications inside the file `README.txt'!
>--
>Richard Kreckel
><Richard.Kreckel@Uni-Mainz.DE>
><http://wwwthep.physik.uni-mainz.de/~kreckel/>
>
>
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:50 MET