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. 2) Most compilers is not all compilers. Why stop someone using their compiler? 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. 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. > 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. > 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? Dave -- 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
