Win10 Home.
I’m using usb-portable version of VsCode. Going to full install standard version.
Installed standard VS code , reinstalled PlatformIO and PokittoLib.
Started from a C working solution single minimal main.c. Add -std=c++11 to platformio.ini. Close and reopen VSCode.
It compile again the same till add an c++ expression like
constexpr int test = 0;
Then same output.
Can you post your c_cpp_properties.json @Pharap? Mainly last section:
"intelliSenseMode": "clang-x64",
"cStandard": "c99",
"cppStandard": "c++98",
"compilerPath": "C:/Users/Filippo/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gcc.exe"
"intelliSenseMode": "clang-x64",
"cStandard": "c99",
"cppStandard": "c++11",
"compilerPath": "C:/Users/<me>/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gcc.exe"
Make sure it’s main.cpp and not main.c, if you try to use .c anywhere the compiler will go into C mode and won’t recognise constexpr anyway.
Just a typo. It’s cpp.
try this: open LPC11U68.json and put the C++11 flag right into it
it can be found in
.platformio/packages/framework-mbed/platformio/variants/LPC11U68
1 Like
Bad Boy! That’s work.
I now have:
"cxx": [
"-std=c++11",
"-fno-rtti",
"-Wvla"
],
and that’s made the trick. Thanks for help.
1 Like
You should not have to do that though. Someone should file an issue with Platformio. That is a bug.
1 Like
I was suspecting it 
I’m not sure I can fill a bug with enough information. Let’s wait to see if it’s something related to my own computer or if it happens to someone else.
(Edited from original context for migration purposes)
Agreed. So far we don’t have enough to go on to make a proper bug report.
Ideally we’d at least want steps to reproduce the problem.
@HomineLudens
I recently encountered a similar issue after updating my nxplpc version and made an issue about it on the PlatformIO forums.
I mentioned it to @jonne and he said it’s probably the same as this issue, and sure enough the fix that fixed this issue fixed my issue, so I think it’s an issue with the particular nxplpc version.
I updated from (I think) v3.3.something to v3.4.1, so I’m guessing somewhere between those points the system broke.
I plan to follow it up assuming someone responds to my issue.
I may have to chase it on GitHub instead.
2 Likes
Good plan.
I’m changing my mind again. If you “Install” a library through the manager in PIO, it gets copied to a .hidden directory.
There’s no other way but to go seek that dir copy the files over to your project etc.
I fail to see this as easy for a beginner
Am I totally misunderstandin the lib manager because like this (libs essentially hidden) how am I going to explain copy-pasting the platform.ini etc? Help, any advice welcome.
I don’t think it was hidden on Windows, but I could be wrong.
(I have ‘show hidden files’ turned on so I often don’t notice if something’s supposed to be hidden.)
I can see that it would be hidden on Mac by default because of the leading dot (though I’d argue that’s a flaw in Mac’s file system design - making anything prefixed with a dot hidden by default instead of just using file attributes).
To copy which files?
platformio.ini isn’t hidden.
Though I’m guessing if Mac hides all folders begining with a dot then .pioenvs, .vscode, .travis.yml and .gitignore are probably all hidden on Mac?
I’m sure a script could get around that though.
E.g. maybe an ‘after successful build’ script could copy the .bin file up to the project folder.
I think a lot of our problems with “how to make this easy for beginners” will be solvable by scripting.
It’s usually easier to explain “move this file from this hidden folder into this other folder” to a computer than it is to a non-technical person.
It’s almost impossible to find something that’s easy for a beginner and still provides all the powertools that an advanced programmer would want/need.
Linking libraries in is difficult enough as it is even when you do know what you’re doing.
The Arduino IDE is easy for beginners to use, and we all know what most programmers think of the Arduino IDE - they bin it and use VSCode or Visual Studio instead.
It’s imperative that we have a cross-platform C++11-capable IDE available.
If we settle for something that isn’t cross platform, that’s a significant fraction of potential users gone.
If we settle for something that doesn’t have C++11 support then we have to be prepare to put up with all the people asking “why doesn’t this game compile? why does it say ‘error: requires C++11’?”.
So far I think that even with these minor setbacks VSCode + PlatformIO is easier to use than a full scale IDE like EmBitz because you don’t have to worry about build targets,
you just have different projects instead of different build targets.
And often you can just copy a project and rename it without having to fiddle about with any IDE menus.
The only other alternative to VSCode at the moment is @FManga’s work on Code::Blocks.
We could perhaps look in to making some kind of makefile that will work with a larger IDE (e.g. Code::Blocks) or trying to get the custom GCC to work with something like VSCode,
but I’m expecting either of those will be more work than trying to improve what we’ve already got.
(If EmBitz had been cross platform in the first place then we wouldn’t have to be worrying about any of this.)
I’ll look more into how PlatformIO works and how to script it if I get chance, but I’m trying to cut down on the number of projects I work on concurrently because I keep having to put things on hold.
I had stopped work on that since PlatformIO seamed to be the better solution. If it’s insufficient for some reason, based on my brief experience rooting through the Code::Blocks source code, I think it’d be easier to just make a VSCode plugin that includes GCC and the PokittoLib.
1 Like
I concur.
Lightweight editors like Atom and VSCode seem to be very popular with ‘hobbyist’ programmers at the moment.
(I presume they’re still mainly using heavyweight IDEs in business/‘professional’ programing.)
I haven’t looked into how easy it is to make an extension for VSCode, but that’s a possibility if we can’t iron out the issues with PIO.
(Though so far apart from this issue that’s cropped up from updating the platform, I haven’t had any other problems with PlatformIO, so I’m not in a hurry to drop it.)
Making our own extension would still be a fair bit of extra work though. We’d have to decide if we were going to use just GCC for compiling or mix GCC and makefiles, and we’d need to develop an easy to use project settings format so people could have custom compiler flags (because frankly neither bare compiler settings or makefiles are beginner friendly).
(Maybe we could even take a leaf out of PlatformIO’s book and use SCons - programmatic Python scripts for build configuration.)
I’m not in a hurry either, but that’s because I’m happy using emacs+make. 
I did not mean to say we should be ditching PlatformIO. I only suggested making an extension as the alternative to Code::Blocks if it’s ever decided that PlatformIO is a problem.
VSCode uses JSON files for configuration, that would be the more natural fit. Ideally, the extension would just handle the build process on its own and users wouldn’t have to mess with flags unless they really wanted to.
I didn’t take it that way.
I just wanted to clarify that my thoughts about making a VSCode extension shouldn’t imply that I want to get rid of PlatformIO.
I agree, it’s probably one of the better alternatives.
I’m not a big fan of JSON because I’m always being bitten by missing commas or having too many commas,
but if an API for manipulating JSON is built-in and there aren’t built-in APIs for other options (e.g. XML, INI, YAML) then it’ll probably have to be JSON.
But allowing Pokitto projects might need to include a config file (equivalent to the current platformio.ini) that specifies extra build flags, like -std=c++14 for people who want to go beyond C++11 and the dreaded -fpermissive to make Arduboy projects slightly easier to port.
Allowing such a file to be bundled with projects means that the experts can tweak the flags to their hearts content and the beginners wouldn’t have to worry - they can just rely on the config file that comes with the project they download to handle the flags for them.
(And of course, if the config doesn’t specify otherwise, default to -std=c++11.)
If that’s the case, how do you do source level debugging? Command-line gdb?
1 Like
Emacs has gdb support built in.
Edit: isn’t debugging a paid feature in platformio? I tested debugging in VSCode using the Cortex plugin, works OK.
1 Like
Ah? Sounds good. Sure you didn’t start the 30 day PIO pro trial by mistake?