Is there any command like Pause or Nope in C++?

[Luke Meyers]

If ur using turbo c++ .. there is a function in #include<dos.h> called..
delay(int millisec);

Should be what ur looking for. I'm not sure if its in the c++ std.

I think it's not too surprising that <dos.h> is not in the C++
standard.

I suggest using the Boost Timer library.

Luke

 

[Tom]

(Marcus Kwok) wrote:

[snip]

I second this suggestion. Also, it seems not to require the user to
type anything other than the carriage return, plus it avoids the buffer
overrun issue.

The above solution rocks !!

I had not yet used STL (Standard Template Library)
and did a little digging to understand it more fully.

Wow! Another door opens. Using the size function (see below) certainly
convinced me that the above method is very good indeed.

#include <string>
#include <iostream>

void main( )
{
using namespace std;
cout << "input a line of text" << endl;
std::string str;
std::getline(cin,str);
cout << "str: " << str << endl;
cout << "str size: " << (int)str.size() << endl;
}

Type: >return< yields: str size: 0
Type: "Hello World.">return< yields: str size: 12

I also observed that in the Original C++ FAQs that Cline/Lomow took
the effort in FAQ #459 to list a header file for utilizing strings.
This header file resizes the string variable as needed. The header
file is approximately 49 lines of code. Not a trivial task in my
opinion.

There are some other useful functions with the string STL and tons of
other STL's as well. I am tempted to start a thread asking which STL's
people find the most useful. Fact is, I need an education on C++
libraries in general. Guess I'll just lurk a bit and do some more
digging on my own.

==========================

Also, the following MS example demonstrates an easy way to "pause" a
program momentarily. (Versus stop it till you hit return.)

// effects_buffering.cpp
// compile with: EHsc
#include <iostream>
#include <time.h>
using namespace std;

void main( )
{
time_t tm = time( NULL ) + 5;
cout << "Please wait..." << flush;
while ( time( NULL ) < tm )
;
cout << "\nAll done" << endl;
}

 

[Gavin Deane]

#include <string>
#include <iostream>

void main( )
{
using namespace std;
cout << "input a line of text" << endl;
std::string str;
std::getline(cin,str);
cout << "str: " << str << endl;
cout << "str size: " << (int)str.size() << endl;
}

No need to cast the result of size() to an int. It will work perfectly
well without the cast. Since casts should be avoided whenever possible,
best to get rid of it. Also, prefer C++ style casts to C style casts.
They are generally safer and, importantly, much more obvious to a human
reader.

Gavin Deane

 

[Marcelo Pinto]

Tom wrote:

[snip]

#include <string>
#include <iostream>

void main( )

It should be *int main()*

{
using namespace std;
cout << "input a line of text" << endl;
std::string str;
std::getline(cin,str);
cout << "str: " << str << endl;
cout << "str size: " << (int)str.size() << endl;
}

[snip]

HTH,

Marcelo Pinto

 

[Tom]

[snip]

#include <string>
#include <iostream>

void main( )

It should be *int main()*

Please explain why.

I noticed several MS examples of use: void main( )
I've read somewhere that main should return a value, but I thought
that requirement was no longer necessary. The compiler complains
without a return value when the int return is specified ... but the
usage of void produced no errors on compilation or execution.

Thanks.

-- Tom

 

[Sumit Rajan]

I noticed several MS examples of use: void main( )
I've read somewhere that main should return a value, but I thought
that requirement was no longer necessary. The compiler complains
without a return value when the int return is specified ... but the
usage of void produced no errors on compilation or execution.

Please see:
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.3

Regards,
Sumit.

 

[Tom]

No need to cast the result of size() to an int. It will work perfectly
well without the cast. Since casts should be avoided whenever possible,
best to get rid of it. Also, prefer C++ style casts to C style casts.
They are generally safer and, importantly, much more obvious to a human
reader.

Gavin Deane

Thanks for the advice. Without the cast the compiler issued a warning
and I usually aim for zero warnings. Please give me an example of the
preferred cast style. My guess is:

cout << "str size: " << static_cast<int>str.size() << endl;

Given the choice of a compilation warning or making a cast ... what
guidelines should be considered?

-- Tom

 

[Gavin Deane]

Thanks for the advice. Without the cast the compiler issued a warning
and I usually aim for zero warnings.

Good decision IMO.

Please give me an example of the
preferred cast style. My guess is:

cout << "str size: " << static_cast<int>str.size() << endl;

Nearly. The syntax is static_cast<type>(expression) so you just need to
add parentheses

static_cast<int>(str.size() )

I'm surprised you got a warning though. string::size_type will be some
integral type and cout should know what to do with them.

Given the choice of a compilation warning or making a cast ... what
guidelines should be considered?

Well, I always try and compile with the warning level as high as
possible and warnings treated as errors. Code with warnings fails to
compile so the choice I have is not "accept the warning or cast it
away", it is "use a cast or re-examine my design".

If I know exactly what the compiler is warning about and exactly why,
and I am happy that I really do know best, then a cast it is. For
example, sometimes I really do want to truncate a floating point number
and just remember the integer part. In which case

int i = static_cast<int>(double_value);

does what I want.

If the warning surprises me in any way because I thought what I was
doing was OK, then I will take another look at the code to see what I
might have got wrong.

Gavin Deane

 

[Marcelo Pinto]

Tom escreveu:

[snip]

#include <string>
#include <iostream>

void main( )

It should be *int main()*

Please explain why.

I noticed several MS examples of use: void main( )
I've read somewhere that main should return a value, but I thought
that requirement was no longer necessary. The compiler complains
without a return value when the int return is specified ... but the
usage of void produced no errors on compilation or execution.

Thanks.

-- Tom

The C++ Standard (3.6.1) says that there are two forms of a conforming
main function:

int main() { /* ... */ }

and

int main(int argc, char* argv[]) { /* ... */ }

other forms are implementation specific.

Furthermore, note that there is no need for a return statement in main,
as the implementation shall provide a _return 0;_ if no return
statement is encountered at the end of the main function.

I don't know your compiler, but I believe there are switches that you
can turn on/off in order to get conforming messages and the "automatic"
_return 0;_ in the main function.


HTH,

Marcelo Pinto

 

[Richard Herring]

Good decision IMO.


Nearly. The syntax is static_cast<type>(expression) so you just need to
add parentheses

static_cast<int>(str.size() )

I'm surprised you got a warning though. string::size_type will be some
integral type and cout should know what to do with them.

The fact that it doesn't should ring alarm bells. Strictly speaking, the
overloads for operator<< for the basic integral types are declared in
<ostream>. I'd be inclined to try including that header before patching
the problem with casts.

 

[Gavin Deane]

The fact that it doesn't should ring alarm bells. Strictly speaking, the
overloads for operator<< for the basic integral types are declared in
<ostream>. I'd be inclined to try including that header before patching
the problem with casts.

Yes. My intention was just to show the correct syntax for using the
cast. But it could read like I was still recommending the cast.

This is exactly the kind of situation I was thinking of when I wrote

<quote>
If the warning surprises me in any way because I thought what I was
doing was OK, then I will take another look at the code to see what I
might have got wrong.
</quote>

in my previous message, but I didn't link that comment very well to the
code.

Thanks for pointing that out. Hope I've been clearer this time.

Gavin Deane

 

[Tom]

[snip]

The fact that it doesn't should ring alarm bells. Strictly speaking, the
overloads for operator<< for the basic integral types are declared in
<ostream>. I'd be inclined to try including that header before patching
the problem with casts.

The above suggestion is excellent and I learned some more digging
around in it's implementation.

I really like the idea of getting away from the undesirable cast and
the impact it has on the readability of the program; however, the
problem did not disappear as hoped.
=====================================
#include <string>
#include <iostream>
#include <ostream>

void main( )
{
using namespace std;
cout << "the program is now paused ... ";
cout << "any erroneous typing will be discarded" << endl;
cout << "type away if you like and ";
cout << "hit return when ready to continue." << endl;
std::string str;
std::getline(cin,str);
cout << "str: " << str << endl;
cout << "str size: " << static_cast<int>(str.size());
cout << "\n" << flush;
}
=====================================

The addition of:

#include <ostream>

Still generates the warning of a size_t to int for the str.size()
function.

The C++ style:

static_cast<int>(str.size())

works without any warnings.

I see <ostream> defines "flush". Earlier I had problems using "flush"
and resorted to using "endl". Now flush works as advertised. An F1
help with ostream selected shows several Str and char type overloads
for operator<<. No overloads to be found for types: int, double,
size_t, etc. within <ostream>.

My guess is another header is needed and then the cast can disappear?

This newbie hasn't yet found the right header.

====================================

I appreciate the earlier suggestion to use:

int main()

And the kind reference to the electronic FAQs that deals with this
specific issue. I dug around for my "read somewhere" memory and found
it in none other than the Cline/Lomow original text on p.#5, FAQ #10
which states:

"We allow the compiler to supply an implicit int return type for
main(); all other functions have an explicit return type. Also, we
exploit the new C++ feature that requires the compiler to insert an
implicit return 0; at end of main()."

The examples within the original text use:

main() // without int return type.

I need to conform wherever possible for best communication and am
confused now on which is the best practice on such a simple issue. The
MS examples are also without the int return type. The electronic FAQs
is more dated, but more available to the masses.

Perhaps those using various compilers can advise if there is a
portability issue?

Maybe it is a case where both are equally right? They do both work on
the compiler I am using. But lean, clean, and fresh is sure a nice
thing.

-- Tom

 

[Jim Langston]

"We allow the compiler to supply an implicit int return type for
main(); all other functions have an explicit return type. Also, we
exploit the new C++ feature that requires the compiler to insert an
implicit return 0; at end of main()."

The examples within the original text use:

main() // without int return type.

I need to conform wherever possible for best communication and am
confused now on which is the best practice on such a simple issue. The
MS examples are also without the int return type. The electronic FAQs
is more dated, but more available to the masses.

Perhaps those using various compilers can advise if there is a
portability issue?

Maybe it is a case where both are equally right? They do both work on
the compiler I am using. But lean, clean, and fresh is sure a nice
thing.

A function without a return value defaults to an int. I'm not sure of the
specifics as to if it works for methods or not, etc..

so, even though
main()
is correct, that it will be compiled to int main()
int main()
is still more correct and should be used. In fact anytime you post any code
in newsgroups dealing with C++ and you show a main function, if it's not
int main()
someone will tell you to fix it.

 

[Richard Herring]

A function without a return value defaults to an int.

In C, but not C++.

 

[Richard Herring]

I appreciate the earlier suggestion to use:

int main()

And the kind reference to the electronic FAQs that deals with this
specific issue. I dug around for my "read somewhere" memory and found
it in none other than the Cline/Lomow original text on p.#5, FAQ #10
which states:

That must be an ancient copy. The current FAQ on the subject of int
main() is here:

http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.3

"We allow the compiler to supply an implicit int return type for
main();

No such feature in standard C++.

all other functions have an explicit return type. Also, we
exploit the new C++ feature that requires the compiler to insert an
implicit return 0; at end of main()."

But that's OK.

The examples within the original text use:

main() // without int return type.

I need to conform wherever possible for best communication and am
confused now on which is the best practice on such a simple issue.

That's obvious. Follow the Standard.

3.6.1/2: [...] It shall have a return type of type int, but otherwise
its type is implementation-defined. All implementations shall allow both
of the following definitions of main:

int main() { /* ... */ }
and
int main(itn argc, char * argv[]) { /* ... */ }


IOW, it's never wrong (in C++ or C) to use int main()

The
MS examples are also without the int return type. The electronic FAQs
is more dated, but more available to the masses.

Perhaps those using various compilers can advise if there is a
portability issue?

Maybe it is a case where both are equally right?

Depends what you mean by "right". Compliant with the ISO standard, or
compliant with the implementation-specific extensions of a particular
compiler?

 

[Gavin Deane]

The examples within the original text use:

main() // without int return type.

I need to conform wherever possible for best communication and am
confused now on which is the best practice on such a simple issue. The
MS examples are also without the int return type. The electronic FAQs
is more dated, but more available to the masses.

Perhaps those using various compilers can advise if there is a
portability issue?

Maybe it is a case where both are equally right? They do both work on
the compiler I am using. But lean, clean, and fresh is sure a nice
thing.

The C++ standard is very clear. main must have return type int. Any
other return type is wrong and so not portable. implicit int has never
been correct standard C++ so main() with no return type is also wrong
and not portable.

Gavin Deane

 

[Richard Herring]

The addition of:

#include <ostream>

Still generates the warning of a size_t to int for the str.size()
function.

The C++ style:

static_cast<int>(str.size())

works without any warnings.

I see <ostream> defines "flush". Earlier I had problems using "flush"
and resorted to using "endl". Now flush works as advertised. An F1
help with ostream selected shows several Str and char type overloads
for operator<<. No overloads to be found for types: int, double,
size_t, etc. within <ostream>.

Not in the help file, perhaps, but are they actually in the header file
itself? In a compliant implementation there should be overloads for all
the built-in integral and floating-point types. (size_t is just a
typedef for one of the built-in types.)

Oh, and these overloads for the basic types are member functions of
basic_ostream, whereas overloads for strings etc may be non-member free
functions, so they may be in a different section of your documentation.

My guess is another header is needed and then the cast can disappear?

This newbie hasn't yet found the right header.

Or the right compiler?

 

[Marcelo Pinto]

Jim Langston wrote:

[snip]

A function without a return value defaults to an int. I'm not sure of the
specifics as to if it works for methods or not, etc..

[snip]

IIRC, implicit int was depracated in C90. And it is definetely out of
the C99 Standard and of the C++ Standard.

HTH,

Marcelo Pinto.

 

[Default User]

In message <[email protected]>, Jim Langston


In C, but not C++.

And not even in C as of the new standard, although that is spreading
very slowly.




Brian