I just want to try c++ coding with Visual Studio code. I have installed vscode 1.18.1 to my laptop (Win10-64).
I got errors by typing following code:
#include <iostream>
using namespace std;
int main()
{
std::cout << "Hello world!" <<endl;
return 0;
}
Should happen no Error. C:\Users\Harri\OneDrive\Tiedostot\Demo2.vscode\c_cpp_properties.json -content:
"path": [
"/usr/include",
"/usr/local/include",
"${workspaceRoot}"
],
Problems/Errors for row 1:
" #include errors detected. Please update your includePath. IntelliSense features for this translation unit (C:\Users\Harri\OneDrive\Tiedostot\Demo2\Calc.cpp) will be provided by the Tag Parser. "
" cannot open source file "iostream" "
The main problem is cygwin paths
You have cygwin paths like /usr/include in your c_cpp_properties.json file. That is a problem because VSCode does not understand cygwin paths. At a cygwin shell you can run:
$ cygpath -w /usr/include
D:\cygwin64\usr\include
to get the equivalent Windows path. Put that into c_cpp_properties.json instead. Remember that you have to double the backslashes when you copy this into a JSON string.
Other suggestions
This SO answer describes how to set up VSCode with cygwin gcc. I haven't tried those instructions but they look reasonable.
Beyond that, I highly recommend going through the Get Started with C++ tutorial on the VSCode site. It might directly answer your question, but even if it doesn't, having a working setup to compare to is valuable.
Also, look at the C/C++ diagnostics: View → Command Palette... → C/C++: Log Diagnostics. This will show things like which compiler VSCode is trying to emulate and what it thinks the #include paths are.
Finally, to get lots of useful information directly from your compiler to compare with what VSCode thinks, if you are using gcc, run at a cygwin or bash prompt:
$ touch empty.c
$ gcc -v -E -dD empty.c > compiler-info.txt
That will write to compiler-info.txt all the predefined macros, #include search paths, default target, etc.
For some reason iosteam is a typo
Try using instead. It worked for me.
Working Code Screenshot
Related
I'm trying to compile and run the following simple cuda example in VS2012 with a makefile:
#include <thrust/device_vector.h>
#include <thrust/device_ptr.h>
int main()
{
thrust::device_vector<double> my_new_vector(10); // create a vector of size 10
}
My makefile is very simple and just compiles it successfuly. When running the executable, it crashes! It seems it does not like device_vector. I'm running it with Windows 7/CUDA 8.0/VS2012. I have got the same error with CUDA 7.5. If I replace the line by a simple std::cout << "hello world!\n";it will run perfectly.
Is there any reason why device_vectordoes not work?
I just needed to change the --gpu-name option. Now it works!
I am pretty new to linux and i wanted to try to make a small opengl
program just as a test. I'm using glfw and i made a very easy test:
#include <iostream>
#include <GL/glew.h>
#include <GLFW/glfw3.h>
using namespace std;
int main()
{
if (!glfwInit())
{
return -1;
}
GLFWwindow *window = glfwCreateWindow(800, 600, "Het werkt", NULL, NULL);
if (!window)
{
glfwTerminate();
}
glfwMakeContextCurrent(window);
while (!glfwWindowShouldClose(window))
{
glfwPollEvents();
glfwSwapBuffers(window);
}
}
Now if i try to run this in Code::Blocks itself, it runs fine, debug, release, it doesn't matter, it works. But when i try to execute it outside Code::Blocks, it goes wrong. If i double click the executable nothing happens, and if i ./ExecutableName in the terminal it gives me this error:
error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
All of the libs are in the same directory as the executable, so i don't get why it gives this error.
By the way i'm working on Linux Mint.
Thanks in advance for your help!
You should place those libraries in your $PATH. Issue a echo $PATH command and see if you can find the libraries in there (within those paths) - if not, you will have to put them in there someway. I'm not sure if you can just copy-paste the libraries in there, so probably you may want to search for them using your linux distribution's package management system. As you are using Linux Mint, maybe you could try searching with sudo aptitude search glfw and then try installing the corresponding packages.
I installed VS2012 today and started learning C++.
I wrote a Hello World program with #include <iostream.h>.
On build I get the error; C1083: Can not open include file... I believe this is an include path problem.
I tried editing the Include Directories in the VC++ Property Page but nothing I try works. Currently the include directories path has :
$(VCInstallDir)include
$(VCInstallDir)atlmfc\include
$(WindowsSDK_IncludePath)
Any thoughts on how to fix?
It's not <iostream.h>, it's just <iostream>.
For standard c++ headers you must not put the .h so :
#include <iostream.h>
should become :
#include <iostream>
After that, if you are beginning with cplusplus, here is a link with the standard library headers (and articles about c++). It is a great help to have this website : http://www.cplusplus.com/reference/
I copied clang_complete.vim to plugin, but when I typed . after some variable, it says:
pattern not found
I searched this issue, and somebody said I should configure g:clang_complete_auto: and g:clang_complete_copen:. How can I do this?
I had the same problem and resolved it by adding the following to my .vimrc
let g:clang_user_options='|| exit 0'
Try opening a sample file
vim /tmp/sample.cpp
and enter some cpp code
#include <iostream>
int main() {
std:: // <-- this should complete
}
Note that you actually need to include the headers, since completion is done with the compiler. If this works, but your project still keeps saying "Pattern not found" then clang++ is probably not able to compile your project. Do you use any -I switches when you compile your code? Add them to a file named .clang_complete in your project directory.
For me this works fine with my .vim/plugin folder containing only the clang_complete.vim file that is available for download:
$ find .vim
.vim
.vim/plugin
.vim/plugin/clang_complete.vim
... but in this issue report https://github.com/Rip-Rip/clang_complete/issues/39 it is suggested that you might need more than that file (additional files are in the git repo).
The following got things working for me on Cygwin using clang version 3.0 (tags/RELEASE_30/final), as well as on Windows using the Clang build instructions and a version checked out from trunk (usually stable, as I've read) yesterday (clang version 3.1 (trunk 154056)) and built with Visual Studio 2010:
" clang_complete
let g:clang_complete_auto = 0
let g:clang_complete_copen = 1
" :h clang_complete-auto_user_options
if has('win32unix') " Cygwin
" Using libclang requires a Vim built with +python
let g:clang_use_library = 1
" Mit der Option "gcc" kriege ich Fehler.
" Remove "gcc" option as it causes errors.
let g:clang_auto_user_options='path, .clang_complete'
elseif has('win32') " Windows
let g:clang_auto_user_options='path, .clang_complete'
let g:clang_use_library = 1
let g:clang_library_path='D:\Sourcen\LLVM\build\bin\Debug'
endif
Note that the Windows version may have sporadic assertion failures but works fine, although not exactly like the Cygwin version. Guess it's to do with using MSVC versus GCC header files.
The Cygwin version has an initial error: release unlocked lock, but it works regardless.
Did you try to compile the code outside Vim, by explicitly invoking Clang on the command-line?
I had the same problem with my code, but it turns out Clang was not able to compile my code due to usage of the MPI libraries (mpich2). Maybe a similar problem is causing Clang to fail in your case? In my case, if I remove the MPI-dependencies, everything works fine, for example in something like:
#include <iostream>
#include <string>
int main() {
std::string myString("test string");
std::cout << myString.size() << std::endl; // After typing the dot, I get a list of std::string methods
}
By-the-way, I still miss clang_complete in my MPI code. Did anyone find a solution for this?
To configure Vim, you must find or create your .vimrc file:
$ vim ~/.vimrc
Then enter:
let g:clang_complete_copen = 1
I am trying to get PhysX working using Ubuntu.
First, I downloaded the SDK here:
http://developer.download.nvidia.com/PhysX/2.8.1/PhysX_2.8.1_SDK_CoreLinux_deb.tar.gz
Next, I extracted the files and installed each package with:
dpkg -i filename.deb
This gives me the following files located in /usr/lib/PhysX/v2.8.1:
libNxCharacter.so
libNxCooking.so
libPhysXCore.so
libNxCharacter.so.1
libNxCooking.so.1
libPhysXCore.so.1
Next, I created symbolic links to /usr/lib:
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCharacter.so.1 /usr/lib/libNxCharacter.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCooking.so.1 /usr/lib/libNxCooking.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libPhysXCore.so.1 /usr/lib/libPhysXCore.so.1
Now, using Eclipse, I have specified the following libraries (-l):
libNxCharacter.so.1
libNxCooking.so.1
libPhysXCore.so.1
And the following search paths just in case (-L):
/usr/lib/PhysX/v2.8.1
/usr/lib
Also, as Gerald Kaszuba suggested, I added the following include paths (-I):
/usr/lib/PhysX/v2.8.1
/usr/lib
Then, I attempted to compile the following code:
#include "NxPhysics.h"
NxPhysicsSDK* gPhysicsSDK = NULL;
NxScene* gScene = NULL;
NxVec3 gDefaultGravity(0,-9.8,0);
void InitNx()
{
gPhysicsSDK = NxCreatePhysicsSDK(NX_PHYSICS_SDK_VERSION);
if (!gPhysicsSDK)
{
std::cout<<"Error"<<std::endl;
return;
}
NxSceneDesc sceneDesc;
sceneDesc.gravity = gDefaultGravity;
gScene = gPhysicsSDK->createScene(sceneDesc);
}
int main(int arc, char** argv)
{
InitNx();
return 0;
}
The first error I get is:
NxPhysics.h: No such file or directory
Which tells me that the project is obviously not linking properly. Can anyone tell me what I have done wrong, or what else I need to do to get my project to compile? I am using the GCC C++ Compiler. Thanks in advance!
It looks like you're confusing header files with library files. NxPhysics.h is a source code header file. Header files are needed when compiling source code (not when linking). It's probably located in a place like /usr/include or /usr/include/PhysX/v2.8.1, or similar. Find the real location of this file and make sure you use the -I option to tell the compiler where it is, as Gerald Kaszuba suggests.
The libraries are needed when linking the compiled object files (and not when compiling). You'll need to deal with this later with the -L and -l options.
Note: depending on how you invoke gcc, you can have it do compiling and then linking with a single invocation, but behind the scenes it still does a compile step then a link step.
EDIT: Extra explanation added...
When building a binary using a C/C++ compiler, the compiler reads the source code (.c or .cpp files). While reading it, there are frequently #include statements that are used to read .h files. The #include statements give the names of files that must be loaded. Those exact files must exist in the include path. In your case, a file with the exact name "NxPhysics.h" must be found somewhere in the include path. Typically, /usr/include is in the path by default, and so is the current directory. If the headers are somewhere else such as a subdirectory of /usr/include, then you always need to explicitly tell the compiler where to look using the -I command-line switches (or sometimes with environment variables or other system configuration methods).
A .h header file typically includes data structure declarations, inline function definitions, function and class declarations, and #define macros. When the compilation is done, a .o object file is created. The compiler does not know about .so or .a libraries and cannot use them in any way, other than to embed a little bit of helper information for the linker. Note that the compiler also embeds some "header" information in the object files. I put "header" in quotes because the information only roughly corresponds to what may or may not be found in the .h files. It includes a binary representation of all exported declarations. No macros are found there. I believe that inline functions are omitted as well (though I could be wrong there).
Once all of the .o files exist, it is time for another program to take over: the linker. The linker knows nothing of source code files or .h header files. It only cares about binary libraries and object files. You give it a collection of libraries and object files. In their "headers" they list what things (data types, functions, etc.) they define and what things they need someone else to define. The linker then matches up requests for definitions from one module with actual definitions for other modules. It checks to make sure there aren't multiple conflicting definitions, and if building an executable, it makes sure that all requests for definitions are fulfilled.
There are some notable caveats to the above description. First, it is possible to call gcc once and get it to do both compiling and linking, e.g.
gcc hello.c -o hello
will first compile hello.c to memory or to a temporary file, then it will link against the standard libraries and write out the hello executable. Even though it's only one call to gcc, both steps are still being performed sequentially, as a convenience to you. I'll skip describing some of the details of dynamic libraries for now.
If you're a Java programmer, then some of the above might be a little confusing. I believe that .net works like Java, so the following discussion should apply to C# and the other .net languages. Java is syntactically a much simpler language than C and C++. It lacks macros and it lacks true templates (generics are a very weak form of templates). Because of this, Java skips the need for separate declaration (.h) and definition (.c) files. It is also able to embed all the relevant information in the object file (.class for Java). This makes it so that both the compiler and the linker can use the .class files directly.
The problem was indeed with my include paths. Here is the relevant command:
g++ -I/usr/include/PhysX/v2.8.1/SDKs/PhysXLoader/include -I/usr/include -I/usr/include/PhysX/v2.8.1/LowLevel/API/include -I/usr/include/PhysX/v2.8.1/LowLevel/hlcommon/include -I/usr/include/PhysX/v2.8.1/SDKs/Foundation/include -I/usr/include/PhysX/v2.8.1/SDKs/Cooking/include -I/usr/include/PhysX/v2.8.1/SDKs/NxCharacter/include -I/usr/include/PhysX/v2.8.1/SDKs/Physics/include -O0 -g3 -DNX_DISABLE_FLUIDS -DLINUX -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp"
Also, for the linker, only "PhysXLoader" was needed (same as Windows). Thus, I have:
g++ -o"PhysXSetupTest" ./main.o -lglut -lPhysXLoader
While installing I got the following error
*
dpkg: dependency problems prevent configuration of libphysx-dev-2.8.1:
libphysx-dev-2.8.1 depends on libphysx-2.8.1 (= 2.8.1-4); however:
Package libphysx-2.8.1 is not configured yet.
dpkg: error processing libphysx-dev-2.8.1 (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
*
So I reinstalled *libphysx-2.8.1_4_i386.deb*
sudo dpkg -i libphysx-2.8.1_4_i386.deb