Move to c++

[Frogmore42]

I saw this:
https://github.com/arendst/Tasmota/projects/3

But did not see anything else there. When I first started trying to do some development within Tasmota, I found it very difficult. The Arduino way is fine for small projects. It was created to make it more approachable for people that don't have a CS background. Making things simple is great, except when one tries to make them more simple than possible. Tasmota is big and complex. Arduino dumps all the INOs together to make one file, so some of the benefits of isolation of concerns is lost. It also makes it much easier to use variables far from where they are defined (and harder to find where they are really defined). Having said that, it would be a big job to change all the Tasmota core code to c++ and would probably need to be done all at once.

Is this a real project and is there a plan for it?

[arendst]

As also said there we stay on ino for now. Using vsc makes finding variables a breeze and many have been moved to TasmotaGlobal anyway.

No energy wasted on moving to c++ for now.

[Jason2866]

TDer (ESPEasy) started to do. He run in problems with PlatformIO, to solve he had to do some ugly workarounds in code and PlatformIO scripts.

[TD-er]

Maybe I can shed some light on why I spend so many hours in converting .ino into .cpp/.h files and this process uncovered lots and lots of new issues.
Then you can decide whether it may be wasted energy or something that may be inevitible in the long run.

I don't know the Tasmota code very well, so maybe the Tasmota code has less to gain here.

I don't think I need to explain what the Arduino way is of compiling .ino files, but just to be sure some really essential parts are not lost, I will summarize it a bit.

• Concatenate all .ino files into a single .cpp file
• Grep all function declarations from the file and prepend them in this new .cpp file
• Compile.

This works all nice for smaller projects, but as soon as you try to use C++ objects as function parameters or return values you can easily run into very strange bugs that sadly not always manifest themselves during compile time.
To overcome these specific issues, you can forward declare those functions just a line above it, as long as you obey one very strict rule; This forward declaration must not contain line breaks (!!!!)

Another problem which may occur when compiling .ino files is that the pre-processor may act strange as it is next to impossible to know in what order files are being compiled.
So if you have a .h file in which you derive build specific #define statements, you must make sure this file is compiled first when compiling anything else.
As long as EVERYTHING you're compiling is in .ino files, you're fine as they all end up in the same .cpp file, which is compiled in 1 run.
But as soon as you start using .cpp/.h files that also depend on those defines.... well let's use the technical term for it... you're screwed.

Thus if you're compiling .cpp files which do need those build specific defines, you MUST make sure the .h file setting those defines is also included in that .cpp file, or indirectly via another .h file that includes the needed one.
So better make sure to have some common.h which will be included where it may be needed or else you may end up with object files being linked together which may have used different defines.

Another thing to keep in mind.
If you're including the same .h file from multiple other files, you must make sure the file is only compiled once (thus use #ifndef SOMEFILENAME #define SOMEFILENAME ...... #endif).
This also applies to global defined objects:

• Declare them in a .h file (e.g. myglobalvariables.h) using extern bool myglobalbool;
• Construct them only once (!!!!) in a single (!!!) .cpp file (!!!) like this:

myglobalvariables.cpp:

#include "myglobalvariables.h"
bool myglobalbool = false;

And there are lots of other things you can do wrong... ehh learn from :)

Now the issues I encountered while doing all of this.

Compiling in PlatformIO on Windows will sooner or later refuse to link with a very cryptic error message.
In short, all .cpp files will be compiled into .o files and those will be linked by the linker.
The linker is called with a single command with all these .o files.
This command line will eventually exceed 32768 bytes, which cannot be dealt with in Windows.

Another problem with PlatformIO is that the documentation suggests to use CPPDEFINES but that will cause lots of very strange build issues, stuff being compiled (and linked in) which should have been left out, etc.
So I now just append the defines I need to the existing ones you already set when setting build_flags using -DMYDEFINE (thus the -D prefix) and all is building nice again.

There are lots and lots of other issues I had to overcome.

So now the big question... was it worth it?
For ESPEasy it was either that or running into hit-or-miss builds where one build would work perfectly fine and another with just a single print string changed would run completely unusable unstable.

I'm not sure if Tasmota will have the same benefit from it.

Just a word of caution.
As soon as you start, there is no way back and you must really understand the process of building/linking/preprocessor etc. in order to make good informed decision on what parts to do first as you simply cannot convert it all at once. (or at least I have no idea how to convert it all at once without manual changes)

[arendst]

Thx for your elaborate insights!

As Tasmota currently isn't hampered by the arduino format I'm convinced (again) to stay there for now.

[TD-er]

Thx for your elaborate insights!

As Tasmota currently isn't hampered by the arduino format I'm convinced (again) to stay there for now.

Glad I could help out a bit in overseeing what may be needed to convert it all, so you would not repeat all the mistakes I made.
The most important thing here is to understand the effort it takes and the benefits you may gain.

In short when you really should consider switching to .cpp/.h:

• When using compile time determined defines + some .cpp/.h files
• When using C++ objects as function parameter or return type (or you keep declaring them for each function definition like struct Bla_struct* bla)
• When defining global scope objects in a .h file. (you need to use the extern clause in a .h file and the actual construction in a single .cpp file)

And these are still possible to overcome and use in combination with .ino files, but things may become tricky if you are not aware of the consequences.
All-in-all, working with .cpp/.h files is more predictable in how it is all compiled and linked.
Whether that's important enough to go into all the effort is upto you and knowing how much issues I've encountered I think it is wise to be a bit reluctant in making the step.