On Jun 9, 2010, at 1:35 AM, David Kirkby wrote:
On 8 June 2010 21:14, Robert Bradshaw <rober...@math.washington.edu>
wrote:
On Jun 8, 2010, at 11:05 AM, leif wrote:
Though many compilers (and preprocessors) support this, I would
avoid
them unless the code *is* C99 or C++.
Why?
There are several good reasons - well, at least in my opinion good
reasons.
1) It encourages a culture of "I stick to standards most times, but I
vary in some occasions". That in general is what causes portability
issues.
I admit there is also the culture of "it works for me so it must be
ok", which is more serious.
Certainly the latter is more of a problem than the former.
2) Most compilers is not all compilers. Why stop someone using their
compiler?
Do any modern compilers not understand one-line comments?
3) By avoiding such constructs, it is possible to user stricter
switches on compilers, so avoiding not only C++ style comments, but
also other dubious things which will be even less portable.
OK, fair enough.
I would suggest that whatever method is used (personally given C99 is
an 11 year old standard, I think that should be ok), that the code is
also checked on the Sun Studio compiler, which can be downloaded for
both Linux and Solaris.
http://developers.sun.com/sunstudio/
That catches some serious errors which gcc misses and avoids
non-portable GNU-specific constructs, which are not portable to native
Unix compilers. The Unix native compilers in general give better
performance than gcc.
While this may have been true for the GCC 1.x and 2.x series, most
recent benchmarks I've ever seen are ambivalent at best, with
different people claiming different directions. Now I have seen backed
up claims that the (closed) Intel compilers are quite good, and Visual
Studio is blazing fast at C++.
Now, what really matters is how it works on stuff you use. If/when
Sage compiles with Sun Studio, then we could do some interesting
benchmarks.
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.
Yes, it is 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 /*
*/.
I don't find it sufficiently important to spend my time changing // to
/* */, but I do feel things like -ansi and -pedantic are useful.
Although you feel you have got better things to worry about, it is
that attitude that means many years have to be spent porting code from
one platform to another.
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.
C has stood the test of time far more than any other language. I
suspect people will be writing code in C, well after languages like
PHP, Python, ruby have all since been superseded by some other new
"hot" language. Many languages have in their time been the hot
language, but then fall into obscurity. I suspect Python will do too.
The fact Python 3 is not backwards compatible with python 2 has
already made that more likely.
I think C's longevity is due to its ubiquity and simplicity, but the
language itself has many fundamental flaws for most applications.
(Well, flaw here is a relative term--pointers and manual memory
management are ideal tools for writing drivers and other low level
code, but superfluous and error prone for many higher level
applications.)
Personally, I usually look at C as the new, portable assembly (though
JITs and VMs are competing in that space as well).
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
Why add in a step that generates non-portable code?
He was asking about writing a Python/C interface generator, so I
suggested using an existing one.
On that note, please, please file bugs for any non-portable (or even
non-ANSI) code that Cython generates. Though I have a more lax
attitude about human written code, I think machine generated code can
and should be as close to standards compliant as possible. It may also
be interesting to set up a Sun Studio compile in the Cython build farm.
- 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
