I trust you are not being flippant) but you are correct.
+ Portable from platform to platform (standardized language).
This is something the pro-C brigade always bring up, yet it's completely untrue - C seems no more portable than any other HLL (not even PC versions) - obviously it's more portable than assemblerbut that's about it.
Certainly as far as micro-controllers go, the different C compilers are extremely non-portable.
Well written C is the most portable language there is. What else language ports from microcontrollers to desktop computers and between different cpu architectures more easily? Can you think of one?
The number of available cross-compilers make it more portable than any other language. It is not a language feature, but a real world fact.there's nothing special about C that makes it more portable
But I notice you're only using a sub-set of the C language
The number of available cross-compilers make it more portable than any other language. It is not a language feature, but a real world fact.
What makes you think that? What is this subset.. or what part of C I'm not using?
And as we're in a PIC forum, none of the PIC C compilers seem to be very interchangeable at all.
You said you're only using the basic ANSI C features, which is only a sub-set of most compilers.
They do not need to be since they are all compilers for the same platform.. Just choose the "best" one and stick with it. I believe they all can compile standard ANSI C, if not, the compiler is crap.
That "ANSI C sub-set" happens to be the C language. Separation of plain and simple ANSI C code from platform specific code is the heart of good software design.
Crippling your coding to antique standards is probably poor software design, not good.
But now we seem to have moved from 'portable code' to 'seperating out portable and non-portable parts' - - like I said, it's no where near as 'portable' as C fans like to claim.
"A";'B'; print "A";'"B" and issues such as these. I did it two ways. The second was elegant and very fast.
It consisted of a set of options:
1) A pre-processor
2) A scanner
3) At this point things could be turned into tokens.
4) The pretty printer itself.
Creating "tokens" would have been so easy. It would not have been the traditional way of compiler writing. Yea, I took a class in it.
There is an old saying among managers: If you want to save your job fire the programmer that insists in programming in ASM. There are good reasons for that.
Today in many (most?) cases time to market is far more critical then code size.
Because higher level languages hide the processor the code is easier to read and maintain. That is not to say that knowing the processor is unimportant.
Structure and stronger data typing tends to reduce the bug rate.
But if you are a hobby type or your own boss, use what turns your crank! Toggle in hand written machine code from a front panel if it makes you happy.
Knowing a language is only one step in becoming a decent embedded programmer. Lets not compare embedded newbies to people who have worked in the field long term.
ASM efficiency however goes beyond embedded programming.
My issue is that I wish there were more embedded newbies. Sadly there isn't. Just script kiddies who can string a bit of Python together. These are what are being churned out into industry from our so called Higher Education system. Most are pretty useless.
Much the same with discrete electronics. Many can simulate something using Matlab but have never actually made anything. Again useless.
And efficiency isn't even usually considered as long as the machine can run it it doesn't matter how wasteful the programming is. Often times they'll simply raise the specs of the machine required to run it rather than try to improve the software.3v0 said:Today in many (most?) cases time to market is far more critical then code size.
And efficiency isn't even usually considered as long as the machine can run it it doesn't matter how wasteful the programming is. Often times they'll simply raise the specs of the machine required to run it rather than try to improve the software.
Bling is a C#-based library for easily programming images, animations, interactions, and visualizations on Microsoft's WPF/.NET. Bling is oriented towards design technologists, i.e., designers who sometimes program, to aid in the rapid prototyping of rich UI design ideas. Students, artists, researchers, and hobbyists will also find Bling useful as a tool for quickly expressing ideas or visualizations. Bling's APIs and constructs are optimized for the fast programming of throw away code as opposed to the careful programming of production code.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?