Hi
Why the cin.get() doesn't work ?Code:char str1[30]; char str2[30] ; cin >> str1 ; //cout.flush(); cin.get(str2,30);
Thanks .
Hi
Why the cin.get() doesn't work ?Code:char str1[30]; char str2[30] ; cin >> str1 ; //cout.flush(); cin.get(str2,30);
Thanks .
Use this:
After cin>> str1, newline character stayed in the input stream.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"); }
That's why you can use ignore member function!
Last edited by Micko; 08-30-2006 at 11:05 PM.
Gotta love the "please fix this for me, but I'm not going to tell you which functions we're allowed to use" posts.
It's like teaching people to walk by first breaking their legs - muppet teachers! - Salem
>cin.ignore ( numeric_limits<streamsize>::max(), '\n' );
To be strictly correct you should include <ios> for streamsize.
My best code is written with the delete key.
Does that mean this code won't compile on some other compilers because of this?Originally Posted by Prelude
Gotta love the "please fix this for me, but I'm not going to tell you which functions we're allowed to use" posts.
It's like teaching people to walk by first breaking their legs - muppet teachers! - Salem
I'll appreciated if a little explain numeric_limits<>::max()
anyway , it was helpful ,thx
Last edited by Mehdi; 08-31-2006 at 04:08 AM.
>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:
Then it would be specialized for each type supported. Let's say int and char:Code:namespace std { template <typename T> class numeric_limits { static T min(); static T 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.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; } }; }
My best code is written with the delete key.
I think that
is same asCode:numeric_limits<streamsize>::max()
At least, it's on every compiler I checked...Code:numeric_limits<int>::max()
Gotta love the "please fix this for me, but I'm not going to tell you which functions we're allowed to use" posts.
It's like teaching people to walk by first breaking their legs - muppet teachers! - Salem
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?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
>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.
My best code is written with the delete key.
Have you checked on GCC for 64-bit systems?
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
No I didn't check on any 64-bit system.Originally Posted by CornedBee
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
Gotta love the "please fix this for me, but I'm not going to tell you which functions we're allowed to use" posts.
It's like teaching people to walk by first breaking their legs - muppet teachers! - Salem
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.Originally Posted by Micko
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law