Gerhard Wesp wrote: > - the use of static is deprecated for module-local objects, anonymous > namespaces should be used instead.
Oh dear. Mild flame time. (Entirely irrelevant to the algorithms in the new code, so uninterested folks can stop reading now. :) I'm not big on C++ pedantry, obviously. Good code can be written in C. It should, IMHO, remain good code when it appears in a C++ program. My memory of anonymous namespaces is that they aren't supported by all of our compilers. But I'd be fine with using them if someone else does the integration work. :) Namespaces are great for larger modules (c.f. YASim). But this is a function that's local to a single source file; that's what static was designed for... > Also, don't pass doubles by value but by const& instead. This > leaves the compiler more freedom for optimization. Eeek. Sorry, this bit is C++ hell. You pass arguments as arguments. Which of these looks "correct" to you: void func(double arg); void func(const double& arg); One of them exhibits a clean syntax that means exactly what it has meant for 30+ years. The other looks... odd. You often pass a reference so you can mutate the argument, but this one is const. Sometimes you pass a const reference to avoid passing a large object on the stack, but this one lives in the FPU... Passing a reference to a const object that lives in a register? What does that *mean*? Apparently, you want it to mean "runs fast", and furthermore think that's a good thing. :) Seriously: if this is a problem, it's a problem with the ABI calling conventions* and should be solved with compiler switches, not language syntax. Windows tried this with the PASCAL/WINAPI nonsense long ago, and is still living with the troubles. These conventions *are* faster. No one cares; they're too much trouble to deal with. Ditto for the const reference silliness, IMHO. If it's a performance issue, then there will be numbers to justify a change. If there aren't numbers, surely the cleaner solution should be chosen, no? Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
