Hello
This is a known limitation. Cint can not accept variable argument.
In order to support it, I need to know stack layout which is machine
dependent. So the conclusion is you can not use variable argument in
cint and it is a hard limitation. If you would like to get similar
effect, I recommend to use operator overloading.
Thank you
Masaharu Goto
>
>Hi ROOT'ers,
>
>As some of you may (or may not) have noticed, I recently proposed a
>TException class. Though it is not the purpose of this mail to further
>that discussion, I'll use it to illustrate a my problem. You can find
>the source code for this class at:
>
> http://www.fys.ku.dk/~cholm/pub/TException.tar.gz
>
>(Note: www.fys.ku.dk is a bit unstable, so keep trying - evntually
>you'll get there - sorry about that.)
>
>My problem is this: I have an Abstract Base Class (ABC), that has a
>method that takes a "va_list" argument e.g.:
>
> #define MakeErrorString(X) va_list ap; va_start(ap,X); \
> SetErrorString(X,ap); va_end(ap);
>
> class TException : public TObject {
> protected:
> ...
> public:
> ...
> virtual void SetErrorString(const Char_t* fmt, void* ap);
> ClassDef(TException,0) // ABC Exception class for ROOT
> };
>
>And then I have some classes inheriting from this ABC, using the above
>mentioned method, e.g.
>
> class TWarning : public TException {
> public:
> TWarning(const Char_t* location, const Char_t* fmt, ...)
> : TException(kWarning,location) { MakeErrorString(fmt); }
> void* Execute(void* arg=0) { return &fExitCode; }
> ClassDef(TWarning,0) // Warning exception class for ROOT
> };
>
>Each of these classes could potentially be used in an interactive ROOT
>session, so I need to run "rootcint" to get the appropiate interface
>functions. On Digital Unix w/EGCS 1.1.2, this works fine up until I
>try to compile the source file created by "rootcint". Then the
>compiler fails miserably with:
>
> g++ -I./ -mcpu=ev5 -D__osf__ -D__alpha -I/opt/osf1/root/new/include -g -fPI
C -Wall -O2 -c -o EXCEPTION_Cint.o EXCEPTION_Cint.cxx
> EXCEPTION_Cint.cxx: In function `int G__TException_SetErrorString_2_0(struc
t G__value *, const char *, struct G__param *, int)':
> EXCEPTION_Cint.cxx:162: no matching function for call to
`__gnuc_va_list::$_0 (long int)'
> /opt/osf1/lib/gcc-lib/alphaev56-dec-osf4.0d/egcs-2.91.66/include/va-alpha.h
:
22: candidates are: __gnuc_va_list::$_0(const {anonymous struct} &)
> /opt/osf1/lib/gcc-lib/alphaev56-dec-osf4.0d/egcs-2.91.66/include/va-alpha.h
:
22: __gnuc_va_list::$_0()
>
>It seems that the fault is in the "rootcint" generated file
>"EXCEPTION_Cint.cxx" at the lines:
>
> static int G__TException_SetErrorString_2_0(G__value *result7,
> G__CONST char *funcname,
> struct G__param *libp,
> int hash) {
> G__setnull(result7);
> ((TException*)(G__getstructoffset()))
> ->SetErrorString((const Char_t*)G__int(libp->para[0]),
> (va_list)G__int(libp->para[1]));
> return(1 || funcname || hash || result7 || libp) ;
> }
>
>(slightly reformated for your viewing pleasure), in particular in the
>cast to "va_list" in the 8th line above.
>
>Now, is this a limitation of ROOT/Cint (I've seen the warning in
>"cint/include/stdarg.h"), and if so, is there any plans to remedy
>this? If not, is it due to some error on my part, or is my code FUBAR?
>
>Everything works nicely in a Linux Box though (2.2.12 kernel, EGCS
>1.1.2, GLIBC 2.1), as you'd expect.
>
>I'd be happy to hear any suggestions you might have. Thanks!
>
>Christian -----------------------------------------------------------
>Holm Christensen Phone: (+45) 35 35 96 91
> Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305
> DK-2200 Copenhagen N Web: www.nbi.dk/~cholm
> Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:22 MET