Page 1 of 1
Myriad of compilation problems arising when switching from .c to .cpp
Posted: Wed Feb 19, 2020 11:03 pm
by zliudr
I was initially interested in using passing variable by reference that I thought was a C++ only feature:
I couldn't get it to compile under c so I renamed all my source files from .c to .cpp. Countless errors are thrown by the compiler. So before I get into any specific error, is .cpp supported by esp-idf? I'm using v3.3. Thanks.
Re: Myriad of compilation problems arising when switching from .c to .cpp
Posted: Thu Feb 20, 2020 12:07 am
by ESP_Angus
Yes, ESP-IDF V3.3 supports C++ and files with a .cpp extension will be compiled using a C++ compiler.
Note that not all valid C syntax is valid C++ syntax, so some examples/etc may need some modifications if converting to C++. And you need to mark any function called from C (such as app_main()) as extern "C" void app_main() { ... to ensure correct linking between C and C++.
You're right that the pass-by-reference syntax is only part of C++ and not C.
If you're seeing specific compiler errors and you're not sure what the cause is, please post them with as much information as possible and we can help you figure out the root cause.
Re: Myriad of compilation problems arising when switching from .c to .cpp
Posted: Thu Feb 20, 2020 12:27 am
by PeterR
I think the main new errors will be structure initialisation?
A lot of the esp device initialisation code is rooted in 'C' and in C++ structure out of order initialisation etc changes will not be tolerated!
Try wraping that sort of code in 'extern "C" {'
Wrapping target stuff into simple files (which is where this usually becomes a problem) is always a good idea.
Re: Myriad of compilation problems arising when switching from .c to .cpp
Posted: Fri Feb 28, 2020 12:24 am
by zliudr
Here is a related issue with struct initializers that I encountered. Fortunately another member found the solution just days before:
https://esp32.com/viewtopic.php?f=13&t=14269
Re: Myriad of compilation problems arising when switching from .c to .cpp
Posted: Fri Feb 28, 2020 2:30 pm
by father_gorry
So, which is the best way to handle that myriad of type conversion errors?
Perhaps returning to gcc is not an option? BTW, is it even possible in Arduino IDE?
Re: Myriad of compilation problems arising when switching from .c to .cpp
Posted: Sat Feb 29, 2020 1:52 am
by PeterR
Fix the errors. C++ was not created because it was worse. C++11 etc versions were not introduced because they are harder to use (although it may seem). Generally the newer languages/versions close down implemenation differences (and so better allow portability). The newer versions and also add richer feature. The only way is up.
Personally I find the structure initialisation a pain. I hope that the committee knows better and that this change helps me code better. Certaintly think.
Re: Myriad of compilation problems arising when switching from .c to .cpp
Posted: Sat Feb 29, 2020 12:48 pm
by father_gorry
I also have enormous amounts of type conversion errors. May this be because I'm trying to use freeRTOS code samples in Arduino?
Re: Myriad of compilation problems arising when switching from .c to .cpp
Posted: Sun Mar 01, 2020 3:13 am
by zliudr
father_gorry wrote: ↑Sat Feb 29, 2020 12:48 pm
I also have enormous amounts of type conversion errors. May this be because I'm trying to use freeRTOS code samples in Arduino?
Me too but those type conversion errors were all in a sense good for coding safely. I don't know if this was due to C to C++ conversion or not, I once defined:
I thought that I defined two pointers but in actuality I defined a pointer ch1 and a char ch2. Due to probably char takes 4 bytes (maybe memory alignment requirement) I was able to use both as pointers without errors but that's really a great way to bury a bug only to scratch my head later. Now what I do is to have a document to collect the common C function declarations to refer to before I code a call. I know my editor does it but it's a good review of what data types are used in them. For instance, I'm now favoring size_t and ssize_t more than int or long.