There is a plan to allow STM32cubeMX for generating main.cpp instead of .c only ?

[dodonny]

Hi, I know this question have been asked several time, but STM32CubeIDE and STM32CubeMx are only generating .c file... this is very frustriating, time consuming and source of multiples error when working with cpp environment. We have to manually rename .c to .cpp file and vice et versa after each modification... this is so 1990 workflow.

Does this implementation have been planned in the future or shall I forget about it ?

Thanks for your reply.

[dodonny]

So painfull to lose your earlier 4 hours work because you have to rename main.c to main.cpp but forget to add it to your commit, because git see it as suppressed file... So unproductive, so unprofessional...

EDIT :

git mv <source.c> <destination.cpp>

could be small workaround for git issues

[Cartu38 OpenDev]

Many other thread on such topic. My opinion is such is not supported but not so much a pain. C++ projects are fully supported by IDE and obviously all STM32CubeMX / device configuration tool is generating C++ compliant material.

Just to be aware of then you have to organize your project in sync. ... you just have to take your C++ material out of main.c and that's all. According to me such is not a constraint but kind of good pratice. Main.c file is updated by tool ... I'm always in flavor to add my own material out of automated part ...

[dodonny]

Yes, this is the best option for solid big project. But could be very annoying for small speed test.

The most frustrating thing is that only need to generate main.cpp file instead of .c file. Just file naming...

I'll explore the : Do not generate main() option. Maybe use another IDE, eclipse only with STMcube beside and 1 or 2 openOBD script. But losing debugging in IDE is very annoying.

[dodonny]

But you can't compile project as C++ with a main.c ? Because it's the entry point of the software and because I cannot import C++ file inside a C file (but can do the opposite).

[Cartu38 OpenDev]

Even quick & dirty test may go quite fast no ?.

main.c file:

/* USER CODE BEGIN Includes */

#include "Process.h"

/* USER CODE END Includes */

int main(void)

{

...

 /* USER CODE BEGIN 'x' */

doMyCppProcess();

 /* USER CODE END 'x' */

...

}

then Process.h

#ifdef __cplusplus

 #define EXTERNC extern "C"

 #else

 #define EXTERNC

 #endif

EXTERNC void doMyCppProcess(void);

 then Process.cpp

#include "Process.h"

extern "C" {

  #include "Initializer.h"

}

void doMyCppProcess(void) {

....

}

[Piranha]

https://community.st.com/s/question/0D50X0000BFER0CSQX/cube32-feature-request-need-to-handle-cpp-files

https://community.st.com/s/question/0D50X0000At0EJ3/how-to-configure-stm32cubeide-to-support-c-development

> this is so 1990 workflow

And code generation is a fairy tale from 2000s... ;)

[Tesla DeLorean]

They were peddling that snake-oil back in the late 1980's.. I'm still waiting for my "kitchen of the future"

If you have to go through a process more than once, or expect too, automate it, write a script or small app.

The CubeMX tools don't do iterative fiddling very well, they really expect you to define the end goal once, and not keep pounding on the button. Keep your main branch separate from your auto-generated sandbox, and merge what you need, or script the process.

[dodonny]

Are you opposing 5/10 mn OR conditional programming inside CubeMX (and IDE) saving hundred of hours for worldwide developer to complex, unreadable macro definition.... ?

From my point of view, you have two options : Let people chose name and extension of the generated file... this way everybody could do his own kitchen...

or, pseudo code :

IF main.c file exist THEN 
write into it as we alwready do
ELSE IF main.cpp exist THEN 
write into it as we alwready do
ELSE 
throw error
END IF

[dodonny]

> And code generation is a fairy tale from 2000s... ;)

Yes, but for now this is our not worst alternative.

>If you have to go through a process more than once, or expect too, automate it, write a script or small app.

Interesting how everyone find alternative to one simple patch... of course they are alternative and workaround. I can recreate a configuration software from scratch to replace CubeMx but does this is the most efficient way ? Does this gonna be the faster way to improve people workflow ? For me Patching CubeMX is the faster way...

Thanks for you comments.