Detecting end of line

[pizet]

Hi!

I'm testing a graph algorithm. I'm representing the graph by a list of sons. But I have a problem with detecting the end of line while reading the input data from standard input.

I've got this piece of code:

int N, j=0; // N is number of nodes

scanf("%d",&N);
for (int i=0; i!=N; ++i) { // for each node let's set his followers
	while (scanf("%d",&E[j])) { // here is the problem
/* you don't need to mind the other code ... */
		scanf("%d",&H[j]);
		++j;
	}
	V[i+1] = j;
}

So I've got the problem on line 5. I dont't know how to detect the end of line.

For example:

2
5 1 2 4 6 3 ^Z
and the program ends...
It doesn't let me to insert values for the second node.

Do you have any ideas on how to solve this problem?

Actually I am seaking for something similar as in Pascal is "eoln".

Thanks.

[hamsterman]

I'm not too familiar with cstdlib, but I think I know this one..
Method 1: Read a string with gets. Then read integers form it with sscanf until it returns 0 or EOF.
Method 2: Read an int with scanf, then call getchar. Repeat until getchar returns a '\n' (which marks the end of line).

[pizet]

How would you do it with "<iostream>"?

[pizet]

By the way it's "<cstdio>". I just use it for basic stuff, because printf and scanf are faster than cin and cout.

[pizet]

And thanks for help. It works.

[hamsterman]

By 'cstdlib' I meant the whole C standard library.
And I agree about the speed. It's really crazy. I once tested, atof was 8 times faster than using a stringstream..

With <iostream> you'd have the same two options:
1: getline, stringstream and while(my_stringstream >> temp_string) {...}
2: cin >> temp_string, and cin.peek().

[Duthomhas]

BTW, don't ever use gets(). Use fgets().

[sohguanh]

By the way it's "<cstdio>". I just use it for basic stuff, because printf and scanf are faster than cin and cout.

On some occasions I agree to the above. I was a bit sad when C++ iostream came out. They remove the concept of format specifier like %d %s %c etc which is so friendly and easy to use in C. In their place, C++ introduce IO manipulators and although they are description friendly, I find it hard to use in comparison to format specifiers.

What is so wrong with format specifiers that C++ creator Stroustrop wanna remove it ? Hmmm.... some design issues I just do not agree but I guess I have to live by the rules he set isn't it ? :O

[Duthomhas]

...friendly, easy to use, and the source of countless forum posts wondering why foo didn't print properly... though I don't personally consider all those weird %z things very friendly (and I know them all by heart, alas).

C++ I/O is dynamic, type-safe, and, if used properly, just as fast. Wait, did I say, "just as fast"? I meant, faster.

http://www.daniweb.com/forums/thread40450.html

[Disch]

To add onto Duoas and his thread... consider the following examples:

int foo = 5;

printf("%d",foo);  // typical printf

cout << foo; // typical cout 

Here's why cout is superior in just about every way:

Type safety

printf offers no assurance that the variables you're passing match the format you specify in the format string. Example:

float bar = 5;
printf("%d",bar);  // SURPRISE 

On the other hand, cout has no format string, so there's nothing for it to misinterpret.


Code clarity

Duoas said he has all of the %z things memorized -- personally I have a few of them memorized... but certainly not all of them. What's more is that they can get pretty complex when you throw in the modifiers.

printf is certainly more compact... but I as stated in another thread recently, clarity is infinitely more important that compactness.


Speed

As Duoas mentioned, cout is typically faster.

Think about what printf has to do. I has to step through and parse the format string, then for each marker it finds it has to determine which type it is and format the data appropriately. This all has to be done at runtime.

On the other hand, with cout, the type is determined at compile time and the appropriate, specific function is called without any runtime checks being necessary.

Expandability

You can overload your own << operators to print new and different types, but you can't create your own printf %-style modifiers (and even if you could, can you imagine what a mess it would be?)

Generic / templated programming

ostreams work well in templates because the syntax for printing any type is the same. cout << myvar; No matter what type 'myvar' is, it will be printed appropriately. This means you can fit it into templates nicely:

// obviously a contrived example... but it gets the point across

template <typename T>
void SomeFunction(ostream& out,const T& v)
{
  out << v;
}

What would the printf equivilent to that be? There isn't one, because you can't generate the correct format string without knowing the type.

[rocketboy9000]

clarity? bah.
printf("&%06x\n",color)
becomes:
cout << '&' << hex << setw(6) << fill('0') << color << setw(0) << dec << endl;
or if you're not using namespace std:
std::cout << '&' << std::hex << std::setw(6) << std::fill('0') << color << std::setw(0) << std::dec << std::endl;
holy moly.

[Disch]

You have a valid point which I concede to: printf is more compact.

But in the scheme of things, code compactness is not nearly as important as other aspects.

You also made the cout version needlessly long.

[rocketboy9000]

Another thing that I like about stdio.h: scanf has assignment-suppression. You can use this to read in a file with comments after the data:

1:10 not a good horse to bet on

while(scanf("%d:%d%*s\n",&odds[i],&against[i]))i++;

[Disch]

You can do that with cout, too, it would just be more verbose.

Which again comes back to clarity vs. compactness.

[rocketboy9000]

Note to OP: I have shown you the best way to solve your problem. To match end of line add %*s\n to your format. It doesn't need another argument.
To Disch: I don't believe you. Show me code that makes cin match a string without storing it anywhere.

[Duthomhas]

http://www.cplusplus.com/reference/iostream/istream/ignore/
http://www.cplusplus.com/forum/beginner/11402/#msg53942

You are getting evangelical on printf()/scanf() over cout/cin. The latter are superior to the former in every way except code compactness, which point you keep dodging.

Disch argues (as do I) that having a really short line of code is less important than type safety, maintainability, etc. Please respond.

[rocketboy9000]

I fail to see how it is less maintainable. The format string is standardized and applies to only one argument. With cout/cin, you must either put things back exactly the way they were, or paranoidly reformat everything. The formatting in cout/cin should apply to the argument, not the stream.
Here' s a fun exercise: write a function that outputs a number in hex, then goes back to exactly the way the stream was before. My example goes back to decimal; but what if cout was octal before and then the user called my code? So I must record the state of all the flags, and then restore them afterward. This is a high price for type safety.
Type safety is good, but most types can be output in multiple ways, making all these flags necessary. Why not ditch the ugly-as-sin << notation, and use something like cout.printdec(10).printhex(16);?

[rapidcoder]

Having type safety and maintainability is important, however separation of concerns is another one. The printf() and scanf() got it much better, because they separate the format pattern from the actual data, and this is exactly how most of programmers expect this to work. The streams in C++ got it totally mixed - to change the format you have to do it as if you were printing some "special kind of data". This is a nice demonstration of operator overloading abuse - using the same operator for much different purposes (even for the same object!).

Additionally having I/O with formatting built-in (this applies to both C and C++), was not a good design decision. Formatting should be separated from writing / reading characters, because streams are not the only way applications communicate with the user, and formatting is often required in some other scenarios. This leads to inefficient uses of sstream just to get a formatted string. Moving formatting to a separate library would be a good thing.

Another thing already mentioned rockedboy9000: additionally making formatting a part of the stream's state, although it really belongs to the argument, is a serious design flaw. This can break stream formatting in multithreaded environments (e.g. in logging).

Why not ditch the ugly-as-sin << notation, and use something like cout.printdec(10).printhex(16);

Or even: cout << number("####.##", 10.45). Still much better, still typesafe and could be easily made threadsafe. With the current STL design it is not possible to make it threadsafe.

[Disch]

I fail to see how it is less maintainable.

The format character assumes a specific type. This is a major maintainability hit.

This seems harmless, right?

printf("%d",myvar); // where myvar is an int 

What if the needs of the program change and myvar needs to become a long long? Or a double? You now need to go back and change every single occurance that you printed/formatted it. Good luck finding all of them.

The formatting in cout/cin should apply to the argument, not the stream.
Here' s a fun exercise: write a function that outputs a number in hex, then goes back to exactly the way the stream was before.

You just pulled a 180 here. You talk about how the format should apply to the argument, then you go on to talk about altering the state of the stream.

I agree with your first comment. The format should apply to the argument. So you can pass whatever format specifiers you want before printing the variable. The state of the stream is irrelevent.

Why not ditch the ugly-as-sin << notation,

Because it hurts expandibility and maintainability. << Can be overloaded and can have operators defined for it outside of the ostream class. On the other hand, new ostream functions cannot be made.

And do you really think << is uglier than %z? Because I'm pretty sure you'd be in the minority there.

The streams in C++ got it totally mixed - to change the format you have to do it as if you were printing some "special kind of data". This is a nice demonstration of operator overloading abuse - using the same operator for much different purposes (even for the same object!).

I see your point here. But this is a zero sum game. If cout didn't do it this way, it would be even more verbose and have even longer syntax, and you would be giving it even more flack for having to have 4 or 5 lines of code to print a single formatted variable.

Another thing already mentioned rockedboy9000: additionally making formatting a part of the stream's state, although it really belongs to the argument, is a serious design flaw. This can break stream formatting in multithreaded environments (e.g. in logging).

No, it's a design flaw to assume I/O is threadsafe.

Any kind of logging in a multithreaded environment (with cout or with printf) should be properly protected by mutexes, making this a somewhat moot point.

Or even: cout << number("####.##", 10.45). Still much better, still typesafe and could be easily made threadsafe.

Go ahead and write such a 'number' formatting option. Nothing is stopping you.

That's the beauty of ostream's system.

With the current STL design it is not possible to make it threadsafe.

Threadsafety can't be built into such facilities without sacrificing performance. Personally, I feel it's better design to do your own work of making objects threadsafe rather than having the library assume it's running in a multithreaded environment.

There are [admittedly imperfect] ways you can make it threadsafe without changing syntax... something like this:

class bufferedostream : public ostringstream
{
private:
  bufferedostream(const bufferedostream&);
  bufferedostream& operator = (const bufferedostream&);

  ostream& stream;
  mutex& mut;

public:
  bufferedostream(ostream& s,mutex& m) : stream(s), mut(m) { }
  ~bufferedostream()
  {
    m.lock();
    s << this->str();
    m.unlock();
  }
};

//...

#define tscout bufferedostream(cout,coutmutex)

//...

tscout << whatever << whatever;

EDIT:

Another idea for a solution without #define or double-buffering output would be to create a proxy class.

The proxy class could lock/unlock the mutex on construction/destruction and feed all output directly to cout (no double buffering necessary). To prevent misuse the proxy class could be only privately constructed by another class, which has a global instantiation that ties to to the appropriate mutex.

It wouldn't exactly be straightforward, but it would certainly be possible. And the syntax of using the stream wouldn't change.


EDIT 2:

Actually that above approach wouldn't work due to const correctness issues. Interesting.

I'd have to think about it more. I wish I wasn't at work!

[rapidcoder]

Threadsafety can't be built into such facilities without sacrificing performance

Mutex cost is usually small compared to the typical IO latency (and if C++ used some tricks that Java uses, the overhead could be eliminated to 0 in a single threaded case; unfortunately it cannot by design). However, they could have simply provided different implementations: one that is single-threaded and one that is thread-safe. But it is not possible without changing the API - I mean, you would have to get some thread-local wrapper that does synchronisation for the global stream (you have done exactly that), and everyone would have to remember to first obtain a wrapper and never use the shared stream object directly. That wrapper ofc has the same API, but still it would be a little cumbersome to use - I mean, you have to change some client code to just obtain/create the wrapper object.

Go ahead and write such a 'number' formatting option. Nothing is stopping you.

That's the beauty of ostream's system.

Oh, are you suggesting I should write my own STL implementation? (just a part of it) :D
Not a good idea. IMHO it is good that some things are done in the standard way. Otherwise, some coders on my project would have to learn more to understand the code.