I agree of course that we should converse in a civil manner.
On Friday, February 3, 2012 10:39:45 PM UTC-8, Jonathan Bober wrote:
>
> In general, person X might use nonstandard GNU extension Y for many
> reasons,
>
In my experience, it usually boils down to
5) Person used language extension without being aware that it is
non-standard.
Often there is a good but highly non-obvious reason for why the cool
feature was not accepted in the standard. Case in point: nested C
functions. Pointing out the rationale of the standards committee in a
polite manner can work wonders.
"This code is only supported on 64-bit Intel/AMD platforms
> (life is too short to spend it worrying about overflowing a 32-bit
> integer)."
>
Newsflash: i386 has 64-bit ints as well. With a minimum of effort you can
write code that works independent of bitwidth and will reduce your own
maintenance and debugging overhead down the road because it makes your
assumptions explicit. This isn't the dark ages anymore where all you had
was an int and you could only pray that it is long enough.
void f(int j) {
> complex<double> x[j];
> [...]
> }
>
Your snippet is neither valid C99 nor valid C++. Since it seems like you
are just using C with std::complex<double>, why not make it proper C99
double complex? Then it would be standards-compliant and perhaps even
faster / less likely to trigger compiler bugs. Also, you are hopefully
aware of the size limitations of C99 VLAs.
Alternatively, if you want to use C++ then you have various template tricks
to make the size statically known. This not only gives you stack allocated
arrays but the compiler can also unroll loops at compile time. Also, you
are probably underestimating just how well-tuned std::vector is (did you
actually time it?).
Continuing: I might find a 5% improvement in my code through proper use of
> __builtin_expect on gcc. I know this is not portable, but should I really
> take
> the time to figure out how to write a proper macro that will work for one
> million different compilers, when am only going to use one?
>
spending the 2 minutes writing a proper macro / inline template will
improve the readability of the code and you'll end up ahead in the long run.
--
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
