ASURO-Bibliothek in C++ ?
Die ASURO-Bibliothek ist ja in nettem C geschrieben und auch wirklich gut lesbar, wenn man die Kommentare entfernt. Da WinAVR auch einen C++-Compiler enthält, könnte man die ASURO-Bibliothek ebenfalls in C++ schreiben, also ohne diese hässlichen #define und Macros. Hat das schon jemand versucht oder darüber nachgedacht? Sicher nicht neu die Idee. :-k
Aus C:/WinAVR/doc/avr-libc/avr-libc-user-manual/FAQ.html#faq_cplusplus
Zitat:
Can I use C++ on the AVR?
Basically yes, C++ is supported (assuming your compiler has been configured and compiled to support it, of course). Source files ending in .cc, .cpp or .C will automatically cause the compiler frontend to invoke the C++ compiler. Alternatively, the C++ compiler could be explicitly called by the name avr-c++.
However, there's currently no support for libstdc++, the standard support library needed for a complete C++ implementation. This imposes a number of restrictions on the C++ programs that can be compiled. Among them are:
* Obviously, none of the C++ related standard functions, classes, and template classes are available.
* The operators new and delete are not implemented, attempting to use them will cause the linker to complain about undefined external references. (This could perhaps be fixed.)
* Some of the supplied include files are not C++ safe, i. e. they need to be wrapped into
extern "C" { . . . }
(This could certainly be fixed, too.)
* Exceptions are not supported. Since exceptions are enabled by default in the C++ frontend, they explicitly need to be turned off using -fno-exceptions in the compiler options. Failing this, the linker will complain about an undefined external reference to __gxx_personality_sj0.
Constructors and destructors are supported though, including global ones.
When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the -S compiler option) seems to be warranted.
