Do you C?

[RTS WORK]

Did a code review of some Open Source command line encryption algorithm written in C. Ended up re-building it to make sure the binary = source. Been like 20 years but it's all good.

[JudyL_MD]

But of course since among other things, I work on drivers Judy

Be wary of strong drink. It can make you shoot at tax collectors - and miss. Lazarus Long, "Time Enough For Love" by Robert A. Heinlein

[_dunk_]

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.

[CDMTJX]

Stuff here at work in in a variety of languages, including C. I prefer objects; C++, C#, or Java. char* string handling is possible, but painful!

[etkid84]

propaganda from the Java and C# peeps who were too stupid to understand pointers. :cool:

David

[Mirds]

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

[NathalieD]

I use: C for kernel code C++ for system programming in user-more and when performance is important C# for the rest

[Hans Dietrich]

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]

[Pierre Leclercq]

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.

[Pierre Leclercq]

Yeah. So, who the first started this urban legend about pointers? No, pointers are not dirty...

[cpkilekofp]

LOL now you see why a programmer who cut his teeth on K&R C fears no other language in the world.

[cpkilekofp]

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.

[cpkilekofp]

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.

[etkid84]

not a problem here

David

[Kuraru77]

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

[Cyrilix]

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.

[cpkilekofp]

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

[Alan Balkany]

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++.

[Mark E Lawrence]

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.

[angheloko]

True true. Only in C was I ever truly challenged - the overflows, string, stacks, floating point errors...The deepest, most mystified and intriguing language, IMO. Can make and break you all in one day. It's like the dark mystic arts of programming.