NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/cplus/15938

Internet Message Format | 1992-11-08 | 2.7 KB

Path: sparky!uunet!mcsun!uknet!doc.ic.ac.uk!agate!spool.mu.edu!darwin.sura.net!sgiblab!munnari.oz.au!mel.dit.csiro.au!mineng.dmpe.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!metro!otc!swdev!grahamd
From: [e-mail] (Graham Dumpleton)
Newsgroups: comp.lang.c++
Subject: Re: Template with pointer-to-member-function problem
Message-ID: <[e-mail]>
Date: 7 Nov 92 23:37:09 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: Technology Development Group, OTC Australia
Lines: 42

In article <[e-mail]>, [e-mail] (HARTMUT KOCHER) writes:
> The following code shows an excerpt of a call back template class.
> It takes a reference to a class and a pointer to member function
> of the same class. When I compile this code with HP cfront 3.0, I
> get the following error message for the contructor call:
> CC: "test.C", line 33: error: bad argument 2 type for
> CB <Test> ::CB__pt__6_4Test(): void (Test::*)()
> ( void (Test::*)() expected) (1264)
>
> Obviously, the arguments are the same, so why is cfront complaining?
> If I make a non-template class with the same functionality,
> everything works as expected. Any ideas, what's going wrong here?
> Is there a workaround for this? I also tried to use a typedef for
> the pointer to member function, but this confuses cfront even more.
> Also, if I supply 0 for the function pointer, cfront aborts with an
> internal error.
>
> What can I do? Any help would be appreciated!

If HP's compiler is indeed simply a port of AT&T's compiler then the problem
is because there is a bug in AT&T C++ version 3.0.1 (3.0 as well probably).
We contacted AT&T about this problem and it has been fixed for their version
3.0.2 compiler. In our playing we were not able to find any satisfactory
workaround so we ending up tracking down the problem in the cfront src and
fixing it ourselves.

Since you got your compiler from HP I would suggest contacting them although
what help you can get will probably depend on whether you pay software
maintenance. It would also depend on whether AT&T gives out fixes to
particular problems.

BTW, once this problem is fixed it is not all plain sailing. In particular
if you had actually made CB<T>::CallBack() inline you would have exercised
another bug in cfront 3.0.1 with the result being an internal error. When we
contacted AT&T they indicated that this problem had not been fixed and
probably wouldn't be for version 3.0.2. However since you can quite happily
make the function non-inline and have it work it isn't too serious.

Hope this helps.

--
Graham Dumpleton ([e-mail])