Using VScode as editor

you can use ANY editor you want. my favourite is slickedit and i edit all files with that and only build/debug with uvision. what you can't do is expect to use any editor as an IDE.

As already noted, you can use any editor you like to edit your code - you don't have to use the one built-in to the IDE.

Many programmer's editors do have the facility to call external tools; eg, to build your code.

"why Keil does not replace it's old editor with a free modern editor like VScode?"

You mean this: code.visualstudio.com/.../cpp ?

It says:

"C/C++ support for Visual Studio Code is provided by a Microsoft C/C++ extension ... The extension is still in preview ... "

Which probably answers your question - it isn't finished yet!

First of all, if you want to use any programming languages, my advice would be to use the Visual Studio Code. It is free and open-source plus it gives an autocompletion. It is the best code editor out there with lots of improvement for Python programming language.

The core developer team of VSCode is very active and gives us an essential update from time to time. 

Now, let's move to your question.

Please add the following code runner in settings.json. It seems to work for me.

"code-runner.executorMap": {
    "cpp": "cd $dir && g++ -std=c++17 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
},

I hope it helps.

Some other folks have commented on VScode. I want to comment on C++14. I know this question is about a year old, but just in case a future reader needs some breadcrumbs...

When you say "use c++14" that is somewhat ambiguous. If you are referring to using basic / convenience features, like digit separators, binary literals, generic lambdas, 'auto' variables, or std::make_unique, then you are going to be fine with simply selecting the right compiler and rebuilding.

On the other hand, if you intend to use the threading (<thread> <mutex> <future> ...)  or time (<chrono>) libraries, then that is going to be a bit more work. The main challenge is that Keil can't predict what RTOS you will use: ThreadX, RTX, FreeRTOS, mbedOS, or any of a hundred others. And of course each OS has a slightly nuanced way of handling their primitive constructs. In spite of that, (thankfully!!), Keil has done most of the heavy lifting, by providing libraries with easy C-style callbacks for the places where these C++ libraries hook into the OS.

Contrast this with IAR, which doesn't provide anything at all, for example IAR's <thread> is a single error statement saying "#error "IAR Systems does not support thread". Yay IAR. 

Keil on the other hand, has a full <thread> implementation, up to the point of where a seam exists between the stdlib and the RTOS. And that is what you will have to fill in.

(As a small aside, GCC or specifically arm-eabi-none is in a similar camp as Keil -- see the '<bits/gthr-default.h>' file for the gcc porting layer - you would need to create and fill in a gthr file for your OS of choice).

Back to Keil, for a launch point, see www.keil.com/.../armclang_lib_wip1493208196925.htm.

For C++14, the basic steps are:

- TARGET TAB: pick compiler v6

- COMPILER TAB: enable RTTI, select the C++14 dialect, and add some defines: -fexceptions -D_ARM_LIBCPP_EXTERNAL_THREADS

- LINKER TAB: similarly, add some misc controls: --stdlib=threaded_libc++

Once you do this, you can use the C++ features creating a thread or initializing a mutex, and the linker will look for the ARMCLANG library callbacks. 

So for instance, the function:

int __ARM_TPL_thread_create ( __ARM_TPL_thread_t* __t, void* ( *__f ) ( void* ), void* __arg )

you would implement per your desired OS. An example native call would be FreeRTOS's xTaskCreate. Or if you are using CMSIS compliance then osThreadCreate. 

As you can probably guess, this effort of filling in Keil's hooks should not be underestimated. The stdlib definition has a lot of nuances, you will have to think about the ability to join threads, to how to handle threads that terminate before the next statement in the caller context, and so forth. I have done this for both IAR (see above, basically start from scratch) and for Keil (implementing the hooks).  IAR took 1-2 weeks. Keil took a 1-2 days. But the result is very rewarding -- after this, you are able to exercise just about any feature in C++14 you'd like.

If you make it far enough to have implemented the stdlib backend, then I would assume you are versed enough in OS design to be aware of initialization challenges, namely, starting the kernel. Unlike say, a Windows C++ executable, where main() is already spooled in the context of a thread (windows process), a bare metal executable needs main to start that OS itself. There are some tricks you can play regarding automatic OS launching but those tricks in my assessment tend to add minimal value. (For an similar non-OS-domain example, see how google-test discovers test suites and invokes them without an explicit registration by using static initializers). While witty and slick, these techniques for kernel management are only marginally superior to just accepting a limitation that main() will itself be an OS launch context, not a thread.