Re: do {...} while(0) macros

["Karim Belabas" <Karim.Belabas@math.u-bordeaux1.fr>]

* Bill Allombert [2006-06-16 16:48]:
> On Wed, Jun 14, 2006 at 05:50:37PM +0200, Karim Belabas wrote:
> > Hi all,
> > 
> >   in order to emulate templates in ANSI C, some of the pari code uses the
> > (standard, ugly) macro construct:
> > 
> >   #define foo  do { A; B; } while (0)
> 
> > This is especially annoying for the (deprecated) addsiz functions which
> > one might conceivably find in code such as
> > 
> >     GEN i;
> >     for ( i = N0; cmpii(i, N) < 0; addsiz(i, 1, i) )
> > 
> > ( Which is inefficient and should be written differently, as all code
> > using the <fun>z functions, but this is beside the point. )
> > 
> > 
> > The simplest "solution" seems to generate most of paricom.h automatically
> > from a template [ see the "OPERATION BY VALUE" part ].
> 
> How this would fix this problem ? Unless you mean replacing the
> macros by functions calls (whic is an option).

Yes this is what I meant.  Easy, but I don't like this solution :-)

> > A seemingly better solution is to kill all (obsolete, inefficient,
> > difficult to use) <fun>z functions in pari-2.5.
> 
> Well having a set of function with GMP-style interface and reasonable
> speed would be useful. Unfortunately <fun>z are usually terribly slow

Not _terribly_ slow, since the overhead is (essentially) linear in
the output size. But indeed, a sequence of e.g. single word addiiz (or
muliiz) is about 50% slower than the same sequence of addii (or mulii) with
a few gerepile (PIV 2.8 GHz, native kernel, pari-2.3.0)

>> An intermediate solution would be to simply document the problem (say as
>> a FAQ item) and forget about it.
> 
> In my opinion, we _have to_ document the list of function that are
> actually macros, because macros always behave differently than functions
> (e.g you cannot dlopen() them). On the other hand, the way we implement
> macros is perfectly standard and should not cause surprise once they are 
> documented as macros.

Agreed. But I'd like a clean up first. This interface might conceivably be
useful in low level routines, e.g. addii [ provided someone eventually
provides a sensible implementation, where the 'output' parameter is
directly used as pre-allocated storage ( NOT affii(addii(x,y), z) ) ].

But I see no use  for gexpz (or even mpexpz !)

Cheers,

    K.B.
-- 
Karim Belabas                  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]