bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Pascal Bourguignon
Subject: Re: Compiling emacs-20.7 with gcc 2.7.2.1 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-2.7.2.2 (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/

-----BEGIN GEEK CODE BLOCK-----
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++++
------END GEEK CODE BLOCK------



reply via email to

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