Thread: why does this crash?

this compiles but crashes! i cant find my mistake (this is the entire code so far)

Code:

#include <iostream>
#include <vector>

using namespace std;

int main(){

vector<int> list;
int counter,temp;


do{
cout<<"Please enter a list of number, -1 to quit"<<endl;
cin>>temp;
list.push_back(temp);
}while(temp!=-1);


return 0;
}

ps: it gives no error code, just opens and close instantly

Probably because you're not entering -1, so the loop quits. Once the loop quits, the program then quits since there is nothing left to do but return 0. There is no crashing. It's just ending because you didn't write your loop condition proplery.

Actually, I misread that. I must be a little blind tonight. The code looks relatively fine, outside of poor indention.

I even ran it myself, and it appears to work.... I don't know what your problem is. Sorry.

Aside from going into an infinite loop on entering a non-number, the code is fine. Are you sure that's exactly what you're compiling?

Originally Posted by MarlonDean

Yes, the problem is my compiler, if i save a file, i must not have a space in the filename eg. project 1.cpp will cause my program to flash

I'm sure the compiler will cope with spaces in the filename, but you may need to quote the filename, e.g.

Code:

 
gcc "my file.c"

If you use:

Code:

gcc my file.c

the compiler will try to compile "my" and "file.c" which will not do the right thing for you if you have a file called "my file.c".

If you use an IDE that doesn't cope with spaces in filenames, that's a bug in the IDE.

Finally, I would say it's a BAD idea to use filenames (or directories) with spaces for programming projects. It tends to lead to all sorts of interesting effects.

--
Mats

Originally Posted by matsp

Finally, I would say it's a BAD idea to use filenames (or directories) with spaces for programming projects. It tends to lead to all sorts of interesting effects.

On a side note, Visual Studio seems to handle spaces in files fine. MFC sometimes tends to generate files with spaces inside. I can't vouch for other IDEs/compilers.

Welcome to the future, manav. The future where IDEs compile our files for us so we don't need to use scripts or command line.

The reason scripting and command line programs continue to exist and be used is because it is easier to implement advanced functionality in them than it is in a interactive program (eg IDE, GUI, etc).

While some development environments make it easier to develop graphical or text based user interfaces than was possible in the past, it is basically easier to parse a string (eg command line input) than it is to respond to various inputs or events associated with a user interface. It is possible to develop an IDE with all the advanced features of a command-line equivalent, but the effort of getting it right (correct "look and feel", correct responses to all possible sets of inputs,all the other things that contribute to "usability") is greater. Getting those sorts of things right requires consistent rules of interface design to achieve usability (an active area of research) and then development of high quality tools that allow development of user-interfaces using those rules (IDE is another area with considerable investment happening) and then programmer discipline to use them (a requirement against which many programmers require a lot of development).

This sort of thing is one of the reasons that vendors like Apple (MacOS attempts to provide all necessary power through GUI, so the user rarely needs to employ a command line program) charge a premium for their products. [And, no, I am not a MacOS user -- I pay less and use windows, but find I must sometimes resort to the command line].

Both Microsoft and Apple, however, are pushing forward GUIs. I don't know about Apple, but Microsoft is certainly trying to push their own techologies on us to make it easier to develop feature-rich and pretty GUIs.
In the future, the line between command line and GUIs is going to blur even more so, I think. And yet, will Linux still retort to their mostly command-line approach, I wonder?

Originally Posted by manav

Just understand one thing, command line and script tools are like a powerful programming language. You can never express in any kind of advanced GUI what you can express in a programming language, for example, say C++.

Nay.
A GUI can express a lot of things a scripted language can, but it depends on the complexity and the aim. Expressing C++ is a GUI would be next to impossible (but DOABLE), but if you have the time and determination, it's possible. I dare say it would be a quality program too, if done right.

The GUI and command line/script tools have completely different benefits and fields of work. Period.

No, no period.
It can be done either ways.
Sure, you can make a compiler command line, but then again, you can make it as a dll or another form of code base - equally possible. It's just that we do not do this for various reasons - but it doesn't mean we cannot, or that it is targetted at a different field of work.
It may just be a bad habit, or disadvantages to it, but it's certainly possible.

You can say it's legacy. We still use old units for physics, for example, or food, even though newer, better units exist. Legacy.