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]
-
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
-
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
I programmed in C after years of C++. I found I was making much better use of typedefs than when I was a C programmer. They allow you to structure your C code much like classes in 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]
Not since '98 (God, has it really been 11 years?). C# and Java these days but it still *feels* a heck of a lot like C. I drive a car with ABS, airbags, anti-skidding programming and a whole host of other modern safety & comfort features. I wouldn't mind driving my first car, a '64 Rambler Classic, every now and again but I'd take my (relatively) modern vehicle for regular use anyday. That's how I feel about C#/Java viz a viz C.
-
LOL now you see why a programmer who cut his teeth on K&R C fears no other language in the world.
-
Yes! For embedded micro-controllers, communication and HW-related SW. We also program C++ (.Net, Borland), Java, C#. Our system and code are quite complex, involving several embedded platforms, PDA, several PC clients and servers, GUI, control, RT... you name it. Where we require portability, performance, and EASY MAINTENANCE - C is the #1 choice.
noams66
Noam Sigal wrote:
portability, performance, and EASY MAINTENANCE - C is the #1 choice.
I did not quite get sarcastic notes in your post. Maybe because C indeed produced as efficient code as C++ does. "Complex" system with C for easy maintenance ?! :omg:
-
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.
And what it has to do with OOP? You can indiscriminately allocate memery in C, as well as you can use static allocations with C++. Very misguided approach of old-fashion school, that's all
-
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 work in a company which produces a hybrid software.One is running on PC ( HMI side ) and one is running in an embedded computer which is completely in C and they work together in a distributed environment.I have the responsibility of the embedded side and after years of programming in VB6 and C# switched to C. I love it because 1.it is the ancestor of C++/C#/Java ( in both syntax and semantic )2.it is very elegant and can be challenging especially in an embedded system.
Behzad
-
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.
I have to agree with both of you guys. Yes, C++ can be used in most places that C is used. But, and a great big BUT indeed - it requires very careful planning, and deep knowledge of the specific compiler implementation. Especially where hard real-time is concerned. Few people really realize the simple elegance and easy maintenance possible with C*. Most OOP idioms really try to do that (make life simpler) - but actually fail, as the C++ code easily gets very complex. *see the remark to my original post, which is quite typical. Especially from newcomers to the business. :-) Noam TriDiNetworks
noams66