What should I know when making a library for the Arduino?

Question

It occurs to me that, beyond my current problem, I ought to ask, "What should I know when making a library for the Arduino?"

First, what I am doing:

I'm using Eclipse as my editor and writing code in C++. I have written a simple Arduino application that includes my header file and am working through errors.

First problem: how do I do a 'build clean'? I am seeing errors that I think I've fixed, almost as if the header file were cached. (Yes, quite likely I am doing something stupid [edit: I was], but I'd still like to know how to clean the library, and don't know where the object files are).

Secondly: what conventions should I be aware of? I haven't used the Arduino as much as I'd like, and it feels so good to be programming in C++, but I know the intent of the libraries is to keep things nice and simple for the users. Are there conventions for function names? Creating constants (it looks like the global namespace is polluted with #defines)? And so on.

Lastly, is there anything else I should know?

I should mention that I've looked at the Arduino Library Tutorial, which is good, but doesn't go very far. I've also peeked at some of the libraries that are installed on my system.

Answer 1

I'll take a stab. I haven't written code for Arduino, but I've done a lot of C and C++ programming. It would help if I actually saw your errors, but nonetheless.

The main thing you need to always remember when using C++ with C code is that your C++ code needs functions declared with "extern "C"" if you want C code to be able to link against the C++ code. The "extern "C"" is what tells the C++ compiler that I'm creating linkable code for C files or I'm using code from C files. So all your functions in the library API header should correlate with a function in the source file defined liked "extern "C" void dosomething()". If you're trying to use classes in C++, remember that C code can't call it, you'll need to create functions (extern "C") to access the object. Now, if your C code is compiled with a C++ compiler, then don't worry about "extern "C"".

If you want to call C code inside your C++ code, then you need to wrap the C header with a construct like this:

#ifdef ___cplusplus
extern "C" {
#endif

///all my C function declarations... yada yada

#ifdef __cplusplus
}  //end extern "C"
#endif

If you working in C++, don't use a lot a #defines unless you're creating compile-time flags like "DEBUG" or "VERSION2" to create special sets of code. Otherwise use "const int/char/float" for number defines for safe type checking. The compilers are usually smart enough to optimize these out, so they wind up in ROM/code space (depends though). Also, don't create MACROS, use inline functions. Also, don't always follow convention when programming if it's stupid such as using a lot of macros and number defines in C++. The same thing applies to C99 version of C, it has added things like inline functions and consts from C++. The industry realizes how much buggy code and hard to maintain code comes from overuse of the preprocessor language.

Eclipse usually stores the obj files in a directory under your project. If you're doing a "Debug" build, then it's located under the "Debug" folder under your project folder. If you're doing a "Release" build, then look under "Release", etc. Normally a clean build just works for me in Eclipse, so I don't know what's going wrong with your setup. I guess make sure you're not creating precompiled headers.