Do you C?
-
> Work with really critical systems, such as avionics, does not allow you to use object oriented programming. So C and ADA are a must. Why on earth not?
Paul Sanders http://www.alpinesoft.co.uk
There is a norm called DO 178-B that says so. OOP is not safe enough to work unless you be extremely cautious about it, and very extremely cautious. So to prevent errors and, therefore, fatal accidents, OOP is forbidden to this date. A new review of the norm, the DO 178-C, is said to permit OOP under extreme controlled conditions. So, when you need to prove that your SW is bug-free, you just avoid at all costs to use OOP. Besides not using OOP, it is becoming more and more recommended the use of formal methods to help the proof of bug-free SW.
-
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
Yes, of course. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
I don't see C and Assembly being replaced in the embedded world too soon. Nobody I work with likes the idea. We tried C++ here, built a few overpriced and unmaintainable products and dropped it. And if I recall the most recent survey in Embedded Systems correctly, C++ adoption is on the decline in other places that do embedded work too. The C++ that we still do is for tools we develop and cutomer products that run on PCs like print clients.
-
> Work with really critical systems, such as avionics, does not allow you to use object oriented programming. So C and ADA are a must. Why on earth not?
Paul Sanders http://www.alpinesoft.co.uk
Alot of it has to do with that fact that dynamic memory allocation is dangerous in an embedded system. When you can't grab a new chunk of memory you can't just pop up a window, tell the user and let the program exit. If that happens in a critical system spacecraft will crash, missles hit friendly targets, or trains run through control signals. In critical systems, static memory allocation is preferred.
-
Alot of it has to do with that fact that dynamic memory allocation is dangerous in an embedded system. When you can't grab a new chunk of memory you can't just pop up a window, tell the user and let the program exit. If that happens in a critical system spacecraft will crash, missles hit friendly targets, or trains run through control signals. In critical systems, static memory allocation is preferred.
Yes, I can see the sense of that, although I would have thought that embedded systems built on modern hardware (and I know that not all are) would have ample memory. Seems to me actually that there's an argument here for a language like C# (or Java), with garbage collection and no 'free' function, as the chances of a potentially fatal memory leak are reduced. Hard to provide realtime guarantees with such a language though since GC can happen any old time.
Paul Sanders http://www.alpinesoft.co.uk
-
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
I don't see C and Assembly being replaced in the embedded world too soon. Nobody I work with likes the idea. We tried C++ here, built a few overpriced and unmaintainable products and dropped it. And if I recall the most recent survey in Embedded Systems correctly, C++ adoption is on the decline in other places that do embedded work too. The C++ that we still do is for tools we develop and cutomer products that run on PCs like print clients.
tom1443 wrote:
We tried C++ here, built a few overpriced and unmaintainable products and dropped it.
To successfully switch from C to C++, you absolutely must understand and properly use OOP. At least for the core infrastructure at a minimum. Otherwise you end up with overpriced and unmaintable products as you get all the problems that come with structured design AND OO design if you do not. Don't blame the language for lack of skill on the developers part. There is absolutely no reason that C++ can't be successfully used in an embedded system short of having a lack of development tools for the particular embedded environment. There are just some extra details that an embedded developer needs to be concerned about (in particular memory management). C++ has been used on many embedded systems requiring the 5 9's availability level. With that said, there are some applications that are just more suited to structured development where C programming has a role, like drivers and algorithms.
-
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
Yes, I can see the sense of that, although I would have thought that embedded systems built on modern hardware (and I know that not all are) would have ample memory. Seems to me actually that there's an argument here for a language like C# (or Java), with garbage collection and no 'free' function, as the chances of a potentially fatal memory leak are reduced. Hard to provide realtime guarantees with such a language though since GC can happen any old time.
Paul Sanders http://www.alpinesoft.co.uk
Besides that, doing "Modified Condition/Decision Coverage(MC/DC)" is already a pain in the ass with structured programming, imagine doing it in OOP. Stack overflow is also hard to guarantee in OOP.
Paul Sanders (AlpineSoft) wrote:
Yes, I can see the sense of that, although I would have thought that embedded systems built on modern hardware (and I know that not all are) would have ample memory. Seems to me actually that there's an argument here for a language like C# (or Java), with garbage collection and no 'free' function, as the chances of a potentially fatal memory leak are reduced. Hard to provide realtime guarantees with such a language though since GC can happen any old time. Paul Sanders http://www.alpinesoft.co.uk
-
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
propaganda from the Java and C# peeps who were too stupid to understand pointers. :cool:
David
etkins wrote:
propaganda from the Java and C# peeps who were too stupid to understand pointers. Cool
Those are almost the exact same words my current boss said to me. :laugh:
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
Yes, I can see the sense of that, although I would have thought that embedded systems built on modern hardware (and I know that not all are) would have ample memory. Seems to me actually that there's an argument here for a language like C# (or Java), with garbage collection and no 'free' function, as the chances of a potentially fatal memory leak are reduced. Hard to provide realtime guarantees with such a language though since GC can happen any old time.
Paul Sanders http://www.alpinesoft.co.uk
Paul Sanders (AlpineSoft) wrote:
(and I know that not all are)
You're right. Some systems still have very tight memory requirements. In some cases, cost can still be a determining factor, when you need to cram so much on very tight devices with many features.
-
propaganda from the Java and C# peeps who were too stupid to understand pointers. :cool:
David
Yeah. So, who the first started this urban legend about pointers? No, pointers are not dirty...
-
Apparently not anymore. I tried to help on a piece of open source software that I use and that is written in C. Boy for a C++ programmer that is painful. I mean no classes, no stl, and don't get me started about strings...
John
LOL now you see why a programmer who cut his teeth on K&R C fears no other language in the world.
-
Not anymore, unless there's a very good reason. I just find it far too limiting. :doh:
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Anna-Jayne Metcalfe wrote:
Not anymore, unless there's a very good reason. I just find it far too limiting.
Indeed it is...that is why so many packages were built to enhance C's usability. The most famous and ubiquitous of these, of course, is C++, which began its life as a preprocessor that produced C code from C++ input. C as an intermediate language is still quite useful, and this is due to the same simplicity that makes it labor-intensive for large projects.
-
Machaira wrote:
For general application development there's no reason to use C (or C++). Long live C#!
It's for similar reasons that (long ago, back in the dim mists of the '90s) I recommended to an entrepeneur that he switch to Visual Basic or Access for future efforts - my exact reason was that "the programmers are cheaper and more easily disposable." However, C yields optimizations more powerful than anything short of assembly language, and has always been the choice where the highest performance and reliability have been required as well as readiblity and maintainability.
-
Yeah. So, who the first started this urban legend about pointers? No, pointers are not dirty...
-
Long live C: http://www.theregister.co.uk/2009/01/21/open_source_projects_08/[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
OOh the good times. I used to write C/C++ code for unix-like systems (it was a wonderful 6 years). But now I work in another company writing code for J2EE. I really miss pointers and dynamic memory :D, I mean it! :D
"An expert is a person that has failed in every possible way in a specific field" - Neils Bohr