On 8 Jun., 22:14, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Jun 8, 2010, at 11:05 AM, leif wrote:
> > On 8 Jun., 19:25, Bill Hart <goodwillh...@googlemail.com> wrote:
> >> My recommendation would be to stick with ANSI C as much as
> >> possible. I
> >> doubt comments // will be a problem.
>
> > Though many compilers (and preprocessors) support this, I would avoid
> > them unless the code *is* C99 or C++.
>
> Why?
Because many!=all. That *some* parts of Sage e.g. [currently!] require
gcc, doesn't mean everybody will always want to compile all parts with
gcc. (Same with C99. The chance of being mostly portable increases
with avoiding features not really necessary.)
Btw, compilers are not the only tools that deal with source code.
> >> The inline sematics are different
> >> in c99 and in general cause a screwup across compiler versions.
>
> > If using ANSI C, one should either use macros instead or at least use
> > an INLINE which then expands to "inline" or nothing, depending on the
> > compiler/platform.
>
> >> I would say, in a .h file static inline is fine, otherwise eschew the
> >> use of inline.
>
> >> Other problems for porting to windows include:
>
> >> 1) Variable declarations which are not at the start of a block
> >> *including* in for loops, e.g. for (long i = 0; i < big; i++) is
> >> invalid except in c99 (many c99 implementations don't even support
> >> this).
>
> > That's a really superfluous feature, and can be avoided (as well as
> > any local variable declarations within the "middle" of a body).
>
> I actually really like putting variable declarations as close as
> possible to where they're used, but I guess that's a matter of style.
Human-written functions and especially bodies (statement blocks)
should usually (but not always) not be that large that variable
declarations at their beginning were far away from their use/true
scope.
IMHO it is good style to put the declarations of "very" locally used
variables in a body (at the beginning!) that reflects the variables'
scope (i.e. if necessary create a new scope), despite modern compilers
being smart enough to do sophisticated register allocation. It's just
more readable, and likely to avoid coding errors (like declaring
parameters passed by value const, which doesn't influence code
generation - at least if they are anyhow only read).
> I'm all for standards, but personally I don't care much about the -
> ansi -pedantic flags--I've got better things to worry about. Some
> people do find this kind of thing important though, and they can spend
> their time changing // to /* */.
Tedious of course. But IMHO it's dumb if that's the only C99/C++
feature actually used.
Especially in header files that are intended to be used by many
different components.
"-ansi -pedantic" is nice if you intend to port things (or use other
tools, see above).
And I hate to get tons of "unrelated" (unnecessary) warnings or even
errors when doing so (including "-Wstrict-prototypes is not valid for C
++" when compiling Cython files btw, a distutils bug afaik).
> >> 2) printf("%ld") - on windows this needs to sometimes be
> >> printf("%lld")
>
> > That's not only a problem on Windows; one should use the inttypes.h
> > macros (C99) or equivalent ones.
> > Note that "long long" is not ANSI C.
>
> But we do use long long all the time in Sage, so you're safe there.
Nice argument. Somebody else does (or did somewhen!), so I can...
In general the safest way would be to use typedefs for that (e.g.
int64), and macros for operations on them.
Even less of a problem if you *generate* C code (or mostly use C for
interfacing).
(Unfortunately long long==long on all 64-bit platforms I know
of. ;-) )
> >> 3) mpz_set_ui instead of setting to a limb (a limb is not necessarily
> >> an unsigned long on Windows)
>
> >> 4) pointer arithmetic (assuming a pointer fits into a long), use
> >> intptr_t (oh wait, you can't, that's c99 only)
(@Bill:) Define your own if you're not in C99...
-Leif
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
