C++ support of stm32cubeide does not work.

[yujin]

in default situation, you could not call c++ function in C file. 

So the main.c  is not suitable file in C++ project.

if user choose C++ project,the generated main.c ,stm32h7xx_it.c should sufixed with .cpp.

[Ghofrane GSOURI]

Hello @yujin 

Please check this C++ Project on STM32CubeIDE - STMicroelectronics Community

and There is a plan to allow STM32cubeMX for generatin... - STMicroelectronics Community ,

it may help you solve the issue .

THX

Ghofrane

[Andrew Neil]

---

@yujin wrote:

in default situation, you could not call c++ function in C file. 

---

Did you provide the appropriate extern "C" declaration?

https://stackoverflow.com/questions/1041866/what-is-the-effect-of-extern-c-in-c

[unsigned_char_array]

main.c:

extern "C" void c_function_in_cpp_file();

int main(void)
{
    c_function_in_cpp_file();
    while(1)
    {
    }
}

cpp_file.cpp:

void cpp_function_in_cpp_file()
{

}


extern "C" void c_function_in_cpp_file()
{
   cpp_function_in_cpp_file();
   //function can be linked to C code, but can execute C++ code
}

You make a header file compatible with both C and C++ by using:

cpp_file.h:

#ifdef __cplusplus
//c++ class definitions etc. invisible to C files including this header
#endif

#ifdef __cplusplus
extern "C" {
#endif

//functions that can be called by both C and C++

#ifdef __cplusplus
}
#endif

[yujin]

this is not a good solution.

we just need stm32cubeide to generate main.cpp and interrupt.cpp if c++ was chosen.

[unsigned_char_array]

---

@yujin wrote:

this is not a good solution.

we just need stm32cubeide to generate main.cpp and interrupt.cpp if c++ was chosen.

---

C and CPP source files can coexist. I've been doing it like that for many years. I really don't see the issue. if you need main to be cpp you can exclude it from build and include the c file in a cpp file. Or make an app_main.cpp with an app_main() that's called from main().
Is there a specific problem this causes? Did you find another workaround since almost an entire year after I posted my solution?

If you really want main to have the cpp extension you can simply write a script for this.

In STM32CubeMX you can add code before and after code generation. 

STM32CubeMX->Project Manager->Code Generator->User Actions

Then add "before.cmd" to "Before Code Generation" and add "after.cmd" to "After Code Generation"

before.cmd:

ren Core\Src\main.cpp main.c

after.cmd:

ren Core\Src\main.c main.cpp

I tested it and it works.

STM32CubeMX is simply limited in how it structures generated code. I would have liked more user code sections or the ability to add your own. But that has been requested for a long time now. Luckily there are macro tricks to modify generated functions by creating an alias of a function so it won't be overwritten using generation. If you want your own project structure you might just use code generation to get something working (peripheral and clock setup) and then copy that to your own structure. I think it's too much to ask that the generator will meet everyone's exact needs.

You marked this topic as a bug-report. But I see it as a feature request. Cpp support means simply that STM32CubeIde can also have cpp source files. All drivers are in C. You want all of those renamed too?

[Pavel A.]

> we just need stm32cubeide to generate main.cpp and interrupt.cpp if c++ was chosen.

Unfortunately this is not likely to happen soon. Use a post-generation command (script) in CubeMX to modify the generated files as you prefer.

Or better, learn about coexistence of C and C++ source files in a c++ application (basically, use extern "C")

[yujin]

Yes, you can write a script to change the file extensions of 'main.c' and 'interrupt.c' to '.cpp', or vice versa. In fact, I have already done something similar.

However, I consider this a suboptimal solution because it should be handled at the system level rather than by a patch.

Another common suggestion is to wrap C++ code in C using extern 'C' constructs, but this approach can introduce additional complexities and complicate the codebase.


KISS！

[unsigned_char_array]

You didn't answer my question. "Is there a specific problem this causes?"

"Another common suggestion is to wrap C++ code in C using extern 'C' constructs, but this approach can introduce additional complexities and complicate the codebase."
What issues did you find?

"KISS!"
Keeping it simple would be to accept the code generator generates C code and simply write application level code in C++. You forget how much time this will take for ST to test all their c code also in cpp. They offer their solution for free and offer free assistance on this forum.