Thread: Istream cin vs. cin.get

Use this:

Code:

#include <iostream>
#include <limits>

using namespace std;
 
int main()
{
    char str1[30];
    char str2[30] ;
    cin >> str1 ;
    //cout.flush();
    cin.ignore ( numeric_limits<streamsize>::max(), '\n' );
    cin.get(str2,30);
    system("Pause");
}

After cin>> str1, newline character stayed in the input stream.
That's why you can use ignore member function!

>cin.ignore ( numeric_limits<streamsize>::max(), '\n' );
To be strictly correct you should include <ios> for streamsize.

Originally Posted by Prelude

>cin.ignore ( numeric_limits<streamsize>::max(), '\n' );
To be strictly correct you should include <ios> for streamsize.

Does that mean this code won't compile on some other compilers because of this?

I'll appreciated if a little explain numeric_limits<>::max()
anyway , it was helpful ,thx

>Does that mean this code won't compile on some other compilers because of this?
It means that the standard doesn't require it to. However, I have yet to see an iostream header that doesn't include ios in some way, shape, or form. But that too isn't required, it just happens to be the case on every compiler I've seen.

>I'll appreciated if a little explain numeric_limits<>::max()
numeric_limits is a template class that's specialized for different types. There are several properties of each type, but let's just say that there's only max and min for the sake of my carpal tunnel. numeric limits would be defined like this:

Code:

namespace std {
  template <typename T>
  class numeric_limits {
    static T min();
    static T max();
  };
}

Then it would be specialized for each type supported. Let's say int and char:

Code:

#include <climits>

namespace std {
  template <>
  class numeric_limits<int> {
    static T min() { return INT_MIN; }
    static T max() { return INT_MAX; }
  };

  template <>
  class numeric_limits<char> {
    static T min() { return CHAR_MIN; }
    static T max() { return CHAR_MAX; }
  };
}

Repeat for all other types you want to support and you have a convenient and consistent interface for the arithmetic properties of various types.

I think that

Code:

numeric_limits<streamsize>::max()

is same as

Code:

numeric_limits<int>::max()

At least, it's on every compiler I checked...

It may be so, but...

1. Makes little sense to check for int when we want to check for stream.

2. Did you check enough compilers and enough operating systems? What if one fails?

Many other examples there are where one could possibly check against names other than those specified by the implementation. For instance, size_type is known to be an unsigned integral type. So, it's possible to believe that checking against a unsigned long will be enough to know how many elements a container can hold. Or is it an int? Or is it something else specified by the compiler?

>I think that
>numeric_limits<streamsize>::max()
>is same as
>numeric_limits<int>::max()
It may be. Then again, it may not be. Typedef's are there are a reason, and you should take advantage of them if you want portable code.

Have you checked on GCC for 64-bit systems?

Originally Posted by CornedBee

Have you checked on GCC for 64-bit systems?

No I didn't check on any 64-bit system.
From what I have read here and in other threads I can conclude that there will be a lot of problems when porting existing C/C++ code on 64 bit systems. I'm not C/C++ programmer, but it seems to me that many of them are not really addicted to the standard.

Thank you for your explanations

Originally Posted by Micko

From what I have read here and in other threads I can conclude that there will be a lot of problems when porting existing C/C++ code on 64 bit systems.

Only poorly written code. Code that relies on the size of a built-in data type, when no C or C++ standard ever made any guarantees about it, or about data types being the same size.