Quote:
|
Originally Posted by Mike Betts
I guess I'm just too conservative. I have worked with a lot of processors in a lot of environments in multiple languages. I never trust the compiler options in areas like these.
If you have ever spent a week of sleepless nights rewriting code to be explicit rather than implicit because the new compiler (or even version of the compiler) does not compile like the old one did, you would be as gun shy as me.
Other things I do not do:
1. Depend on variable promotion. I use explicit casts.
2. Depend on the parser to determine order of operations. I use parentheses (a lot).
3. Use library functions. I'd rather write my own.
And the list goes on... It is a work ethic which may cost me a little more time in front of the keyboard, but my code is much more portable across multiple platforms.
As far as speed and efficiency goes, I guess I'd be using assembler if the speed of initialization affected performance critically.
Bottom line...
If everyone took as much time and effort as you have to insure which linker and compiler options gave you reliable results, this thread, and my advice, would be moot.
Most people (especially those new to programming and in the heat of a robot build) do not. As such, my advise in the future will likely be the same as my advise in the past.
Regards,
|
Hi Mike,
Well, nobody that knows me has ever attributed conservitism to me... [;-)
Your discipline is commendable and your advice is good. I didn't mean to infer otherwise. I tend to like to get to know tools intimately and exploit them. But I understand about not becoming dependant on features that are likely to be unavailable in other environments, and that point's well taken.
In this case, I appreciate that the compiler, linker, and runtime guys made the effort to conform to the ANSI standard, and I'll make use of their work.
Best luck to your team, and may you not be haunted by the curse of un-initialized counters and wild pointers.
Bill