Using Qt with Visual Studio Code (Windows) - c++

The following are installed:
Visual Studio Code (1.45.1)
Visual Studio 2019 Community (in order to use the MSVC cl.exe compiler)
Qt 5.15.0 (installed to C:\Qt)
Visual Studio Code has been launched after running Visual Studio Command Prompt so that the environment is set correctly for cl.exe. The ms-vscode.cpptools extension has been installed in Visual Studio Code and includePath is set to:
"includePath": [
"${workspaceFolder}/**",
"${INCLUDE}",
"C:/Qt/5.15.0/msvc2019_64/include/**"
],
This file hw.cppcompiles and runs fine:
#include <iostream>
int main()
{
std::cout << "Hello world!";
return 0;
}
The command used in tasks.json is:
"command": "cl.exe",
"args": [
"/Zi",
"/EHsc",
"/Fe:",
"${fileDirname}\\${fileBasenameNoExtension}.exe",
"${file}"
],
Alternatively, from the in-built Terminal inside Visual Studio Code, the command "cl /EHsc /MD /O2 hw.cpp /link /out:hw.exe" compiles everything correctly and hw.exe can be executed.
But when I attempt to use Qt as follows it fails to compile:
#include <QString>
int main()
{
QString test("Hello world!");
qDebug() << test;
return 0;
}
The compiler reports "fatal error C1083: Cannot open include file: 'QString': No such file or directory". IntelliSense does find QString.h, which opens when I press Ctrl and click QString (at the top).
What am I missing?
UPDATE
Thanks to comments from #rioV8, I've investigated /link options for cl.exe. The task arguments have been updated to:
"args": [
"/EHsc",
"/MD",
"/O2",
"/IC:\\Qt\\5.15.0\\msvc2019_64\\include",
"/IC:\\Qt\\5.15.0\\msvc2019_64\\include\\QtCore",
"${file}",
"/link",
"/LIBPATH:C:\\Qt\\5.15.0\\msvc2019_64\\lib",
"Qt5Core.lib",
"qtmain.lib",
"/OUT:${fileDirname}\\${fileBasenameNoExtension}.exe"
],
This has improved things slightly. hw.cpp now compiles and generates hw.obj, but now I get linker errors (one for each .lib):
warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
This is followed by fatal error LNK1120: 2 unresolved externals.
Getting closer, but still not linking.

There has been a detailled guide on the KDAB blog recently.
Overview of VS Code for Qt developers:
https://www.kdab.com/using-visual-studio-code-for-writing-qt-applications/
Technical guide:
https://www.kdab.com/using-visual-studio-code-for-qt-apps-pt-1/
https://www.kdab.com/using-visual-studio-code-for-qt-apps-pt-2/
The steps in the technical guide look very similar to the issues you are describing ;-)

Related

Visual Studio Code - Include Path Problems Header Files C++ (MinGW)

I am pretty new to programm in C++ so please don't judge my problems with setting up my "Visual Studio Code" environment. I am trying to use the blaze math packages to solve quadratic programming problems. With the MinGW GCC I can compile the testfiles of blaze successfully via cmd and thus I want to use the GCC for VS Code.
OS: Windows 10.0.19041
GCC: gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 7.3.0 || (cmd: gcc --version)
VS Code Extensions: C/C++ 0.27.1
Firstly I went through the VS Code tutorial for MinGW:
https://code.visualstudio.com/docs/cpp/config-mingw
This worked fine so I can easily compile my helloworld.cpp. The resulting tasks.json file looks like this
tasks.json.
As my package manager (for blaze or other packages) i use the vspkg-git:
https://learn.microsoft.com/en-us/cpp/build/vcpkg?view=msvc-160
Thus I am programming on Windows I can't use the "integrate" command to add the path to the includepath. So I have to do this manually.
My packages are in the folder with the absolute path
C:\Users\Johannes\Desktop\Masterthesis\vcpkg\vcpkg\packages
So I added the path on the "c_cpp_propertier.json"-file
{
"configurations": [
{
"name": "GCC",
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"cStandard": "c11",
"cppStandard": "c++17",
"intelliSenseMode": "gcc-x64",
"includePath": [
"${workspaceFolder}",
"C:/Users/Johannes/Desktop/Masterthesis/vcpkg/vcpkg/packages/**"
],
"compilerPath": "C:/Program Files/mingw-w64/x86_64-7.3.0-posix-seh-rt_v5-rev0/mingw64/bin/g++.exe",
"browse": {
"path": []
}
}
],
"version": 4
}
In the folder are several packages therefor I added the "/**" at the end of the path to enable the recursive search for header files.
My 'helloworld.cpp' file looks like this
#include <iostream>
#include <vector>
#include <string>
//#include <blaze/Math.h>
using namespace std;
int main()
{
vector<string> msg {"Hello", "C++", "World", "from", "VS Code", "and the
C++ extension!"};
for (const string& word : msg)
{
cout << word << " ";
}
cout << endl;
}
My problem is that when I try to include a header-file from this path for example Math.h Visual Studio throws an Error
blaze/Math.h: No such file or directory
But when I right-click on the include and click "Go to Definition" VS Code opens the file. Optionbar and the opened file.
The Log-Diagnostics gives that information.
I guess someone that has experience with MinGW and additional packages in VS Code will solve that problem very simple, but I have read nearly every thread about those problems and didn't find anything matching mine.
Okay, i got the answere. The include path of the "c_cpp_properties.json" file is only for IntelliSense. This means that Visual Studio Code will find this packages and IntelliSense will suggest you the available headers from the pathes. This does not mean that the compiler can find these pathes. Therefor you have to add the pathes to the "tasks.json" file. As you can see above in the photo of the "tasks.json" file, there is a field called "args" which means "arguments". Those are the compiler arguments. You have to add the Path there too in Format "-I","C:/PathYouWishToAdd". This works fine!!

How do I transfer my C++ solution made in Visual Studio for Windows to Visual Studio for Mac?

I made a multiple solutions with C++ in Visual Studio at a tech camp on a Windows computer. Unfortunately, I do not have a windows computer at home, so I tried using Visual Studio for Mac 2019. This alert shows up whenever I try to run any of my solutions that says "This project type is not supported by Visual Studio Community 2019 for Mac. When I build the solution, it says it the build is successful, but the run with or without debugging options are grayed out. How can I fix this?
I was able to get it to work using a Windows 10 Parallels, and it said it needed to update the solution because I had made it in Visual Studio 2017. I updated it and it worked, but my program runs very slow. After doing this, it still does not work on Visual Studio for Mac.
Here is my main .cpp file named MyFirstProgram.cpp:
#include "pch.h"
#include "Main.h"
#include <string>
using namespace std;
int main()
{
cout << "My header file works!" << endl;
}
The pch.cpp file:
#include "pch.h"
The pch.h file:
#ifndef PCH_H
#define PCH_H
#endif //PCH_H
And the Main.h file:
#pragma once
#include <iostream>
#include <string>
To build your C++ project using Visual Studio code on Mac, ensure you have C/C++ build tools installed.
Go to your Marketplace on Visual studio, Click on view, select Extensions. Type C++ on the search, and select the extension by Microsoft and install
Create a new project
Copy and paste your codes in a new main.cpp and MyFirstProgram.cpp file.
Try rebuilding
Alternatively, you can use Xcode or Jetbrain CLion on Mac
Another trick to build your cpp program on Mac or Linux without using any heavy IDEs is building a simple task file
**Mac has a g++ compiler **
Create a folder yourDirectoryName
create a file main.cpp (you can copy and paste your codes in here)
create a file json file
** go to the top bar on visual studio, select Terminal > configure Default Build Task > select other**
it would create a hidden json file for you. modify the json file to run your main.cpp file
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "g++",
"args": [
"main.cpp",
"-o",
"${yourDirectoryName}"
],
},
{
"label": "run",
"type": "shell",
"command": "./${yourDirectoryName}",
"dependsOn": [
"build"
],
}
]
}
The task is called run.
to run it, go to terminal, select run task.
click on the task run > continue without scanning the task output

Company-clang mode in emacs on windows

I'm having trouble with the last step in getting clang to work with company-mode on emacs.
I have
(setenv "PATH" (concat (getenv "PATH") ";C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64;C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64\\amd64;"))
(custom-set-variables
'(company-c-headers-path-system
(quote
("c:/users/chowron/Documents/Development/include" "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\include" "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\shared" "C:\\Program Files (x86)\\Windows Kits\\8.1\\Include\\um")))
'(company-clang-arguments
(quote
("-I \"C:\\\\Program Files (x86)\\\\Microsoft Visual Studio 14.0\\\\VC\\\\include\"" "-I \"c:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.10586.0\\\\ucrt\"" "-I \"c:\\\\users\\\\chowron\\\\Documents\\\\Development\\\\include\"")))
'(company-clang-executable
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\ClangC2\\bin\\amd64\\clang.exe")
'(company-clang-insert-arguments nil))
In a simple program like
#include <iostream>
#include <string>
int main(int argc, char** argv) {
std::string food;
food. // Completion at point here
}
I see in clang-error
clang failed with error 1:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ClangC2\bin\amd64\clang.exe -fsyntax-only -Xclang -code-completion-macros -x c++ -I "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\include" -I "c:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.10586.0\\ucrt" -I "c:\\users\\chowron\\Documents\\Development\\include" -Xclang -code-completion-at=-:9:8 -
<stdin>:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
Running this on CMD.exe, however seems to work fine. Using stdin to input the file with a CTRL-Z at the end gives a bunch of warnings and eventually
...
COMPLETION: pop_back : [#void#]pop_back()
COMPLETION: push_back : [#void#]push_back(<#char _Ch#>)
COMPLETION: rbegin : [#reverse_iterator#]rbegin()
COMPLETION: rbegin : [#const_reverse_iterator#]rbegin()[# const#]
...
So I think I have the command line args and paths set up ok within emacs, but there is some setting or emacs function missing?
I found that the issue was in how the include "-I" paths were set. For anyone who might encounter the same problem.
In the .emacs setup, you have to write it like
(quote
("-IC:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\include" "-Ic:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.10586.0\\ucrt" "-Ic:\\users\\chowron\\Documents\\Development\\include" "-v")))
There are no quotes around the 'Program Files (x86)...' paths. Let clang do the interpretation.
As an extra note, this works with the clang bundled with VS2015 Release 2 and upwards at least. It should work with official releases too.

Cannot run Hello World C++ program

I am just starting C++ and downloaded a compiler and an IDE, both eclipse, and tried to make my first C++ program. I use the Hello World C++ Makefile Project, and add the all the stuff on the next page. I then build the program, and the build says this:
12:30:00 **** Build of configuration Default for project HelloWorld! **** make all Cannot run program "make": Launching failed
Error: Program "make" not found in PATH PATH=[C:/Program Files
(x86)/Java/jre1.8.0_91/bin/client;C:/Program Files
(x86)/Java/jre1.8.0_91/bin;C:/Program Files
(x86)/Java/jre1.8.0_91/lib/i386;C:\ProgramData\Oracle\Java\javapath;C:\Program
Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files
(x86)\Common Files\Microsoft Shared\Windows
Live;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;c:\Program
Files (x86)\ATI Technologies\ATI.ACE\Core-Static;c:\Program Files
(x86)\Common Files\Roxio Shared\DLLShared\;c:\Program Files
(x86)\Common Files\Roxio Shared\12.0\DLLShared\;C:\Program Files
(x86)\Windows Live\Shared;c:\Program Files (x86)\Microsoft SQL
Server\100\Tools\Binn\;c:\Program Files (x86)\Microsoft SQL
Server\100\DTS\Binn\;C:\Users\Jen\Desktop\eclipse;] 12:30:00 Build
Finished (took 122ms)***
I run the program, and it says:
Launch failed. Binary not found.
This is the code for the program:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
puts("Hello World!");
return EXIT_SUCCESS;
}
There are two errors, too:
Function "puts" couldn't be resolved.
Symbol "EXIT_SUCCESS" couldn't be resolved.
Thanks in advance!
Nate N.
/////////////////////////////////////////////////////////////////////////
I followed the advise of user4581301 and the code now says this:
#include <iostream>
using namespace std;
int main() {
cout << "Hi World" << endl; // prints Hi World
return 0;
}
The build looks like this:
13:22:26 **** Rebuild of configuration Debug for project HiWorld ****
Info: Internal Builder is used for build
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o "src\HiWorld.o" "..\src\HiWorld.cpp"
g++ -o HiWorld.exe "src\HiWorld.o"
13:22:27 Build Finished (took 835ms)
But now the program, although it does run, doesn't print anything.
Thanks in advance,
Nate N.
Launch failed. Binary not found.
well this is shown because you have 2 errors.
any error means = no binary compiled/linked
no binary compiled/linked = cant launch something which doesnt exist
solution = fixing the errors
#include #include
^ also this is not valid
Cannot run program "make": Launching failed Error: Program "make" not found in PATH
Kaboom! No make, no build, no binary to run.
Some compilers don't ship with Make out of the box, but I don't see any signs of a compiler toolchain in your path at all.
Eclipse is an IDE with support for a wide variety of different compilers. as a result it does not ship with one. Since the error message shows you are building on Windows, your simplest option is one of the many MinGW variants. And Since you are just starting, I recommend starting off with the plain-vanilla MinGW as Eclipse requires next to no extra configuration to use it.
Just make sure you follow the instructions to install msys along with MinGW to get make.

MS link fails from gnu make, but works from cmd line

Recently my gnu makefile stopped linking my C++ project. I had made some changes. I have copied the link line out and run it from a batch file. It builds fine. But the same line strangely fails when I run make. The error it gives is:
LINK : fatal error LNK1181: cannot open input file 'user32.lib'
which has to be a red herring because from the same command line prompt, running the link command succeeds. I am beginning to suspect GNU make. This used to work from within make but I made a few additions and changes to the makefile to get it building on Linux which seemed to introduce the problem.
I am using :
GNU Make 3.80
MS Visual C++ Linker 10.00.40219.01
on Windows XP.
My LIB and LIBPATH both include the path to the SDK directory which contains the libraries. My link command is as follows:
link C:\SDL-1.2.14\lib\SDL.lib C:\SDL-1.2.14\lib\SDLmain.lib C:\SDL-1.2.14\lib\SDL_image.lib C:\SDL-1.2.14\lib\SDL_ttf.lib C:\SDL-1.2.14\lib\SDL_mixer.lib C:\SDL-1.2.14\lib\SDL_net.lib ../../build/lib/sdlhal.lib user32.lib gdi32.lib kernel32.lib oldnames.lib wsock32.lib advapi32.lib comdlg32.lib comctl32.lib wsock32.lib winmm.lib netapi32.lib OpenGL32.lib glu32.lib /nologo /incremental:no -subsystem:console /PDB:../../build/bin/Prog.pdb /OUT:../../build/bin/Prog.exe /MAP:../../build/bin/Prog.map ../../build/Prog/intr/util.obj ../../build/Prog/intr/objwithvel.obj ../../build/Prog/intr/rock.obj ../../build/Prog/intr/explosion.obj ../../build/Prog/intr/ship.obj ../../build/Prog/intr/photon.obj ../../build/Prog/intr/world.obj ../../build/Prog/intr/test.obj ../../build/Prog/intr/main.obj
EDIT: Bit of progress with C++ program below. My Environment variables were:
LIB=C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;C:\Program Files\Microsoft SDKs\Windows\v7.0A\lib;
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;
But when printed out by program run from within make, they are:
LIB=.lib
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\WINDOWS\Microsoft.NETFramework\v3.5;C:\Program Files\Microsoft Visual Studio 10.0\VC\LIB;C:\Program Files\Microsoft Visual Studio 10.0\VC\ATLMFC\LIB;
Based on your description of the value of LIB, I suspect that you have simply set the "LIB" variable in your makefile (to ".lib"). In standard GNU make (actually, all versions of make) all the environment variables are imported into make as make variables when make starts up (there are exceptions, such as SHELL, which are handled differently).
Whenever make invokes a command, all the current values of variables that were imported are written out to the environment of the child process.
Put another way, any variable that make read from its environment is considered to be marked for export when make runs any command from a recipe.
So if you have a makefile like this:
LIB = .lib
all: ; #echo "LIB = %LIB%"
and you run it like this:
> set LIB=C:\foo;C:\bar
> make
then the output will be "LIB = .lib", not "LIB = C:\foo;C:\bar"
I suspect that your LIB and LIBPATH variables aren't set the way you think they are when link is invoked from make.
Try creating your own link.exe program that gets invoked from make and dumps the command line and environment. That'll tell you for certain whether or not the variables are set correctly by the makefile.
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char** argv, char** env)
{
int i = 0;
for (i = 0; i < argc; ++i, ++argv) {
if (!(*argv)) {
*argv = "(null)";
}
printf( "arg[%d]: \"%s\"\n", i, *argv);
}
puts("\nENVIRONMENT...\n");
while (*env) {
printf( "%s\n", *env);
++env;
}
return 0;
}
Also check that there aren't unquoted spaces in the wrong place in the link command line. While it would seem to be unrelated to the error you mention in the question (and is probably really just a cut/paste error), the link command line you gave has a space in the middle of the path/file name for explosion.obj.
This is likely to be a path issue. Are you using the mingw version of GNU make, or the Cygwin version?
One way to debug this is to put an echo $LIB and echo $LIBPATH command into the make recipe to confirm that these are getting set as you expect.