Programming in C++

[shaduzlabs]

Yes, i have encountered this problem as well when porting asio library to the ESP32. I have a few ideas how to resolve the issue with LwIP definitions, but this was somewhat a lower priority until now.

Any plans of releasing the asio port? I'd be really interested

[urbanze]

It's been a while since this discussion and it's time to ask if the "bugs / bugs" have been corrected, if it ever existed ...

I currently use ESP_IDF with Arduino component, I can use both Arduino and IDF libraries freely, and to this day I have not come across any "problems" regarding using C++ (main.cpp) except the "Designated initializers" as quoted above. I use C++ because with "main.c" simply mingw32 does not compile and also appears inumerous errors with Arduino libraries, so switching to "main.cpp" everything works perfectly.

I'm starting to use ESP32 for professional and maybe industrial purposes and I'd like to know if I need to take any care when using C++, which I do not have, since I've had no problems until today. What are the most common or "catastrophic" problems when using C++?

[kolban]

I use C++ almost exclusively and I haven't encountered any issues relating to the language. We even have exception handling support now adays. No issues here.

[permal]

I too use C++ exclusively, I've even wrapped Task management, event handling and I/O etc into a C++ framework. The only things that I'm lacking at the moment are:

* Ability to set stack sizes on an individual level when using std::thread (i.e. pthreads). This could be fixed by using FreeRTOS APIs instead, but I'd rather not do that.
* Complete concurrency support (https://github.com/espressif/esp-idf/issues/690), but so far as I can tell, std::unique_lock, std::mutex, std::shared_ptr and std::unique_ptr and std::condition_variable are working just fine so I'm not really missing anything.
* Things like std::to_string() and some other convenience functionality in the std-namespace, so full C++11 support.

[mzimmers]

I thought I had this beat, but...I too am getting the undefined reference to app_main().

- I've wrapped the definition of app_main() in extern "C" {} notation.
- Did a make clean

Still no success.

Also: I notice that there are (at least) two C++ compilers in my C:\msys32\opt\xtensa-esp32-elf\bin directory:

1. xtensa-esp32-elf-c++.exe
2. xtensa-esp32-elf-g++.exe

How do I tell the build environment which I wish to use?

Thanks...

[chegewara]

What i will write now can sounds weird, but it happened to me few months ago when ive been starting with esp32 + c++.
Ive got exact the same issue complaining about app_main(), even make clean did not work. What i did and helped to me was to delete main.cpp file and create it one more time with exact the same code.

[mzimmers]

That was worth a try, but didn't help.

[kolban]

When you compile source, the result ends up in the "build" folder. Go into that folder and you should find a folder called "main". Go into "main" and you should find a file called "libmain.a".

Now you can run:

xtensa-esp32-elf-nm libmain.a

This will dump the symbols contained in the library.

You should now look for an entry called "app_main" which should look like:

00000000 T app_main

Let us know what you find.

[mzimmers]

MZimmers@mzimmers-w10p MSYS /c/esp32_projects/esp32_wifi/build/main
$ xtensa-esp32-elf-nm libmain.a | grep app_main
00000000 r _ZZ8app_mainE19__PRETTY_FUNCTION__
00000000 T app_main

MZimmers@mzimmers-w10p MSYS /c/esp32_projects/esp32_wifi/build/main
$

[kolban]

In the main folder, what other files are in there? I expect main.o but anything else? Run the xtensa-esp32-elf-nm command over main.o and see what it reports. Try delete the whole of the build directory tree and rebuild the application and see if the problem persists.