[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] GCC question



On Thu, 18 Nov 2010 00:03:12 , Henk Robbers <h.robbers@chello.nl> wrote:
> Helmut Karlowski wrote:
> > Am 17.11.2010, 00:07 Uhr, schrieb Vincent Rivière
> > <vincent.riviere@freesbee.fr>:
> >
> >> If you try to call it with any other number of arguments, it the
> >> compilation will quickly fail at preprocessing stage.
> >> This is what is happening to you, and why you are getting the error.
> >>
> >> With Pure C, which use a different GemLib, objc_draw() is probably
> >
> >
> > Pure-C acts different:
> >
> > It compiles without problems:
> >
> >
> > #define x(y)  (xy,y)
> > #define y(a,b,c,d)  (d,c,b,a)
> >
> > y(1,2,x(X))
> >
> >
> > while gcc complains.
> >
>
> I have looked into AHCC (pre.c #define X_REPAIR 1)
> The following is the case:
> Pure C expands macro's while collecting arguments.
> If a argument is a macro name it is expanded before insertion.
> Which is non standard. (But useful. And looks more obvious.)
> See K&R second edition A12.3 page 230 second alinea:
> "During collection, arguments are not macro-expanded."
>
> The C standard is a bad standard, due to incompetent compiler
> writers in the big firms. Clumsy code in existing compilers
> has been promoted to 'standard' because already too many programs
> were relying on the clumsinesses.
>

The gcc method is very crude while the method relied upon in the
Newsie code is more intuitive to coders. Presumably LatticeC uses
the same method as PureC

This was my solution which I think would work in all cases:

#define objc_draw3(dialg,s,d) objc_draw(dialg,s,d,dialg[0].ob_x-3,dialg[0].ob_y-3,dialg[0].ob_width+6,dialg[0].ob_height+6)

There are some others like this but not too many.

Regards,

Peter