Anyone want to write the reference section docs for the pointer operators (* - dereference) and (& - address of) ? Show your C chops, gain fame and impress those future employers and girlfriends/boyfriends, well, maybe employers.
These don't need to be very detailed, maybe just a couple of super-simple examples and a link to some other, longer explanations.
Geez... do we have to write an entire C tutorial? Is there some particular use of pointers that's especially applicable to the arduino environment?
(and has anyone looked for an online C tutorial whose author might be interested in contributing to the arduino project?)
My idea is that a beginner would at least be able to decode symbols in the code they find, and understand basic comments (helping them to look elsewhere.) I definitely don't think we need a whole C tutorial.
The two cases that come to mind are array and string manipulation - for things like LCD's and LED displays, and passing parameters to functions by reference - say you've got two sets sensors with two sets of similar variables and want to manipulate each one in identical ways.
The docs are going in extended reference - no one has to read this stuff that isn't looking for it.
The problem with generic C books is that they refer to a programming environment that varies quite a bit from Arduino - leading to confusion - in exactly the most confusing part of the game (trying to learn C). The idea is not to provide a tutorial but just a hint of how and why one might use these things.
I''m continually amused by the sophisticated C solutions posted by users in the forum, and the seeming resistance to documenting Arduino, C, AVR calls in the reference section. I'm just using my own experience here, and the comments of my students, in speculating that well organized, appropriate docs make things easier for both beginning and intermediate coders. For beginners anyway, seeing the C code with some familiar functions (e.g. Serial.println()) might make all the difference between trying more sophisticated code or giving up, writing more kludgy code, or getting frustrated.