[chbot] C vs C++ and embedded

Tue Jan 6 23:59:39 GMT 2009

Having used C and C++ in many projects, I am firmly in the C camp.

C++ provides a whole lot of language features which are very powerful but can 
get you into a lot of trouble too.

C++ will just about always add significant overheads in terms of both CPU and 
memory usage. C++ also tends to thrash memory allocators which will often be 
quite poor in smaller embedded systems.

C++ can hide a lot of bugs too for example, consider:

a = b;

In C that can only do a very limited number of things:
* An assignment, maybe with a cast.
* A copy (if a and b are structures).

In C++ that could generate a vast raft of execution. I have seen cases where 
that would generate 28 constructor calls, followed by a whole lot of 
destructor calls.

For me, the most illuminating project was a 2 year telecommunications project 
I worked on in Auckland. Programmers tried to use all the "cool" C++ features 
and ended up spending more time working out subtle problems due to the way 
they used C++ than actually addressing the problem. C would have been far 
more productive.

There is nothing worse than spending a lot of frustration trying to debug a 
problem only to find that the compiler has "helpfully" hidden what is going 
on. C leaves things in plain view making it easier to debug.

I can't see why one would want to use C++ as a way to use n LCDs when you can 
achieve the same in C.

The major useful feature of C++ is being able to apply a single interface to 
different object types by way of abstract classes. That is readily achieved 
in C by the use of function pointers (which is how most operating systems 
handle file systems, device drivers and the like). That is essentially what 
C++ does anyway, just doing it manually in C means you don't get all the 
other C++ side effects.

My impression on the C vs assembler debate is that as you move to more 
powerful CPUS, particularly RISC CPUs, there is seldom much, if any, 
advantage in using assembler (apart from the C start up code). A C compiler 
can typically do far better optimisation over the use of many registers than 
a programmer can do. Sure, a programmer **can** do a better job of optimising 
a few lines, but that's not realistic on a multi-kilobyte program. C 
typically does a very poor job on most small micros with AVR being an 
exception because AVR was designed from the ground up for use wth C.

My toolset of choice is ARM + C. One of the main reasons I like ARM is so 
widely used, from small USD1 micros to the powerful multi-core CPUS that 
power all sorts of mobile and networking devices. There is no other 
architecture that has such a wide range. The gcc toolchain for ARM is free 
and very good and you can even make yourself a JTAG debugger for ARM for less 
than $10.  That same gcc toolchain is used in all sorts of environments 
including cell phones etc.

If I am power/size constrained then I'll use  AVR + C.  Unfortunately the 
debugging protocols etc are under wraps which means that there are no cheap 
debugging tools (though the other dev tools are free).

-- Charles

On Thursday 01 January 2009 11:36:48 John Tiler wrote:
> AVR/C for me. I've toyed with the idea of C++ too, because you can setup
> 'devices' say an LCD screen and have the expandability to have 'n' LCDs, or
> as much as memory allows.
>
> I did actually convert half my 'library' to C++ to see what it was like,
> and using AVR-GCC it took up an extra 20% say? as opposed to using
> stuctures. I guess if it used more memory it would run slower (more code to
> exec) and the actual time saved was not really worth that extra memory.
>
> Cheers,
>
> John
>
>
>
> From: mikael.stewart at gmail.comTo: chchrobotics at lists.linuxnut.co.nzDate:
> Wed, 31 Dec 2008 13:35:01 +1300Subject: Re: [chbot] C vs C++ and embedded
>
> Until recently I was very much hooked on Atmels AVR series microcontrollers
> and using WinAVR (Package containing GNU-GCC C compiler, Programmers
> Notepad IDE and documentation), and also a linux port of GNU-GCC while
> under UBUNTU/Debian. I liked the idea of not having to spend a ridiculous
> amount of money on hardware programmers or software - I was a student at
> the time! There is also a strong support base for AVR stuff on the 'net
> with lots of sample code around and since I'm the type that learns by
> example and not by long winded literature, this was very important to me.
>
> Just recently I've switched to Microchip dsPIC 30F and 33F range of
> microcontrollers for my projects. The development tools might cost more but
> there are some major hardware advantages that suit my applications. I
> generally use the Microchip C30 C compiler as it is so well optimized but
> will still use inline assembly for certain things e.g. a bit-banged
> proprietary 2-wire comms routine because I cringe at the thought of how
> using C might slow this down! As they say, engineering is an art of
> compromise...
>
> For the record, I only ever used assembly language when messing around with
> the 68hc11 microcontroller some 6-7 years ago. I'm still getting used to
> the dsPIC architecture but will probably be coding a bit more assembly in
> the future. Also, I've never touched C++ for microcontroller programming..
> I can think of a few cases where it would be handy, but C structures,
> unions and bitfields are usually good enough for what I do...
>
> Cheers,
> Mikael
>
>
>
> ----- Original Message -----
> From: Chris Hellyar
> To: Christchurch Robotics
> Sent: Wednesday, December 31, 2008 11:16 AM
> Subject: Re: [chbot] C vs C++ and embedded
> That makes interesting reading, coming from someone who has avoided OOP
> programming for ages, and only just got dragged in, kicking and screaming
> in the last year or so.I'm a die-hard assembly fan for embedded stuff,
> which probably makes me a dinosaur.  I suspect if it was still a part of my
> income I'd have switched to C long ago though.  I find it's the thrill of
> the chase with assembly which makes it interesting, but it also means it
> takes 5x as long to get the same result. :-).Case in point would be my
> current modbus project.  There are some good open source C code bases for
> modbus RTU on various platforms, but I'm coding from scratch in assembler
> for PIC 'cause I can'.  200+ hours of work and it's working well with a
> bunch of standard test tools, but in C I think it would have been more like
> 30 hours work.Which leads me to a straw-poll question...  What are people
> using as their tool set of choice for robots/gadgets?  What
> processor/language?  I'm 1 vote for PIC/asm. :-)Cheers, Me.On Wed,
> 2008-12-31 at 09:56 +1300, Richard Jones wrote: After the last meeting Paul
> was discussing with me the merits of using 'C' structures and C vs C++.
> This article might prove interesting to anyone interested in the tradeoffs
> between C and C++ for embedded applications like robotics:
> http://www.embedded.com/98/9802fe3.htm
>
> Richard
>
>
> _______________________________________________
> Chchrobotics mailing list, web site: http://kiwibots.org
> Chchrobotics at lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/chchrobotics
>
>
>
>
>
> _______________________________________________Chchrobotics mailing list,
> web site:
> http://kiwibots.orgChchrobotics@lists.linuxnut.co.nzhttp://lists.ourshack.c
>om/mailman/listinfo/chchrobotics
> _________________________________________________________________
> It’s the same Hotmail®. If by “same” you mean up to 70% faster.
> http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_
>122008