[sdiy] how to learn C?

[Veronica Merryfield]

On 2011-01-08, at 1:20 PM, Paul Cunningham wrote:

> c++ is fine for embedded as long as you aren't trying to use the c++ runtime library (dynamic memory allocation, new, delete, virtual methods, streams, etal)... c and c++ is compiled the same way when you stick to the c syntax, and c++ supports a few syntax niceities that make allocating local variables more convenient. if u got it u can use it. and -- u can even use classes as long as they are declared in fixed memory or on the stack (again no virtual methods, new, or delete). of course memory and stack space are in limited supply on embedded systems so don't go crazy. avoid recursive algorithms.
> 
> the original c++ is a preprocessor called cfront which translates c++ to c and then compiles with regular cc compiler. it made function names longer to encode the class data, but this extra metainformation is discarded by the linker. modern compilers are much better and very efficient -- disassemble your binary if you need to compare. also c can be explicitly within in c++ if there is a good reason for doing that. and most c/c++ compilers support inline assembly if they can't get the job done at a higher level. -pc
> 
> On Jan 8, 2011, at 3:37 PM, Matthew Smith <matt at smiffytech.com> wrote:
> 
>> As regards C++, not if you're doing embedded. As someone just pointed
>> out, excellent way to make bloat

What ever language one uses to implement an embedded system, one really should know what the compiler is doing. More complex high level languages produce code that needs more effort to understand. In the case of C++, one needs to know what happens with constructors, destructors, calling mechanisms and so on. 

A ways back I was using GCC in an embedded 386 system and found that the constructor mechanics relied on code stubs in dynamic memory but did not provide the code to initiate them. I think there was an assumption that 386 equated to PC. I should have known better having had experience previously with 68K compilers doing odd stuff.

I now check what compilers do.

One can use OO techniques in C and use to do this often in the early days of C++ when compilers were flakey and Cfront was not always available for a platform. It is comparatively simple to replicate classes, constructors and destructors. One can even implement a virtual mechanism. It takes some coding discipline but works just fine. 

There are certain robustness issues when using C++ but they exist in other languages too. For instance, many will perform actions in constructors that they thin nothing of, especially if from an exception catching background. Constructors can not return values and hence can not return errors. The solution is to move to a two part construction technique, always calling an init routine. There are many other issues that are C++ specific when using it in an embedded environment, but it does boil down to knowing what your tools are doing.

Vrnc