getting mplab XC32 to grasp that this is C++ not C

[Simon]

Apart from the fact that it seems to be just ignoring all the paths I set up for header files because MPLABX is the peice of junk it is I have a new problem, now it thinks it is trying to compile C rather than C++. I have a header file of register definitions and where I have created types with in C++ is done by just declaring a structure or union rather than typedef is says it can't find the types.

An overloaded function brings in a complaint that I think is that it is define twice but not sure. Overall it seems that all header files are being treated as C when they are included from c++ files.

How do I convince this brute?

[langwadt]

#include is really just a copy-paste into the source file

[JPortici]

I never did C++ on MPLABX. While it's possible, i wouldn't do that.
I remember reading of this issue. I think you have to either make your headers hpp, or pass some flags in the command line (it's a GCC problem)

[Simon]

#include is really just a copy-paste into the source file

And it can't even do that. An entire programmed is now a mess, I don't know what has happened since the last time I compiled it but now it just can't find any of the includes.

[cv007]

Is the C++ compiler being invoked? The compile output would tell you- *g++.exe and/or *gcc.exe. I don't use the mchp xc compilers but maybe they have different names.

Including C++ things in a C source file, or compiled with a c compiler, would produce various errors.

An empty class, in the source file, would tell you quickly whether the c++ compiler is being invoked as a c++ compiler would have no problem with an empty class and the c compiler wouldn't understand it at all-
class C {};

[bson]

Check that the IDE thinks the file including it is C++ as opposed to C...  I haven't used MPLABX in ages, but maybe something under the project navigation, like a right click?

[ejeffrey]

Overall it seems that all header files are being treated as C when they are included from c++ files.

I'm absilutely not denying that mplab is doing something dumb but this is not possible.  There is no way for any compiler I know of to treat the included files differently from the file they are included from.  The entire translation unit (.c/.cpp file plus all includes) are compiled as a whole, and either c or c++.

The first step is to extract the actual compiler command being executed.  It should be in the logs somewhere.  If you can post that it will likely be clear what is going on, then the question will be what magic settings in mplab are making it do that.

[bson]

Well, the #include could be inside an 'extern "C" { ... }'...

[Simon]

Every error starts with something like:

C:\Program Files\Microchip\xc32\v5.00\bin\xc32-gcc.exe"   -g -D__DEBUG   -x c -c -mprocessor=ATSAMC21J17A  -O0 -fno-common -mchp-stack-usage -MP -MMD -MF "build/default/debug/_ext/811099509/class_adc.o.d" -o build/default/debug/_ext/811099509/class_adc.o ../samc_cpp_source_old/class_adc.cpp    -DXPRJ_default=default      -mdfp="C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21" -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"

So looks like it is calling the C compiler instead, I have no include paths in the C compiler settings only in the C++ ones so it can't find any includes and the ones it does are treated as C. due to all the issues it has no even got to trying to compile a class so has not noticed by itself.

[Simon]

I found this thread: https://forum.microchip.com/s/topic/a5C3l000000Mf5DEAS/t387978 (selected cpp File Extension and set Default under Associated File Type (MIME).)

Seems to be a problem with the MPLAB X / net beans standard configuration that despite me going through about 4 computers in the last month has not been and issue with the standard setup until now. But having started moving files around and changing file names I have that mess to sort out but it looks like the problem was that the C compiler was being invoked for every file type even the C++ ones.

I really need to take some time to work out how to setup VSC for ARM micro controller programming and debugging. This MPLAB.X thing is the IDE from hell.

[JPortici]

Yeah, that was the thread i was thinking about

[voltsandjolts]

I really need to take some time to work out how to setup VSC for ARM micro controller programming and debugging. This MPLAB.X thing is the IDE from hell.

One of the best things I've done for my embedded setup was move to j-link for programming and debugging (their Ozone debugger is pretty sweet). It supports tons of micros and it's solid. That leaves you free to use any editor you like. Honestly, it gave me a sense of freedom and reduced stress. I don't mean to sound like a fanboy, but it's helped me a lot.

Also, here is an example standalone makefile C project for SAMC21, in case you're interested. I assume it'd be simple enough to switch it to g++.
https://github.com/ataradov/mcu-starter-projects

[Simon]

Which of the J-links exactly were you refering to? they range from $200 to $1000+. I have gone round this circle before.

I have a cheap USB to SPI/UART adapter, it also does JTAG, is it easy enough to set one of those up in VSC?

[langwadt]

Every error starts with something like:

C:\Program Files\Microchip\xc32\v5.00\bin\xc32-gcc.exe"   -g -D__DEBUG   -x c -c -mprocessor=ATSAMC21J17A  -O0 -fno-common -mchp-stack-usage -MP -MMD -MF "build/default/debug/_ext/811099509/class_adc.o.d" -o build/default/debug/_ext/811099509/class_adc.o ../samc_cpp_source_old/class_adc.cpp    -DXPRJ_default=default      -mdfp="C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21" -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"

So looks like it is calling the C compiler instead, I have no include paths in the C compiler settings only in the C++ ones so it can't find any includes and the ones it does are treated as C. due to all the issues it has no even got to trying to compile a class so has not noticed by itself.

"-x c" mean use c regardless of input file extension, without it *.cpp files should automatically be treated as c++

[voltsandjolts]

Which of the J-links exactly were you refering to? they range from $200 to $1000+. I have gone round this circle before.

I would recommend the j-link plus as it's the cheapest option which has an Ozone license.
https://uk.farnell.com/segger/8-19-28-j-link-plus-compact/debug-probe-1mbps/dp/3106582
https://www.ebay.co.uk/itm/257179833926

Not my ebay listing BTW!

But you can use any j-link to evaulate Ozone and other Segger software and decide if it's for you.

[voltsandjolts]

I have a cheap USB to SPI/UART adapter, it also does JTAG, is it easy enough to set one of those up in VSC?

I just use my editor as a text editor.
Then alt-tab to command line window to run make (I use makefile projects, as per link above).
Then alt-tab to Ozone debugger, which pops up with "code changed do you want to download", yes please.

So, not integrated at all, but a nice separation of concerns.
I undertand some folks would not like this, especially if you have a 'build and run every 2 mins' style.

[SiliconWizard]

Every error starts with something like:

C:\Program Files\Microchip\xc32\v5.00\bin\xc32-gcc.exe"   -g -D__DEBUG   -x c -c -mprocessor=ATSAMC21J17A  -O0 -fno-common -mchp-stack-usage -MP -MMD -MF "build/default/debug/_ext/811099509/class_adc.o.d" -o build/default/debug/_ext/811099509/class_adc.o ../samc_cpp_source_old/class_adc.cpp    -DXPRJ_default=default      -mdfp="C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21" -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"

So looks like it is calling the C compiler instead, I have no include paths in the C compiler settings only in the C++ ones so it can't find any includes and the ones it does are treated as C. due to all the issues it has no even got to trying to compile a class so has not noticed by itself.

"-x c" mean use c regardless of input file extension, without it *.cpp files should automatically be treated as c++

Exactly. Now why MPLAB forces C mode by default this way, only the great architect of Microchip can tell.
Maybe the reason is that they have historically used non-standard extensions for some of their support files, so they needed this option flag to force GCC to compile them as C, and there's probably so few customers using C++ that they didn't really bother fixing that.

[bson]

Now why MPLAB forces C mode by default this way, only the great architect of Microchip can tell.

Probably because of their idea of things like "C Project", "C++ Project" etc.  Whereas in reality projects often have a mix of source language files, scripts files, XML, JSON, etc.  I mean, if you create a "C Project", don't you want everything, even a file called 'main.foo' to compile as C by default?!

[Simon]

I don't understand why people do not use C++. But then the majority of people just want to know how to use the manufacturers "fuck it up for us ware" which is not written for C++. Then there are all the myths about C++ being bad and dangerous lumped in as though it is C which is dangerous because the compiler trusts that you know what you are doing. Then everyone runs off and uses that ball ache python ignoring that it is written in C anyway.....

For me C++ has been a major advancement and I only use it for the more rigorous adherence to correct use of the language than C and classes, I have not yet used standard libraries or dynamic memory allocation and still it is massively better than plain C.

I mean why do people even bother to write in "OBJECT ORIENTED" C when the can write in plain object oriented C++. I looked at the CANOpen stack project and just ran a fucking mile, it's so hard to figure out what is going on because it was written in object oriented C. OK my own implementation is probably simpler but it was so convoluted that it was not worth using as inspiration for my own.

[voltsandjolts]

Hiring good (or even mediocre) embedded C programmers is hard, I suspect it would be 10x more difficult hiring embedded C++ talent. So, I'd urge caution in moving your commercial codebases to C++. Maybe arduino kids would fit in. Dunno.

That said, I don't have anything against the "simple" version of C++. Classes for encapsulation, constructors, destructors, exceptions, pure virtual base classes, inheritance. Maybe even multiple inheritance. Fine. But then things get murky, to the point where much of the boost libraries, for example, are incomprehensible to me, like the preprocessor has now become some sort of insane compiler of its own. IDK. Heh, I only recognise the language thanks to the semi-colons.

Perhaps I just feel more comfortable and "in control" with plain C. It's manageable and it fits in my head, most of the time.

[ejeffrey]

For the most part compiling C code with a C++ compiler will just work and give you the option of using C++ features with basically no downsides.  You only have to use the parts you think improve your life.  For a single developer on a project, this is a totally fine approach.  I've definitely written plenty of code using the C++ language but only the C standard library.

I think the main reason this isn't more common is that there isn't a widely accepted "C++, just the good bits, for embedded" subset.  So in multi-person projects it is often easier to say "just use plain C" rather than define the acceptable subset of C++.

Historically it was also a problem that many chip manufacturers shipped their own compilers.  Often they had no C++ support, or even worse completely broken support.  These days pretty much everyone is using gcc or llvm so it's much less of an issue., but old habits die hard.

[Simon]

As GCC is the going standard the easy solution is to just not have a C++ library if that is the bit where things diverge.

I know very little about C++ and trying to use what C++ books aimed at operating systems teach on a microcontroller is just too much work at the moment. So I started slow, fundamentally it's C anyway but the C++ compiler is a stronger enforcer than the C one. statically declaring objects seems to be the best way at the moment.

The stricter treatment of types means that I can write code in a more robust and easy to read way by creating my own enum types for function arguments. So I can make the arguments in function calls more verbose rather than just naked numbers. The code is more readable later and I can only enter the numbers in the enum definition. So for example only the pins available on given chip can be defined, if I try to use an incorrect pin the compiler will stop me without having to write additional diagnostic code.

Putting things into classes makes it so much easier to decide what controls what and then stick to that. With C I had problems finding the boundaries between things and even though I grouped things into files I still lost things.

[Simon]

Oh and function overloading, that can make life so much easier.

[uer166]

Oh and function overloading, that can make life so much easier.

Function overloading makes every single operator suspicious, where a "+" can mean a single instruction or 1000. C++ has some benefits, but this particular kind of syntactic sugar is a net-negative overall.

[Simon]

Are you confusing function overloading with operator overloading? I use function overloading not operator overloading so once it has decided which version it needs to use (at compile) it's clear code.