Usage of ANSI-C |const| in X11 code...

[Roland Mainz]

Adam Jackson wrote:
> > Yeah, but note the underscore (indicating that it's more some
> > (semi-)private stuff) - |_Xconst| is more a hack for the old days when
> > K&R compilers needed to be supported. Since a while ANSI-C89 support is
> > the minimum required and some code in libX11, Xserver and other places
> > already uses |const| without causing complains. So my question is
> > whether code can now "officially" use |const| directly (CC:'ing
> > xorg-arch at lists.x.org as this is more an architecture question, IMO we
> > need need a clear statement that ANSI-C89 is now the minimum level and
> > all it's features[1] can be used by Xorg code) ...
> 
> Can anyone even name a compiler shipped in the last ten years for any major
> operating system that didn't include ANSI C support?

AFAIK no new operating system (but there are still a couple of companies
out there who have to support their old stuff... ,-/)

> > [1]=Next question would be whether the |inline| keyword can be used in
> > Xorg code - |inline| is newer than ANSI C89 (maybe C99 but I am not
> > sure) but most compilers incl. gcc, Sun Workshop/Forte/One and the MS
> > compiler support it right now...
> 
> Specifying inline is rarely worth the effort, for a few reasons.  The compiler
> will usually ignore your suggestion and inline what it feels like anyway.

gcc may behave like that but other compilers are more strict with the
default optimisation level (but still offer automatic inlining in higher
levels) ...

> Also, unless your function is also static, you have to emit an out-of-line
> version of the function anyway since it could be called from another
> compilation unit, so that's N+1 copies of the function body.  For most modern
> processors, cache misses are much more expensive than function calls, so
> inlining can actually make your code slower.
> 
> It's kind of like the register keyword.  If it makes you feel better, you can
> add it to your declarations, but it's really not going to change anything.

AFAIK on some platforms (SPARC comes in mind) it makes a huge difference
as values are passed in registers (unless all registers are used up) and
not via the stack (and no stack version is provided).

> If we find performance-critical code where inlining makes a difference for a
> given compiler, we should handle that case-by-case, because heuristics differ
> and what's fast in gcc may be slow in sun c.

My point with using |inline| was more to replace some of the very ugly
#define macros with |inline| functions (|static inline| to be exactly)
to give the compiler better ways for type checking, the optimizer a way
to analyse (e.g. profiling) the code correctly (I am looking here at Sun
Workshop's XIPO option which allows the optimizer to operate application
wide in one step (e.g. the optimizer can inline&&optimize over all
source files in one step (which gives nice performance boosts when this
step is combined with profile-feedback))) and make the code more
readable, too.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)