I'm running g++ compiler on windows 10 with mingw.
On checking compiler version in cmd I get the following:
g++ --version- g++ (MinGW.org GCC Build-2) 9.2.0
same with c++ --version
When I compiled a cpp program making use of structured bindings I got a warning:
warning: structured bindings only available with '-std=c++17' or '-std=gnu++17'
But otherwise the code ran fine.
Does everyone get this warning or am I running a lower version compiler?
I'm using an extension - Competitive programming helper, and this warning interrupts the process.
Hence, if it is the case that everyone gets this warning, is there a way I can block version specific warnings only without having to block all compiler warnings.
TIA.
As the warning itself says:
structured bindings only available with '-std=c++17' or '-std=gnu++17'.
Meaning, you are using cpp version 14 or lower as compiler. However, you also have cpp 17 or higher installed on your system to get such kind of warning.
Your program will still run but with the warning.
For Windows:
If you are using VS code (assuming that you are already using code runner) then,
Open Settings(UI) of VS code (Ctrl + ,)
Search for Code-runner: Executor Map
Click on Edit in settings.json
Something like this will appear:
In cpp section: change it to "cd $dir && g++ -std=c++17 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt" as in the picture above.
It is finally done now.
Below steps are for linux.
Open .bashrc file using command sudo gedit ~/.bashrc in terminal.
In the .bashrc file, add alias g++="g++ --std=c++2a" at the end of the file.
This will always compile your file in cpp+20 version.
Once done, you will not get any warning.
Note:
It is not mandatory to use cpp+20. You can use any version you like.
Change the version according to this website
https://www.learncpp.com/cpp-tutorial/configuring-your-compiler-choosing-a-language-standard/
Related
I just switched to ubuntu and I wanted to setup notepad++ for CPP.
So I used the NppExec plugin to compile within notepad++,
My script was :
npp_save
g++ "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART)obj"
./"$(NAME_PART)obj"
Here the "obj" I used is to just save the file with an "obj" keyword nothing else.
The last line ./"$(NAME_PART)obj" is to run the program.
But it looks not working in ubuntu, it produces this error:
NPP_SAVE: Z:\home\username\cpp\test.cpp
g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
; about to start a child process: "g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
CreatProcess() failed with error code 2:
File not found.
./"testobj"
; about to start a child process: "./"testobj""
CreatProcess() failed with error code 2:
File not found.
I have investigated some of what I think is the problem, so I think is the usage of / and \ in changing the directory.
I don't know how to fix that, so I can not be sure.
Any ideas? :) I am using vim btw in the same machine and it is working perfectly.
In theory it might be possible (see below), in practice it is rather convoluted and works only for simple compiles (like single file hello world type).
I would suggest you try a linux program, e.g.
an editor like
scite (same editing engine as notepad++) or
kate
or a real IDE like
kdeveloper or
qtcreator.
The problems with Notepad++ inside wine and g++ outside wine (from the linux install ) are this:
notepad++ inside wine under linux is still a windows program
NppExec can only do, what a cmd inside wine can do.
starting g++ directly inside cmd is an error due to g++ being a linux binary and not a windows binary
that is your CreatProcess() failed with error code 2, it means: you are trying to execute a linux program inside wine.
That does not work! (At least not so easy.)
Though you can start linux program inside cmd inside wine using start /unix ...
started this way, g++ wants linux paths and NppExec through its variables will provide only windows paths (whatever wine has set up as drives like Z:\home\username\src\hello.cpp)
though you can convert wine paths to linux paths via the winepath -u command.
g++ started through 'start /unix ... ' inside a cmd inside wine has no proper terminal to report errors to you
though you can start an xterm for g++ and have g++ reports its messages to the xterm
the downside is that g++ will report errors using the linux paths in the xterm, so you cannot double click on an error message an get to the corresponding filename and line.
You get the idea: its complicated not comfortable.
What worked for me for a helloword.cpp was this NppExec script:
NPP_SAVE
npp_run cmd /c start /unix /usr/bin/xterm -e "/usr/bin/winepath -u '$(FULL_CURRENT_PATH)' | xargs g++ -o /tmp/a.out && /tmp/a.out ; echo 'Press return'; read"
The second line
uses an xterm,
let winepath convert the Z:\home\... path to /home/... and
have that send to g++ for compilation using /tmp/a.out as binary
if compile is successfull, /tmp/a.out is executed
the echo and read are for keeping the xterm open so that you can read the output.
If you really want to use Notepad++ inside wine, one option might be using Gnu Make outside of wine and have NppExec run make all or make run similar to the g++ in my script example. That would work for more complicated compiles.
I am trying to compile the following program:
#include <iostream>
int main(){
std::cout << "Hello, world!";
return 0;
}
When I compile it, I get this message:
C:\programs>g++ test.cpp
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: a
uto-importing has been activated without --enable-auto-import specified on the c
ommand line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.
The build succeeds and the executable runs as expected, but this warning still irritates me. I expect a successful build to be completely silent. This message gives the false impression that there's something wrong with my code.
I can silence this error with g++ -Xlinker --enable-auto-import test.cpp, but this is undesirable, as it triples the number of characters I need to type to compile a program.
Questions:
Why does this warning appear for the simplest of programs? i don't expect cryptic warnings when I compile Hello World.
Is it possible to silence this warning without passing the flag to the linker every time? An option in a config file hidden somewhere in c:\mingw, perhaps? Or maybe I missed an "automatically enable auto-import" checkbox during installation?
Possibly Relevant Specs
GCC Version 4.5.0
ld.exe Version 2.20.51.20100613
Windows XP Service Pack 3
I used to face same problem as you do with g++. I solved this irritating problem just now. Here is how I come to the solution, step-by-step:
On Windows, you can create an alias of g++ with all given options which you want to use with g++. Say, for example, you want to create an alias s++ of g++ -enable-auto-import, then you run this on cmd as:
C:\>doskey s++=g++ -enable-auto-import
This creates an alias called s++. But this alias will not take any command line argument, which means, you cannot write this:
C:\>s++ filename.cpp //it is not working
To make it work, if you've to tell the alias to accept command line arguments while creating it, so here is how it is done:
C:\>doskey s++=g++ -enable-auto-import $*
Please note the $* at the right, which indicates that now s++ can take command line argument:
C:\>s++ filename.cpp //yayyyy..its working now, without giving any warnings!
But you may not prefer to create the alias everytime you open cmd. In that case, you can create a shortcut of cmd.
For example, I created a shortcut called Console and in the Target textbox of shortcut window, I wrote this:
C:\WINDOWS\System32\cmd.exe /K doskey s++=g++ -enable-auto-import $*
And since this is too long (horizontally), one screenshot was not able to capture the entire command. I took two screenshots so that you could see yourself how I did it:
Left part of the command
Right part of the command
For more information on creating aliases on windows, see this:
Creating aliases on Windows
I did some reading and it looks like it might be related to the mingw32 dll not having dllimport attributes defined.
Perhaps there is a patch or you can rebuild mingw32 yourself and add them?
I'm a noob, I admit it. Regardless, I've had a really annoying problem with MinGW.... I can write AND compile programs in C with no problem whatsoever, but recently I've tried to install Cmake, but I can't because it fails every time it tests the C++ compiler (g++). So that lead me to just write a simple "hello world" program in C++ and try to compile it. No dice. Again and again I get no response whatsoever. On the command line, I'm typing
g++ -o hello++.cpp hello++
but have also tried
g++ -o hello++.cxx hello++
g++ -o hello++.cc hello++
g++ -o hello++ hello++.cpp
(Of course I saved copies of the source code in the same directory with the .cxx and .cc extensions respectively)
and a bunch of other combinations thereof. Everytime I get nothing. No warning. No error. Nothing. No .exe file was created in the directory, and typing "hello++" on the command line afterwards just gives me a "command not found" error. Soooo.... what the hell is going on? Why does the gcc command work but the g++ not?
I'm on windows 8, using cygwin.
The last one should have succeeded; you won't get a message saying it's succeeded, but you should see the executable in the current directory. The others all try to take the executable as input and output the source, which won't work; although I'm surprised you don't get error messages.
If it did succeed, then simply typing hello++ is unlikely to run it since the current directory is typically not on the path. Try ./hello++ instead.
If it didn't succeed, then it's possible that g++ isn't installed properly. I'm afraid I've no idea how to fix a broken Cygwin installation. Perhaps which g++, to see which program is actually being run, might give some clues.
I am having trouble compiling Fortran code with references to DISLIN. I have downloaded DISLIN from the website, unzipped the file and ran the setup. I have added an environment variable called DISLIN (C:\dislin) and added C:\dislin\win to the PATH section of my system variables.
I am trying to compile some example code of the DISLIN website which includes line
USE DISLIN
I am using a MinGW shell to compile with command gfortran -o progrname -ldislin EX11_1.f90 and am getting the following error:
Fatal Error: Cant open module file 'dislin.mod' for reading at (1): No such file or directory.
I have tried changing the variable path and even moving the dislin.mod file (which is there) but still get the same message.
Ok I fixed this problem so thought I come back and post what worked for me incase any one else needs it...
Install both DISLIN and MinGW on the c drive
Copy disgf.a from /c/dislin and dislin.f90 from /c/dislin/gf into the directory containing your fortran files
(for me this is /c/MinGW/pnote)
Using the MinGW shell navigate to you files: cd /c/MinGW/pnote
compile dislin.f90 and your fortran program: gfortran -c dislin.f90 progName.f90 (dislin.f90 obviously only needs to be done once)
link libraries etc and compile: gfortran progName.o disgf.a -luser32 -lgdi32 -lopengl32 -o exeName
'run' exeName
You probably need to specify the path to the DISLIN module files:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules
and, if not already configured like described here, also the path to the library itself:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules \
-L/path/to/DISLIN/library
They provide a batch file (windows) to do the compiling and linking for you.
f90link -c My_Program
This is located in c:\dislin\Win
Also, if you are having trouble with the dislin.mod file which resides in c:\dislin\gf then recompile that with the -c compile option. I found all of this info in c:\dislin\readme.inf
near as I can tell (Jan 2018) dislin (64 bit) fails miserably with gfortran 7.2, period; and probably with many other newer compilers.
When trying to link, gfortran 7 says 'dislin.mod' is an unrecognizable format.
I think this program is highly dependent on exactly correct version synchronization - something that renders such software useless imho after many years in research.
and no, the correctness of various 'paths' seems not to help.
after all, gnuplot works, "at all". Not sure why I spent so much time on brand x.
jrc
I'm trying to compile a C++ project (Hello World) in windows 7 using Eclipse Helios. After creating the project the console shows me the next message:
Internal Builder is used for build **
g++ -O0 -g3 -Wall -c -fmessage-length=0 -osrc\hello.o ..\src\hello.cpp
g++ -ohello.exe src\hello.o
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe:
warning: auto-importing has been activated without --enable-auto-import specified on the command line.
If I open the command line and execute: g++ hello.cpp -Wl,-enable-auto-import, I can generate the exe file and I can run it.
In eclipse after adding the argument "-Wl,--enable-auto-import" in the MinGW C++ Linker - Miscellaneous section, I didn't get any warning however, the console is always empty. Again, using the command line, if I move to the directory and execute the exe file generated by eclipse I get the expected result.
I know that Eclipse is compiling the cpp file properly but, why the eclipse console is not displaying the info? Is something missing in the configuration?
Sorry guys my stupid question.
I appreciate your help.
This looks like an environment variable(s) and/or register paths problem.