Is there any disadvantage in writing classes?

Plain C seems to be the current industry standard for embedded systems. Not sure why.

Is there any reason not to create c++ style classes in Arduino?

No.

There are some caveats...

  • No structured exceptions
  • Be wary of dynamic allocation (new / delete)
  • Go easy on virtual methods

mikb55:
Is there any reason not to create c++ style classes in Arduino?

Good Lord! I hope not!

-jim lee

This is an interesting point and I can kind of see why this may be the case ... I just recently read a little about C++ object orientation (coming from directions like Java and Python) to set up a little library for my recurring task of controlling lights via MQTT, meaning: Monitor MQTT channel, act on commands, post status.
I put most of the MQTT stuff in an abstract base class and then derives child classes that only additionally implement how the light is controlled (PWM to a MOSFET, I2C to a PWM controller board ...)
The way I found uses virtual methods in the parent class for that and then an implementation int the child classes. Is there better way to go on the MCU? Should I avoid polymorphism altogether at the expense of duplicated code? Are there any rules of thumb regarding "going easy"?

Oh, and this...

  • No pure virtual methods.

ElCaron:
Is there better way to go on the MCU?

No. If it's virtual it's virtual.

Should I avoid polymorphism altogether at the expense of duplicated code?

I would not.

Unless I was running out of SRAM. But, unless there was a compelling reason not to, in the event of running out of SRAM I would move towards a bigger processor.

Are there any rules of thumb regarding "going easy"?

If the method does not require being virtual then do not make it virtual. Pure abstract classes are very likely a waste.

Make fewer "fatter" classes.

Having said all that, I have found Arduino library programmers tend to use polymorphism when, with a bit more effort, they could have used build-time binding. That tends to produce more code but it does reduce / eliminate VMTs.

Wait a sec, really? Why not?

-jim lee

On a PC, when a pure virtual method is called a trappable exception occurs that, by default, terminates the program.

What happens when you accidentally call one on an Arduino?

Bear in mind that the cost to add an empty implementation is a single machine instruction that the linker will very likely fold into a single machine instruction for all empty implementations. In other words, the cost of an empty method is very very close to zero.

Donno about an Arduino, but on the Mac (Pre osX days) the compiler would error if you tried to create an object from a class with any pure virtual methods. We used it as a flag saying that this class MUST be inherited and not used directly.

I guess I could just try it..

-jim lee

mikb55:
Plain C seems to be the current industry standard for embedded systems. Not sure why.

Is there any reason not to create c++ style classes in Arduino?

Not sure what industry you got that from, but I started doing embedded systems in the late '70s, and started using c++ in the mid-90s, and never went back. c would sometimes be used in some of the HAL layer code, but that is about it.

The advantages of object orientation FAR out-weigh the disadvantages in 99.999% of applications. CPUs are VASTLY faster and better resourced than they were back then, and the compilers are VASTLY better at optimization, making any penalty virtually non-existant except for extremely rare cases. For those rare cases, c code can be used in very localized areas, leaving the bulk of the code OOP.

Regards,
Ray L.

RayLivingston:
CPUs are VASTLY faster and better resourced than they were back then...

A small addition to that...

Wikipedia:
The designers worked closely with compiler writers at IAR Systems to ensure that the AVR instruction set provided efficient compilation of high-level languages.