>I cannot figure out how to open the results/output window in Dev c++.
Assuming I understand what you mean, the output window is a command prompt process that's created when you run your program and terminates when your program ends. Just hit F9 to compile and run, or choose the option you want from the Execute menu. But keep in mind that you'll need to use a trick to keep the window open long enough to read your output. The accepted solution is to ask for input:
#include <ios>
#include <iostream>
#include <limits>
void pause_program ( const char *msg )
{
std::cout<< msg;
// This might not work as advertised
if ( std::cin.rdbuf()->in_avail() > 0 )
std::cin.ignore ( std::numeric_limits<std::streamsize>::max(), '\n' );
std::cin.get();
}
>Also how to effectively use step over / step into
I never liked Dev-C++'s debugging interface. I always drop down to the command line and use gdb directly rather than fiddle with it. ;)
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
System Command- Non-Portable,Very Expensive
>Non-Portable
It is portable, since it's on my laptop I can carry it around with me everywhere I go. :rolleyes:
>Very Expensive
Didn't cost me a dime to use. :rolleyes:
Or am I just clutching at straws here. ;)
iamthwee
Posting Expert
5,950 posts since Aug 2005
Reputation Points: 1,543
Solved Threads: 439
No I was being serious. But thank you for your pity. :sad:
iamthwee
Posting Expert
5,950 posts since Aug 2005
Reputation Points: 1,543
Solved Threads: 439
System Command- Non-Portable,Very Expensive
Are you thinking of the same system() I'm thinking of? Are you thinking? system("PAUSE") is not expensive. The amount of time spent waiting for user input is about 3000000000000000000000000000000000000000000000000000000000000000000000000 times (give or take a few dozen powers of ten) as long as the amount of overhead that system() produces.
Portability is not an issue here; a command line program to be ported to other platforms would have the end-of-program wait-for-input removed anyway.
Rashakil Fol
Super Senior Demiposter
2,658 posts since Jun 2005
Reputation Points: 1,135
Solved Threads: 177
Series of steps performed by system()
1.Suspend your program
2.Call the operating system
3.Open an operating system shell (relaunches the O/S in a
sub-process)
4.The O/S must now find the PAUSE command
5.Allocate the memory to execute the command
6.Execute the command and wait for a keystroke
7.Deallocate the memory
8.Exit the OS
9.Resume your program
Well to speed things up you could use an inline function or macro a la:
#include <iostream.h>
#include <conio.h>
#define paws system("PAUSE");
void main()
{
//do stuff
paws
}
Now it's fast and easy to use.The argument to the 'system()' function is necessarily platform-specific, so 'hardcoding' such a command reduces portability.
I don't understand. The system command is available on my laptop which uses xp, this means I can carry it everywhere I go. I no that there are portability issues with PCs (they tend to be large and cumbersome so limit portability is this what you mean? I tried carrying that and almost broke my back :confused: ).some systems might not have a command processor at all
I had one of those systems but when I realised I couldn't do anything with it I knew it twas pointless.
iamthwee
Posting Expert
5,950 posts since Aug 2005
Reputation Points: 1,543
Solved Threads: 439
Great thanx for clearing that up! Another mystery has been unveiled. You know your stuff.
BTW you do get what irony is don't you. :rolleyes:
Meh, I've had my fun for the day.
iamthwee
Posting Expert
5,950 posts since Aug 2005
Reputation Points: 1,543
Solved Threads: 439
>Series of steps performed by system()
I'm sorry, I fail to see how the speed of system is in any way relevant to halting the process so that the user has time to read the output.
>Now I(and others) just came to know how you program.
It seems he programs with a reasonable perspective. You don't optimize when the program is waiting on the user. You *do* optimize when the user is waiting on the program. Simple.
>'hardcoding' such a command reduces portability.
Yes, and so far this is your only valid complaint.
>Not all systems have a 'pause' command, and those that do might not give it the same meaning
Or someone could replace the pause command with a malicious program. You forgot to mention that system has security issues.
>also, some systems might not have a command processor at all
In which case the call is a harmless no-op.
>Inline function is just a request to compiler...
It is? I thought it was a preprocessing directive that gets performed before the compiler is ever called. Now, you can argue that some compilers are wholistic rather than a collection of separate tools, but the preprocessing step is still completely independent of the compilation step, and mixing them up can introduce conceptual confusion that affects your reputation around here. ;)
>Anyways your total code is non-standard and won't even compile.
I wonder how long it would take you to realize that iamthwee has been baiting you.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401
>But why should I use such a resource heavy call when I can have better alternatives as suggested by you.
Now you're presenting a better case. :) Rather than avoiding system because system is slow (which is a nebulous argument at best under the circumstances), you're advocating avoiding system because there are better alternatives. The difference is subtle, but significant.
>I never knew or thought it to be a preprocessor directive.
It's not (at least not logically; the point is irrelevant because it's an implementation detail), and I admit that I missed the part of iamthwee's post that said "inline function". I zeroed in on the code that he posted, which used a preprocessor macro and to which my comments were accurate. For the inline function part, feel free to ignore me. :)
>I would really like to know more about inline functions being preprocessor directive as said by you.
An implementation is free to preprocess inline functions into inline code, much like a preprocessor macro. In fact, a good compiler probably will. It's not quite the same because some amount of lexical analysis has to be done to determine whether to take the hint (and how to go about the inlining) or ignore it, and that's extremely likely to be after the preprocessing step but before the compilation step.
Narue
Bad Cop
15,460 posts since Sep 2004
Reputation Points: 6,464
Solved Threads: 1,401