[Top][All Lists]

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

Re: Compiling emacs-20.7 with gcc on m64k-next-nextstep4

From: Pascal Bourguignon
Subject: Re: Compiling emacs-20.7 with gcc on m64k-next-nextstep4
Date: Thu, 14 Jun 2001 11:09:31 +0200 (CEST)

> > I solved the problem by replacing macros by functions.
> Thanks for the info.  I will put this into etc/PROBLEMS.
> > As I  said, I think  that the  usage of macros  done in the  source of
> > emacs  is   preposterous.   Most  of   them  should  be   replaced  by
> > functions. Actually macros should almost never be used. They're just a
> > kludge to paliate  deficiencies of C. No high  level language has such
> > macros.
> IIRC, in Emacs sources, macros are mostly used for efficiency, or to 
> hide implementation of data types in case it will change in the future.

I  think  that  efficiency  is  better  archieved  with  a  good  data
structure, and  then using  those nice -O,  -O2, -O6 options.  And for
data hidding, better use a typedef.

     /** Private section. Please close your eyes **/
     struct emacs_private_you_dont_want_to_know_it {
         ugly_kludge    internal;
         dirty_clothes  in_family;
     /** Beep! Beep! End of private section. Please read on from here **/

     typedef struct emacs_private_you_dont_want_to_know_it emacs_public_t;

     extern void emacs_function(emacs_public_t* that);

> > The only place where  macros could be allowed, _was_ to define
> > constants  (now we should  use "const  int cst=1;"),
> Emacs still supports old compilers which don't know about `const'.

Yep, surely.  But it  does not support  gcc- (out of  the box).
How old are those compilers without const?

Do you mean that those  old k&r compilers can compile syntax.c without
problem? That they  run on platforms with more than 32  MB RAM and 500
MB virtual?

> > Well, and  to
> > protect  from   multiple  inclusions  of  headers,   since  RMS  can't
> > understand  that  it's better  to  use  #import  (without outputing  a
> > nagging warning) instead of #include...
> "#import"?  Isn't that highly unportable?

Yes.   It's a small  improvement coming  along with  Objective-C. This
sentence was  just some rants on  my part about the  way gcc sometimes
tries to "impose its law" by the way of warnings.

__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++

reply via email to

[Prev in Thread] Current Thread [Next in Thread]