[sdiy] how to learn C?

[Paul Cunningham]

word. its hard to learn at first -- especially if you aren't already versed in some kind of assembly language. ultimately everything reads or writes to a memory location whether it represents internal registers, RAM storage or external components connected by data and address lines. C/C++ is simply a paradigm for doing it that uses consistent methodology generating efficient machine code. 

the first thing that was frustrating to me when learning C was that it literally does nothing without  libraries or functions that access low-level I/O. nothing. on popular OSes, you get all kinds of APIs to manage memory and cpu resources, as well as access to drivers for peripherals... on embedded platforms you get practically nothing, so finding 3rd party examples and libraries is critical to the learning embedded programmer.

i really appreciate the arduino platform because it has a robust library that builds upon c++ without dragging you into the whole oo game, basically using oo for what it does best: encapsulation of complicated things. while c does a great job of setting bits and stuff, someone reading through sample code can quickly appreciate the readability of arduino calls compared to generic c code that reads like:

*((unsigned char *) myioPtr) &= 0x40; // turn off the LED (huh?)

that said -- new c programmers NEED to understand pointers, pointer arithmetic, and dereferencing if they are going to be able to write their own low-level functions. on top of that you will need to intimately understand how your code gets bootstrapped, and how it needs to behave during interrupts.

its a lot at first, but i think the arduino does an awesome job of hiding most of that for noobs. ultimately, anything you write for arduino can be written in native c for atmel chips without too much exrtra drama... but its exciting to get an arduino up and running in just a few minutes after building it! ha now you can just order one prebuilt... how easy can they possibly make it for you?

also: getting embedded code to work is harder than getting it to not work. just like synthesizers, there are millions of ways to get absolutely no sound at all. through debugging you will quickly learn all the low-level stuff you haven't already learned! ;)

oh one more thing, if you use c++, you will probably be better off avoiding constructors and deconstructors unless you have a really good reason. setting up an .init() method is a lot more straight-forward and doesn't immediately put you in situations where a constructor doesn't do what you think it should. and as jason mentioned, constructors probably won't be called for static classes (without a c++ runtime library). -pc

On Jan 8, 2011, at 6:51 PM, Veronica Merryfield <veronica.merryfield at shaw.ca> wrote:

> 
> 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
> 
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>