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++.
> 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).
> 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.
> 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).
:-) Yes, reimplement all in pure lambda calculus.
-Leif
> That's my opinion anyway. But if you *really, really* need c99, then
> Sage currently does support packages which use it.
>
> Bill.
>
> On 8 June, 13:21, Sergey Bochkanov <sergey.bochka...@alglib.net>
> wrote:
>
> > Hello, SAGE developers!
>
> > I have a question about C standard which SAGE packages should conform
> > to. Is it C99? Plain ANSI C? "Modern ANSI C", i.e. ANSI C which
> > borrowed several features from C99?
>
> > I am working on Python<=>ALGLIB interface with intention to make it
> > usable from SAGE. It is Python interface to the pure C package,
> > created using CTYPES. I.e. C part of this interface is not C extension
> > to Python package, it is totally separate shared library which is used
> > through CTYPES foreign function library.
>
> > Python-C interface generator is ready, now I work in automatic
> > generation of C code. One week, I think, and it will be ready. But I
> > can't decide what C standard to choose.
>
> > As for me, I'd like to use ANSI C with several widely supported
> > features from C99 - inline functions, "//" comments, maybe something
> > else. But this thing should be compiled for SAGE, so I don't know can
> > I use something beyond ANSI C or not.
>
> > There is no information on this subject at the SAGE Developer Guide,
> > so I am asking this question here.
>
> > --
> > With best regards,
> > Sergey mailto:sergey.bochka...@alglib.net
--
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
