Running an .exe file

[bld]

Hello,
I've been experimenting with the MinGW C++ compiler recently. So I made a simple 'Hello, World!' program and compiled it into an .exe file. But when I tried to open it the command prompt just popped up and disappeared quickly. But I was able to run the program by typing programname.exe into the command prompt directly

Is this normal?

Here is the code:

#include <iostream>
#include <string>

using namespace std;

int main() {
	cout << "Hello, World!\n";
}

[jlb]

You may want to read this topic for some information about this "problem" :

http://www.cplusplus.com/forum/beginner/1988/

[bld]

Well, I'm not using an IDE. I write my code in Sublime Text 3 and I compile it through the command prompt. Anyways, this is normal, right? I'm happy, that I got MinGW working and I'm worried, that I messed up somewhere.

[Ganado]

But I was able to run the program by typing programname.exe into the command prompt directly

Yes, this is normal.

When a program ends, it closes. Since you ran a console application that had no console, Windows creates a temporary console for it, which disappears once the program ends.

When you run the program inside an existing command prompt, like cmd, a console already exists, so no temporary consoles are needed.

[bld]

I see, thanks for the help!

Edit: I have two more questions:

1. Do I HAVE to set the PATH variable, after installing MinGW and all the required packages? I can just type cd c:/mingw/bin into the command prompt and it should work fine, right?

2. I know, that this is stupid, but my antivirus (Avast) blocked my 'Hello, World!' program and marked it as a trojan. Is there anything I should be worried about?

[bld]

I've made some edits to my last reply.

[jlb]

2. I know, that this is stupid, but my antivirus (Avast) blocked my 'Hello, World!' program and marked it as a trojan. Is there anything I should be worried about?

This is probably because your antivirus program isn't setup properly for your build directories. Make sure you don't put your project files into any of the mingw directories. I don't remember exactly where, but the projects should be somewhere in your "personal" directories and then modify the Avast configuration to exclude those directories from being scanned.

[bld]

Oh, and how about the first question, with the path variables?

[jlb]

Doesn't the installer automatically add the bin directory to the path?

By the way what Mingw did you install, from what location?

[bld]

I got MinGW from it's website and I had to add the path variable manually. But I'd like to know, if I have to add the path variable for the compiler to work. I can just type cd c:/mingw/bin and it should work, right?

[lastchance]

Create a batch file, say: setgcc.bat
that contains

set PATH=C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;%PATH%

(Alter that statement to point to wherever your binaries are for YOUR compilers).
Put this file anywhere in your current path. (I create a c:\util directory to do precisely this for various programs).


When you want to do some programming:
Open a cmd window.
Go to whichever folder your source files are (or wherever you want to create them) and enter
setgcc
This will put all your compiler stuff in the current path FOR THIS SESSION ONLY, so keeping your usual search path quite short.

Now you can use whatever editor you like (just notepad try.cpp would do) and compile to your heart's content:
g++ try.cpp
gfortran try.f90
etc.

By default, it creates an executable a.exe which you can run in the command window by simply typing
a.exe
or even just
a
There are compiler options to change the name of the executable, or you can do it manually.


Now, isn't that simpler than the bloat that comes with Visual Studio and its "projects" nonsense?

[bld]

I don't need a tutorial about setting up the path variables and I don't use VS. I just want to know, if I can use the compiler without setting the path variable by just typing for example: cd c:/mingw/bin g++ test.cpp -o test.exe - Is this going to work?

[lastchance]

Why don't you just try it then?

The difficulty here is that g++ is just a wrapper to the underlying compiler, all of whose components (and possibly libraries) need to be found.

It would be a VERY bad idea to dump all your own files within the bin directory. The best thing by far would be to (temporarily) change the path variable.

But feel free to ignore all this; it's your PC.

[bld]

But feel free to ignore all this; it's your PC.

Well, it works, but could it damage my PC in any way?

[jonnin]

no.
you may damage the g++ or mingw software, but not the operating system or hardware or anything like that. Most likely outcome is an unholy mess that can't be untangled from the compiler, which is fine if you are just screwing around on your own machine with your own code. I used to, as a kid, put stuff in the dos/windows OS system root folders just to avoid pathing it out. It worked, but it was a mess -- trying to update / upgrade / anything broke it and getting it going again was no fun. Same thing here, it works until you upgrade your g++ and have to figure out what belongs to the old software and what belongs to your compiles.

If you did something like this professionally, you would likely get a wipe and reload of your machine if something broke, and if you have neve experienced a corporate reload -- you lose 2-3 days and have to work a weekend or something...

[bld]

I didn't put anything in the system root folder, I installed MinGW in the default C:\MinGW directory and then I loaded it by typing cd c:/mingw/bin into the command prompt. I don't see the problem here, afaik changing the path variable only lets the system know, where is the compiler located, so i don't have to input the cd c:/mingw/bin thing every time.

But feel free to correct me, if I'm wrong, this stuff is still pretty new to me.

[lastchance]

If you type
cd c:\mingw\bin
into the command prompt then you will be doing all your work in the actual program directory. So your source files, input/output files and executable files will get muddled up with the compiler binaries and libraries, you will have difficulty ever tidying up the folder because you risk deleting compiler files, you will have problems upgrading, ... do I need to go on?

No, you won't damage your computer in any way shape or form, but you will probably end up with a hopelessly unmanageable muddle.

If c:\mingw\bin is where your compiler's binaries are, then having a simple batch file that will change the path variable JUST for that command session is a far better approach; so, for your layout, in (e.g.) setgcc.bat:

set PATH=c:\mingw\bin;%PATH%

This will temporarily - and only temporarily - put the MinGW files into your path.

Outside of that command window, and also once that command window is closed, your PATH variable will be exactly the same as it ever was when MinGW didn't exist.

[bld]

If you type
cd c:\mingw\bin
into the command prompt then you will be doing all your work in the actual program directory. So your source, input/out and executable files will get muddled up with the compiler binaries and libraries, you will have difficulty ever tidying up the folder because you risk deleting compiler files, you will have problems upgrading, ... do I need to go on?

Oh, now I see! Anyways, if I put c:/mingw/bin in the path variable I shouldn't run into any issues with mixing my files and the compiler files, right? Because making a batch file that temporarily sets the path variable is not something I want.

[jonnin]

putting it in the path variable makes it always accessible. So you can compile and run your programs in your own folder, all organized and neat like, without any fuss (and run from any folder if you move working programs out to other places). This is likely what you want, assuming you save and compile into your own working folder and not into the compiler's folders. This has its own aggravations; you pass your progams to anyone else and you may need to find what libraries it uses to give to them. I know I have to hand users 3 or 4 dlls for everything I compile, but this varies from compiler to compiler, just don't forget to bundle it up if you pass something to another machine. You would have wanted to do that the other way too; no one wants the full ming / bin folder in a zip file to run hello world.

I use the batch file thing too, and change the header of the console session to tell me which one I ran last (I have one for java, nodejs, python, c++, and maybe one or two more rarely used). I would rather put it in the true path and forget it, but several of my languages (not c++) have multiple versions for various tools that each have their own special snowflake copy and things get broken if I mess with the real path, so I have a temporary path. C++ is much, much more friendly about breaking things; very few programs write c++ and compile it in the middle of their operations and most of the ones that do are less idiotic about using the path settings to find the compiler and just use their own without having to be told where it lives. I don't see any big reason to do the batch file thing for c++ on most machines.

[lastchance]

You are fine to put c:\mingw\bin in the path variable. But if you use lots of different software, and they all do the same thing, then
(a) the path can get very long (so increasing search times);
(b) you increase the risk that if you have two programs with the same executable name (yes, it happens!) in different parts of the path you may end up running the one that was found first and not the one intended. (There are a surprising number of different convert.exe files on my computer, for example).

So, my personal opinion is that you keep the main search path short, and only fix the main system folders in it. Use temporary path extenders for everything else. Of course, c++ may be an absolutely vital part of your life, in which case by all means put it permanently at the front of the path.