As most of you know by now (I hope), the Arduino API is a mixture of C and C++ source file. Our approach to that has been that of Safe C, i.e. making sure that all the C source files also compile as C++ (but of course not vice versa). So far we have been using C++03 on the C++ side, as C++03 is readily available in all common compilers, even ancient ones like the one used in the Arduino IDE so far. Now, I have been trying to create a C++ Serial class that both would be fully Arduino API compatible and would be compile-time initialised so that the compiler is able to optimise it completely away; see https://github.com/Ell-i/Hackathon/wiki/ELLi-runtime-design#wiki-runtime-hardware-access for the background why. I did such a Serial class in one way in the old runtime, using C++03, but I was never happy with that particular approach. Among other things, in that approach I had to give up using the Stream class as a base class for Serial, thereby breaking the Arduino API compatibility slightly. Hence, as the Arduino folks have announced that the 1.5 IDE will move to gcc 4.8 on the ARM side, and as gcc 4.8 fully supports C++11, there is the new possibility of utilising the relaxed C++11 POD rules while defining the Serial class; see http://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data If I read those new rules correctly, it should be possible to make the Serial a POD class, or at least statically costructable, while still having Stream as a base class for Serial. In any case, even if that were to fail completely or partially, moving to C++11 would give us constexpr, which allows much more aggressive optimisation by the compiler in certain C++ constructs. Hence, given the move to gcc 4.8 that is completely C++11 compatible and our desire to use the compiler to do heavy compile-time optimisations, I think it would be a wise move to go to C++11 now, while there is still a minimal amount of C++ code in our new runtime. (For constexpr, see http://en.wikipedia.org/wiki/C%2B%2B11#constexpr_.E2.80.93_Generalized_constant_expressions ) Unfortunately, the Mac OS X native gcc is an ancient one, llvm-gcc based on GCC 4.2, and Apple has no intention to update it, ever. GCC 4.2 doesn't support C++11. On the other hand, as Mac OS X LLVM fully supports C++11, it looks like a good choice to switch from the llvm-gcc 4.2 to the latest native LLVM when compiling the emulator on Mac OS X. I have now done that, but this switching has a number of potentially nasty side effects. Firstly, moving from C++03 to C++11 and from llvm-gcc 4.2 to Apple LLVM 5.0 (LLVM 3.3svn) required me to do a largish number of small changes to many places in the runtime, as the latest Apple LLVM deprecates a number of old gcc quirks, some of which we foolishly relied on. Hence, there will be a largish commit pushed soon, and that may cause merge errors when you'll pull the commit, as it touches so many places, though lightly. Consider yourself warned. Secondly, the use of C++11 constructs means that the new Runtime no longer compiles with the present Arduino IDE 1.5, as it still has a too old version of gcc. To compile the new Runtime, you need a locally installed GCC (or LLVM) that is new enough to be able to handle C++11. Thirdly, for some obscure reason the new emulated code works badly with the Mac OS X incremental dynamic loading, necessitating the DYLD_BIND_AT_LAUNCH=1 environment variable to be set for dyld(1), lest the emulated code crashes foolishly while trying to dynamically load bzero/memset, called from the compiler's optimised code. Finally, as LLVM may not be natively available in Linux, this move makes the path of getting the emulator to work on Linux slightly longer than it was before. I'm sure we can make the emulator to work also with native GCC 4.8 (and even 4.7) on Linux, but as I don't Linux myself, someone else must take care of that at some point. And it may not be exactly trivial. Anyway, I'm now taking this bold step, and will push the commits related to it latest on Monday, unless someone yells loudly. --Pekka