Hello Walter,
Did you try the same with compiler? I guess this does not work
either. Function with variable argument has to be informed each
argument type, in this case, with format parameter.
1st arg : %5d int decimal
2nd : %8.8x int hex
3rd : %8.8x int hex
So, passing Short_t does not work.
Besides this, I do not recommend using short and float in
variable argument because some compiler can not handle
them. Cint copies compilers limitation as is. But because
the limitation is compiler dependent, Cint behavior differs
with compiler. Please use int, long and double for variable
argument.
Thank you
Masa Goto
> -----Original Message-----
> From: owner-roottalk@pcroot.cern.ch
> [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Walter F.J. Mueller
> Sent: Wednesday, July 30, 2003 6:38 PM
> To: roottalk
> Subject: [ROOT] CINT, variable argument lists and Short_t
>
>
> Dear ROOTers,
>
> I'm having some problems with passing Short_t variables to Form() when
> using CINT. When I use in a macro something like
>
> cout << Form("enum: %5d; q[2] = %8.8x %8.8x",
> i_nevent, on_camac->q[2], (Int_t) on_camac->q[2])
> << endl;
>
> with i_nevent being an Int_t and q[] being an array of Short_t I get
> sometimes confused output for the 2nd argument which is passed as
> Short_t. A sample output might look like
>
> enum: 0; q[2] = 000000aa 000000aa
> enum: 1; q[2] = 08ac012e 0000012e
> enum: 2; q[2] = 08ac00fb 000000fb
> enum: 3; q[2] = 08ac0129 00000129
> enum: 4; q[2] = 08ac00f2 000000f2
>
> When running this as compiled code (via ACLiC) I get
>
> enum: 0; q[2] = 000000aa 000000aa
> enum: 1; q[2] = 0000012e 0000012e
> enum: 2; q[2] = 000000fb 000000fb
> enum: 3; q[2] = 00000129 00000129
> enum: 4; q[2] = 000000f2 000000f2
>
> My understanding of variable argument lists (as used in Form()) is
> that char and short types are promoted to int before they are passed,
> also floats are promoted to double, like in traditional C.
>
> So I'm led to the assumption that CINT does not always properly properly
> do this for Short_t variables. As a consequence a %d or %x conversion,
> which accesses an int, sees sometimes garbage in the upper 16 bits.
>
> It seems that these problems occur only for the 2nd or later parameters
> of the ellipse (that is the 3rd one or later in the total arglist).
>
>
> With best regards,
>
> Walter
>
>
> --
> --
> Walter F.J. Mueller Mail: W.F.J.Mueller@gsi.de
> GSI, Abteilung KP3 Phone: +49-6159-71-2766
> D-64291 Darmstadt FAX: +49-6159-71-2989
> WWW: http://www-kp3.gsi.de/www/kp3/people/mueller.html
>
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:14 MET