On Jun 8, 2010, at 11:05 AM, leif wrote:
On 8 Jun., 19:25, Bill Hart <goodwillh...@googlemail.com> wrote:
Flint for example, uses C99. However, use of C99 has caused problems
for porting to Windows.
Windows... ;-)
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?
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.
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 /* */.
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.
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)
Actually, best to not use C if you want it to compile on anything. C
is broken. (Partly joking).
But only partly :) I have the same opinion.
Back to your original question, you're talking about using/creating a
Python C interface generator. In this case, you may want to just
consider using Cython?
- Robert
--
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
