We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello all, I have been following the recent clashes between various participants (see the post "Compiling differences between C51 v7.03 and v8.06" or "introducing the smoked sardine complex" :) :) ). C was given, I think, a unjustified bash in that post. I wouldn't like to have been compelled to explicitly cast too often. Most potentially dangerous casts can be filtered out by a static code analyzer. Can you give an example of more strongly-typed languages than C that are used in embedded development?
Can you give an example of more strongly-typed languages than C that are used in embedded development?
That's a tough one. Strongly-types languages are usually also high-level, and those are used rarely in "small" embedded systems.
Java and Pascal would, for example, be somewhat more strongly typed than C.
Python (rarely used in small embedded systems, but useful on the PC side) would be strongly typed.
I have never used Pascal, but know there is/are Pascal compiler(s) for the '51.
The C vs Pascal discussion always center around the question "do you want 'freedom' or do you want the compiler to protect you against yourself"
Erik
I have programmed quite a lot in Pascal.
The feeling is: How much time do I have to spend to get past the compiler, i.e. how to fool the compiler enough so that I can do my job.
Some of my problems does come from Turbo Pascal, that didn't had variant-sized arrays, so the user had to either switch to the Turbo Pascal typeless pointer type or declare new arrays at the same location as an array of a different size.
I have never seen any problem that C has too weak type checking. The biggest problem for people is that pointers and arrays are almost identical in concept, and that this makes it almost hopeless to let the compiler (or runtime) perform out-of-bounds checking on array indices. This should not be a problem if people always keeps track of their buffer sizes and makes use of the correct functions for doing different things. Nothing wrong with strcpy(), sprintf() etc but strlen(), strncpy(), snprintf() do help a lot.
C was given, I think, a unjustified bash in that post.
I thought the proponents of 'make it up as you go along' terminology were the ones being bashed, not the programming language.
C++ is used, but I'm not sure how widely. I believe there is a C++ compiler (or possibly a C++ to C translator) available for the 8051.
I'm now bracing myself for the cries of 'You can't do that! Wrong language! Too big! Too bloated! Hello world needs a 64 bit CPU and 32 gig of RAM!' from all the usual experts who have never tried it.
I have never seen any problem that C has too weak type checking.
I agree. C simply requires the programmer to be competent with his tools.
C++ is used, but I'm not sure how widely. I believe there is a C++ compiler (or possibly a C++ to C translator) available for the 8051. Ceibo promotes their - whatever they call it - translator from C++ to Keil C.
http://www.ceibo.com
IAR has native C++ support. But the juicy parts are stripped since '51 architecture isn't exactly suited for some parts of the C++ language constructs and runtime library.
Yes, that is the fundamental philosophical difference between 'C' and Pascal:
'C' requires the programmer to be competent with his tools - it has a "You asked for it, You got it" paradigm. 'C' gives you a powerful weapon - it's up to you not to shoot yourself with it.
Pascal originated as a teaching language; it insists that you state your intentions absolutely explicitly at all times - the theory being that this should force you to think more carefully about precisely what your intentions really are...
Of course the risk is then that you end up not being able to shoot anything at all!
In what way do you think 'C' was "bashed", and in what way "unjustified"?
(not that I necessarily disagree - just not sure what you're specifically referring to)
Andy, all, I am a staunch believer that almost any programming language (except Cobol, maybe :) ), bestowed in the hands of a capable person, can get almost any job done! I don't have a problem with anybody bashing C, but other programming languages deserve a similar treatment (C++, for example, is much more dangerous to work with. classical example: transferring a pointer to a base class as a parameter to a function and treating it as an array! this is not defined). I thought that you were trying to say that certain problems can be solved better given a more strongly-typed tool. It's all a question of trade-off and capable hands, I think. Cactus Blip
Newer versions of C++ do have RTTI and more advanced cast operations to help a user that cares.
People who do not apply engineering will most probably fail with whatever tool they lay their hands on.
You can use FEM to simulate the stress on a mechanical structure. If the builder then decides to switch material, the FEM simulation will not help.
Still not clear exactly what you think was the "bash" against 'C'?
"I thought that you were trying to say that certain problems can be solved better given a more strongly-typed tool"
No, I don't think I would've said that!
I don't think it helps to solve the problem, but it can help to catch (potential) errors in the solution.
Whether there's a net benefit is, of course, the big question...
"I am a staunch believer that almost any programming language (except Cobol, maybe :) ), bestowed in the hands of a capable person, can get almost any job done!"
There's a well-known saying that a Real Programmer can write FORTRAN in any language...
;-)
There are groups of flat earth people on the 'Left' coast of the US that believe that Forth with objects is the only embedded typed language. If you don't like a data type just re-define it at run time ;-).
I had it with you! I'm going back to basics! That is, BASIC ;-)