ESP32 Forum

I am using Eclipse as my build environment (on Linux) and am using the latest ESP-IDF with the 5.2.0 Xtensa GCC. I also want to write apps in C++ using the Standard Template Library (STL). For example, I want to declare variables that may be strings ... for example:

std:string myString;

I am including

#include <string>

First the good news ... all compiles and runs cleanly.

Now the bad news, I can't get my Eclipse (Neon.2) to find the "std::" namespace classes and hence have no entry assist. Has anyone gotten a build environment working that uses the Standard Template Library with Eclipse that uses the Xtensa GCC tool chain that resolves the namespaces?

Neil

Had the same issue: now I Include the full path in the #include

This works for me (Using eclipse Mars)

Howdy my friend, VERY good and VERY interesting. First, thank you for the response. This gives great credence to the notion that it isn't just a goof on my part.

To elaborate on your answer ... out intuition would have us code:
and this does indeed work but the IDE shows errors (but compiles cleanly). The error being that the "std::string" class is not found. We have already modified our Include paths to include:

/opt/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0

which does indeed include the header file called "string".

Following your suggestions I changed:

#include <string>

to

#include "/opt/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/string"

and the errors about missing std::string disappeared ... so this is most definitely a workaround. However, its not a workaround I'm at all happy with. My goal is to create samples in Github for others to download and I can't assume a fixed location for the XTensa tool chain. I'd like to continue to work this puzzle ... if you or any of the other community members want to join me in the snipe hunt, feel free to chime in.

Later ... wow ... that was painful. I found an answer but I don't know "how" or "why" it works.

Here is the recipe.

* In your project, right click the project and select "Properties".
* Navigate to C/C++ General
* Navigate to Preprocessor Include Paths, Macros etc.
* Select the "Providers" tab
* In the "Command to get compiler specs", change the string to read:

xtensa-esp32-elf-gcc ${FLAGS} -E -P -v -dD "${INPUTS}"

* Rebuild the index

And now the std:: namespace seems to work.

Hi Kolban,

Just to be clear, is this any different to the steps described in the Eclipse setup guide? I don't see a difference in the steps, but I wanted to be sure as it's all a bit fiddly.

kolban wrote: I found an answer but I don't know "how" or "why" it works.

The process of getting the "compiler specs" has Eclipse run the gcc preprocessor to spit out information about where gcc looks for header files. This is how Eclipse knows that there are headers to be found in
/opt/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0 (or whereever it happens to be on your system.)

No question that the instructions in the formal docs gave me the notion of where to start looking ... no question.

However, in Eclipse, there are many ways to "skin the cat". The end result in Eclipse is that we have a workspace and in the workspace we have projects and in the projects we have control files. I use a recipe which works as follows:

1. Create a Workspace folder (if one doesn't already exist)
2. In the workspace folder, clone the ESP-IDF template project into a folder with the name of the project I want to build
3. In Eclipse Create a new C or C++ makefile project and point the Project folder to the existent folder created by the GIT clone

Now I "fix up" the existent C/C++ project by importing the include paths necessary. I do not believe that is the recipe supplied in the formal docs. To be clear, I sure am not saying that my recipe is any better ... it is just the recipe that I am following.

It is the last step in the formal docs that I had missed in my recipe practice which, once done, has resulted in it working for me. I suspect that if I had followed the formal documentation from the outset step by step, all would have been well.

kolban wrote: Now I "fix up" the existent C/C++ project by importing the include paths necessary. I do not believe that is the recipe supplied in the formal docs. To be clear, I sure am not saying that my recipe is any better ... it is just the recipe that I am following.

It is the last step in the formal docs that I had missed in my recipe practice which, once done, has resulted in it working for me. I suspect that if I had followed the formal documentation from the outset step by step, all would have been well.

Yeah. Eclipse is tricky!

You're correct that we don't recommend or require any manual setting of include paths. However that's what a lot of people have used in order to get things working.

What's supposed to happen (if following the official setup steps) is that the first time Eclipse builds the project, it looks at the compiler command line arguments (which includes lots of "-I" arguments passing header search paths). This gives it the IDF header search paths, for the "include" directories inside IDF and the project itself.

It also runs the "get compiler specs" command, as mentioned above. This gives it the built-in header search paths, for things like the STL C++ headers. This isn't necessary for Eclipse to find the libc C headers, we use our own C library inside IDF rather than the one that's internal to gcc.

Between these two things, Eclipse should have a complete picture of all of the places to look for header files and it can successfully parse them, highlight things, provide high-level links and other nice IDE behaviour, etc.

However, a lot of people have had trouble with this. I think this is for any one of a number of reasons:

• Before the first time you run Project -> Build, Eclipse doesn't know anything (as watching the compiler run is how it finds out where the directories are) so everything has a red squiggle. I think some people (understandably) assume this means it's broken, or alternatively if something else is broken then building the project may fail and the red squiggles will remain.
• If you skip or typo one of the several fiddly steps in the official setup guide, Eclipse will only get part of the picture so some or all of the names in source files will have red squiggles.
• On Windows, until recently parsing the IDF header paths in the build output didn't work properly. This should be fixed in IDF master branch as of a couple of weeks ago, although the Eclipse setup instructions have also changed a bit so will need to be re-followed.

The reason we've never recommended manually adding include directories is that there are a lot of them - especially once you include the internal compiler ones. If you want to see the full list you can run Project -> C/C++ Index -> Generate Report while you have a single source file open, and the report will list all of the header directories that Eclipse is tracking for that source file. While adding some directories manually fixes the most obvious shortcomings, there's a "long tail" of more obscure directories (like the STL ones, for example.)

We know that the Eclipse setup steps are fiddly and error-prone, and we are still hoping to provide better solutions (like a setup wizard) in the future.

Hello Neil, hello Angus,

I sat myself on two chairs, today and so far it works.

I followed the video tutorial in order to build a Standard Template Library.
I modified the included paths of include.xml
/opt/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0
/opt/xtensa-esp32-elf/lib/gcc/xtensa-esp32-elf/5.2.0/include
to
/my/directory/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0
/my/directory/esp/xtensa-esp32-elf/lib/gcc/xtensa-esp32-elf/5.2.0/include
Eclipse does compile without errors.
That is nice.
I also successfully rebuild the index so all error messages of the cpp3 file disappeared.

I set up further properties in eclipse as to your guidance provided here

By the way, in my project folder I opened properties and underneath c/c++ Build -> environment I added:
PATH
/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/usr/esp/xtensa-esp32-elf/bin:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/my/directory/esp/xtensa-esp32-elf/bin/

I also added
BATCH_BUILD -> Value 1
IDF_PATH -> /my/directory/esp/esp-idf

In case I receive an error message when I type menu config in the command line
I try:
export IDF_PATH=~/my/directory/esp/esp-idf
then again: make menuconfig

I case I receive an error message when I type make
in the command line, I try:
export PATH=$PATH:$HOME/esp/xtensa-esp32-elf/bin
then again: make

works for me...

Thank you both for your great guidance.

DL88AI88

Excellent ... thanks for the response. Tips and improvements on the procedures are always welcome ... that way we can all learn from each other. I'm becoming a bigger and bigger fan of working in C++ each day. Given that (for the most part), C++ is a superset of C we can leverage our existing C skills and incrementally introduce C++ constructs gently as we gain confidence.

Since our Xtensa toolsuite supports C++11 (the 2011 standard of C++) Ive been studying some new things. For example, in C++11 we support "lambdas". If you think a lambda is a big sheep found in Peru that spits at you ... stop reading now

The lambda is a fancy term for a function that inherits its context ... but for me ... its an inline function!!!

Imagine a C function defined as follows:

void myFunction(int (*fptr)(char *name) {
// we are about to call a function pointer
int age = fptr("neil");
}

This is a standard piece of C that takes a function pointer as a parameter. Normally we would do something like the following:

void getAge(char *name) {
return 35;
}

and then call:

myFunction(getAge);

Thats cool ... and standard C ... however in C++11, we can code function references in-line ... for example:

myFunction([](char *name) {
return 35;
});

And what we have is an anonymous function that satisfies the signature. Absolutely great in a call-back environment. This feature has always been there in languages like JavaScript and now in Java 8 ... but is GREAT to have extra tools in my tool box like this in the ESP32 land simply by compiling with C++.

FWIW, you can't have lambdas inherit any context if you want to use function pointers.

I looked them up a while ago because I wanted to add some context to an ISR, but no dice...