15

Following up on this comment from the question Writing firmware: assembly or high level?:

When compiling C++ code for the Arduino platform, can you use virtual functions, exceptions, etc? Or would you want to (have to) use a subset of C++ (as described in the comment)?

Any other caveats when programming for the Arduino platform?

Community
  • 1
  • 1
cbrulak
  • 15,436
  • 20
  • 61
  • 101

6 Answers6

14

The Arduino environment uses the AVR version of the GCC toolchain. The code is compiled as C++, so you can use classes. Virtual functions are possible; the vtables will be stored in the .data section and have the correct addresses. In fact, the Print base class uses virtual functions to adapt the various "print" methods to the different output types.

Exceptions are not supported because of code space reasons. The Arduino environment passes "-fno-exceptions" to the compiler command line. See the source for verification of this.

Templates are supported. For example, this no-cost stream insertion operator technique works fine using a simple template and inline operator.

Mooing Duck
  • 64,318
  • 19
  • 100
  • 158
Ben Combee
  • 16,831
  • 6
  • 41
  • 42
11

The Arduino software uses avr-gcc to compile sketches. The following limitations were sourced from the avrlibc FAQ (Can I use C++ on the AVR?):

Supported

  • Virtual functions
  • Constructors and destructors (including global ones)

Not supported

  • C++ standard functions, classes, and template classes (but see this port of uClibc++ for Arduino)
  • operators new and delete (attempting to use them will cause the linker to complain about undefined external references). This means that objects can only be created on the stack. If dynamic memory allocation is required it must be implemented using malloc() and free() of C types
  • Exceptions. Since exceptions are enabled by default in the C++ frontend, they explicitly need to be turned off using -fno-exceptions in the compiler options. This is done automatically by the Arduino IDE when it launches avr-gcc

Other issues

  • Some of the supplied include files are not C++ safe, i.e. they need to be wrapped with
    extern "C" { . . . }
Matthew Murdoch
  • 30,874
  • 30
  • 96
  • 127
  • Do you have a source for the "new" operator not being supported? I use it in a sketch and it works just fine and compiles without any warning. – ChrisR Jul 18 '13 at 21:48
  • 1
    @ChrisR Interesting. I've referenced the avrlibc FAQ linked at the top of my answer. That FAQ suggests that the `new` limitation could perhaps be fixed so maybe it has been and the FAQ is now out of date? – Matthew Murdoch Jul 19 '13 at 09:17
  • I would guess the FAQ is out of date. There's an Arduino tutorial on how to use classes for libraries ( http://arduino.cc/en/Hacking/LibraryTutorial ) and I'm using abstract classes and virtual functions in my current sketch. – ChrisR Jul 21 '13 at 21:07
  • @ChrisR Classes have always been OK as long as instances were created globally or on the stack (i.e. not on the heap using `new` - which is what the LibraryTutorial does). And the referenced FAQ says that virtual functions are OK too. – Matthew Murdoch Jul 22 '13 at 09:18
  • 3
    Outdated answer, current Arduino supports new/delete, templates, C++ classes. – Pointer Null Nov 14 '14 at 09:43
3

The usability of a features is not limited by the platform but rather the compiler that you are using.

I would check your compiler documentation on what language features are supported.

Martin York
  • 257,169
  • 86
  • 333
  • 562
  • 1
    Not quite...constrained hardware has a major role here in deciding if exceptions should be supported. – Sandeep Datta Sep 02 '09 at 19:04
  • 1
    It is not a constraint of the hardware. It is a constrainted imposed on the compiler because we think it best not to overload the hardware (the hardware could theoritically support it but we dont want to use the required resources to do so). – Martin York Sep 02 '09 at 22:16
  • Any constraints on the compiler are likely to impose further constraints on the programs being compiled. The hardware could theoretically support it but only as long as your own resource demands do not exceed a certain limit. Due to the nature of the problem this limit is quite unstable (changes with your program complexity/requirements) hence its not prudent to switch exceptions ON/OFF based on this (will cause major code churn). Evidently there exists some hardware X which cannot even support basic exception handling on its own making your "constraint on compiler" argument moot. – Sandeep Datta Sep 06 '09 at 05:59
  • 1
    You are missing the point. This is not a hardware constraint it is a constrain imposed by the compiler. Also do you have a reference to such hardware that can not support exceptions? – Martin York Sep 06 '09 at 07:01
  • I am not trying to be difficult but I would really like to understand how this is a compiler problem. All I am saying is, is there a reason why the compiler is constrained in the first place? Is it not because the hardware can barely cope with the application logic without exceptions and adding exceptions is just going to kill it (in all probability)? – Sandeep Datta Sep 06 '09 at 18:12
  • I hate to dredge this one up, but is there anything "special" about exceptions. Is there special hardware features required to support exceptions? For instance, if I hacked the arduino environment to not pass the -fnoexceptions flag, are there any hardware requisites (excluding resources like memory size, etc) that my board could potentially lack? Or are exceptions intrinsic to the machine code? – aaaidan Mar 22 '12 at 09:03
  • @aaaidan: Nope, The arduino environment could theoretically handle exceptions, but programs would take _significantly_ more space. (2x or 3x?) – Mooing Duck Apr 10 '12 at 19:38
  • Any idea how to enable them? http://stackoverflow.com/questions/10095591/enable-exceptions-in-the-arduino-environment – aaaidan Apr 10 '12 at 20:47
2

Comeau computing has a C++ to C compiler which supports all C++ features. Not just virtual functions, or exceptions, but also export. You would need to call Comeau to get it to target the Arduino language, but should be not too hard.

MSalters
  • 173,980
  • 10
  • 155
  • 350
1

The documentation says:

The Arduino language is based on C/C++ and supports all standard C constructs and some C++ features.

It doesn't say anything about virtual functions that I can find.

I tried a simple program and it compiles fine. I haven't tested it on Arduino hardware though.

EDIT: I also haven't tested exceptions.

Mark James
  • 661
  • 4
  • 5
1

I used g++ with this Makefile and started with this code. C++ wastes some space. But protothreads are too cool not to use.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Flinkman
  • 17,732
  • 8
  • 32
  • 53