Do you C?
-
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
-
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.
I don't know about you, but I think C# code is generally much more readable than C/C++ code. It may be in the naming convention or in the huge mass of standard built-in .NET libraries that C/C++ simply doesn't have, but the reason why I tend to prefer coding in C# is because it in so many ways captures parts of C/C++ that are not elegant, and makes them elegant with either some form of syntactic sugar, or in some kind of added functionality that C/C++ does not have.
-
I don't know about you, but I think C# code is generally much more readable than C/C++ code. It may be in the naming convention or in the huge mass of standard built-in .NET libraries that C/C++ simply doesn't have, but the reason why I tend to prefer coding in C# is because it in so many ways captures parts of C/C++ that are not elegant, and makes them elegant with either some form of syntactic sugar, or in some kind of added functionality that C/C++ does not have.
Cyrilix wrote:
I don't know about you, but I think C# code is generally much more readable than C/C++ code. It may be in the naming convention or in the huge mass of standard built-in .NET libraries that C/C++ simply doesn't have, but the reason why I tend to prefer coding in C# is because it in so many ways captures parts of C/C++ that are not elegant, and makes them elegant with either some form of syntactic sugar, or in some kind of added functionality that C/C++ does not have.
Yes, to all that...and it's easier to code safely in C# than in C. Please believe me, I intend no insult by this, but C# programmers are cheaper and more easily disposable than C programmers, as well. C# is an application programming language that uses C-like syntax; C is a system programming language that is occasionally used for application programming. With C#, you are ALWAYS programming in the sandbox of the .NET JIT compiler, the next best thing to an interpreter; with C (except in Managed C++ in .NET) you are always programming directly against the hardware of the machine, with the single safety net of the OS interface to the hardware memory manager to protect you from writing outside the memory your process owns. I didn't even have that safety net in my formative years - I programmed in C on top of MSDOS, which had no interface to the nonexistent hardware memory management of the early PC processors. Let me tell you, that was a hard environment to debug, especially when you were developing multi-megabyte programs that had to be loaded a piece at a time (virtual memory for PCs was a hazy hope for the future) and errors didn't necessarily make themselves evident until long after the initial effect. This is not unlike the embedded development environment even now, and it takes a much sharper sort of analysis and troubleshooting skill than the usual application programmer can deliver. After years of working in the relative safety of VB and .NET (heck, even OS/2 spoiled me by letting me know immediately when I was accessing memory I didn't own), I doubt I could match that skill level now without practice, and I can see the difference that experience gave me in terms of my skills relative to most of the programmers I've ever worked with. Nowadays, I look at application programming in C just as I looked at a friend's project to build a multiprocessor computer using a 6502 processor as the central controller: interesting, technically challenging, but is the work y