Thread: Simple C++ help for a beginer?

cin and cout are popular options. getline( ) also works if you want to accept an entire line of user input (including blank spaces)

Code:

include<iostream>
include<string>
using namespace std;

int main()
{
     string name;

     cout << "Please enter your name: ";

     cin >> name;

     cout << "\n\nHello " << name << ", how are you doing today?";

     return 0;

}

You can clear out the garbage from cin like this:

Code:

#include <iostream>
#include <limits>

using namespace std;

int main()
{
  // The rest of your program here

  cin.ignore(numeric_limits<streamsize>::max(), '\n');
  cin.get();
}

How it works doesn't really matter at this point, so just be sure to include <limits> and copy what I wrote and your problem will go away until you discover better methods of taking input.

Prelude, what is your opinion on using cin.sync()?

>Prelude, what is your opinion on using cin.sync()?
Don't. The language in the standard is ambiguous enough to make cin.sync() non-portable for clearing the standard input stream.

Is there a valid use for sync()?
Why is it even in the standard?

Here is a good tutorial on using getline( )

Code:

#include<iostream>
#include<string>
using namespace std;

int main()
{
     string sentence;

     cout << "Enter a sentence: ";

     getline(cin, sentence);

     cout << "\n\nYour sentence has " << sentence.length() << " characters.";

     return 0;
}

>so if i put cin.ignore(); before the last cin.get, it will keep the window open?
Only if there's one character left in the stream because cin.ignore() only discards one character. Use my suggestion, it clears out the stream no matter how many characters are in it so that the next call to cin.get() will cause a blocking read as you would expect.

>getline(); does that require teh stdio.h header?
It depends which overload you want. If you want the getline that's a member function of istream, you include <iostream> for cin, or include <istream> and make your own object. If you want the getline for the std::string class, you include <string>.

>Is there a valid use for sync()?
Why it's a member of basic_istream is a question I've asked myself many a time. Probably to give Dr. Stroustrup a sneaky way out of his (also ambiguous, but even more misleading) statements in section 21.6.2 of TC++PL.

>Why is it even in the standard?
Supposedly to enhance flexibility when extending basic_ostream and streambuf's. ostream::flush() calls rdbuf->pubsync(), which calls rdbuf()->sync(), which is defined enough to do what we would expect of fflush(stdout).

Stroustrop clearly states in his book (21.6.2 3rd ed.) "flushing an istream is done using sync()". The standard though doesnt seem to take this view. I certainly wouldn't use it. Im not even sure of its purpose!

>Stroustrop clearly states in his book (21.6.2 3rd ed.) "flushing an istream is done using sync()".
Yet he neglected to specify what he meant by "flushing an istream". Sure, the most likely interpretation is that all characters in the buffer are discarded, but that's what ignore does, in a more general way. At best, with that interpretation, sync is redundant for istream, at worst, it's non-portable for any use.

>Im not even sure of its purpose!
The purpose of sync() is to synchronize the streambuf with the external device. For ostream that means writing any unwritten characters to the device and resetting the internal buffer pointers such that pptr() == pbase() (not necessarily, but most likely for a realistic implementation). One could argue that the same thing is done for istream where eback() and gptr() are synchronized such that eback() == gptr(), but that raises interesting and non-portable issues where the external device doesn't have the requisite behavior (I doubt that's what the standards committee wanted). It's more likely that synchronizing the streambuf with the external device for an istream means that (for example,) if working with a filtering streambuf, a file stream, a stream using shared memory, or some other external device that could be updated outside of the control of the streambuf, such as in a multithreaded or multiprocess environment, the streambuf is updated to reflect those changes.

The key element to understanding that interpretation is that calls to gcount() are uneffected by calls to sync(). Therefore, it's logically impossible for sync() to extract characters since any unformatted input operation that extracts characters must update gcount() or risk a loss of integrity of the streambuf.

exactly. I know the semantics of it but as you said its logically impossible for sync to extract characters because gcount is not updated. So what does it do? I read it also as a kind of fflush(stdout) yet am lost as to why its an istream member. there is no sync in ostream only flush.
I rarely use iostreams anyway so it really doesn't affect me but this is an interesting topic.

Prelude do you have a copy of langers iostreams book? What does she say about sync?

>Prelude do you have a copy of langers iostreams book?
I do, but not with me right now. I'll try to remember to look it up when I get home tonight.

>yet am lost as to why its an istream member
In summary, if it does anything (because the external image may not have changed), it makes the internal buffer match the view of the external device.

>there is no sync in ostream only flush.
There's no need for sync in ostream because ostream::flush() calls rdbuf()->pubsync(), which is more or less identical to what istream::sync() does.

>but this is an interesting topic
Indeed, it is.

>What does she say about sync?
They say the behavior of istream::sync() is not well defined and depends on the type of stream in question. Not immensely helpful; I like my interpretation better.