How to use Dev C++

Please reply.

Please reply.

Don't bump your thread. Everyone here is helping others on voluntary basis by finding whatever time they are free to spare.

I cannot figure out how to open the results/output window in Dev c++. Also how to effectively use step over / step into . I kept breakpoints at certain points in my program but step over from then onwards does not happen by pressing ctrl+f7 and I dont know how to do it . I am using
Dev C++ 4.9.9.2 version .

Did you tried looking at the help file of DEV.

>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. ;)

i use Dev C++ and a simple

int main() {
............
............

system ("pause");
return 0;
}

keeps the window open for me to see the results.

i use Dev C++ and a simple

int main() {
............
............

system ("pause");
return 0;
}

keeps the window open for me to see the results.

System Command- Non-Portable,Very Expensive

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. ;)

>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. ;)

If your intent was to make people laugh then I guess you succeeded...otherwise I pity on you.

No I was being serious. But thank you for your pity. :sad:

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.

system("PAUSE") is not expensive.

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

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.

Now I(and others) just came to know how you program.

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.

The argument to the 'system()' function is necessarily platform-specific, so 'hardcoding' such a command reduces portability.

Not all systems have a 'pause' command, and those that do might not give it the same meaning; also, some systems might not have a command processor at all (in which case 'system()' returns a value indicating such)

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.

Well to speed things up you could use an inline function

Inline function is just a request to compiler...Don't be so sure about that.
But how did inline function come here...I guess it's off topic.

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.

May I know how.?
In this preprocessor is simply replacing paws with system(...) command.
Anyways your total code is non-standard and won't even compile.

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: ).

:)

Portable computer programs can be run with little or no change on many kinds of computer systems.
This is what I meant.

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.

>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.

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.

But why should I use such a resource heavy call when I can have better alternatives as suggested by you.
I just wanted to bring that to the notice.

It seems he programs with a reasonable perspective.

If you say so.

Yes, and so far this is your only valid complaint.

Thank God...atleast something from my post satisfied you(which is actually very difficult)

Or someone could replace the pause command with a malicious program. You forgot to mention that system has security issues.

I knew when you'll read this thread, you'll fill up the missing links ;)

In which case the call is a harmless no-op.

Harmless and doesn't even solve the basic purpose which is what I was advocating regarding portability.

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. ;)

It is a request that the compiler is allowed to ignore.

The inline specifier is a hint to the compiler that it should attempt to generate code for a call of
fac() inline rather than laying down the code for the function once and then calling through the
usual function call mechanism. A clever compiler can generate the constant 720 for a call fac(6).The possibility of mutually recursive inline functions, inline functions that recurse or not depending on input, etc., makes it impossible to guarantee that every call of an inline function is actually inlined. The degree of cleverness of a compiler cannot be legislated, so one compiler might generate 720, another 6*fac(5), and yet another an uninlined call fac(6).

So by reading above paragraph what I understood was Inline functions are handled by compiler but how it handles depends upon its cleverness
I never knew or thought it to be a preprocessor directive.

Yours and Dave's post are the best posts I feel in this forum, so I respect what you say(there must be some reasoning behind it) and I would really like to know more about inline functions being preprocessor directive as said by you.

I wonder how long it would take you to realize that iamthwee has been baiting you.

I thought about that(because I have seen iamthwee commenting on other people's code regarding using of non-standard codes) but I intentionally chose to answer this. Though I am very begginer in C/C++, but I thought maybe my post can help some other new posters.

>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.

getchar()

follow this basic program structure and you can get the answer
#include <iostream>
#include <conio.h>

using namespace std;

int main ()
{
cout << "Hello World! ";
getch();
return 0;
}