Is C a 'good' programming language?

[d000hg]

If you use C to do OO, you're pretty much admitting you chose the wrong tool IMO. Someone already extended C to support OO, I heard.

[VectraMan]

If you use C to do OO, you're pretty much admitting you chose the wrong tool IMO. Someone already extended C to support OO, I heard.

I can't understand why anybody would ever use C over C++. C++ can do everything that C can do, and there's no memory or performance overhead to any of the OO stuff where you don't use it.

[VectraMan]

Can you fit C++ code into 8k of rom?

Of course you can. The runtime is the same as C.

[DimPrawn]

Of course you can. The runtime is the same as C.

I thought the runtime for C++ was bigger as it uses the C runtime but adds to it?

[d000hg]

I'd expect C++ compilation to be bigger by default, but that you can fiddle with settings to get around it.
But as soon as you use C++ features you add in extra stuff I suppose.

Embedded is one case where C is the best choice... in many cases I think it's the only choice though as nobody has written a C++ compiler.

[TimberWolf]

I didn't realise C required a runtime. Doesn't the C compiler provide options to output nothing but (non-portable) native code, sans a monster runtime?

[VectraMan]

I thought the runtime for C++ was bigger as it uses the C runtime but adds to it?

"Runtime" is misleading, as that suggests .NET/Java like bloat. The C runtime is just the standard library stuff, like fopen, malloc etc., and I guess on an embedded system you might not even have that.

OOP won't add any extra stuff to the standard library, or to the size of the code for that matter, except where you use extra stuff. A virtual function has an overhead, but if you don't use them it won't matter and if you do use them the overhead would be much the same as implementing the same in C. Data hiding and non-virtual members are done by the compiler, nothing to do with the output.

There's no downside to C++ that I see, so you may as well write your C code the same but using the C++ compiler and have the benefit of being able to use OOP features.

[Trev16v]

Interesting thread. Embedded systems programming has been mentioned a few times and I'll chime in and agree that C definitely has its place in this field. My background is electronics hardware and from that I moved into using assembler and C for PICs and ARM processors. I suppose on limited embedded platforms like these, "assembler with tits on" is exactly what you want from a programming language, and nothing more! I'm used to the concept of managing memory resources yourself and selecting the libraries to match the processor variant and peripherals you're using. I enjoy using C, and don't believe that lack of OOP features make it 'bad'.

[Churchill]

All the C compilers I've used produce machine code (eventually)...

However, including printf is usually fatal, immediately using all the code space for the library support...

Get the address of the display buffer/port address of the display hardware and write the data there yourself.

[Churchill]

Indeed... and squirt the debugging stuff out of the nearest available serial port, if any...

Ah.

Dear dead days beyond recall...

Not really, my potential new employer (fingers crossed and numerous prayers to Deity of choice) designs and develops stuff on small micros so touch wood I'll be like a pig in sh!t if I get the gig... Three interviews with the same client in seven days and counting!!!

FFS!