C or C++?

[Dubslow]

Originally Posted by chalsall

No. As I said, it's simply a macro -- the execution speed will be exactly the same.

As WraithX points out above, you want to get (no joke intended) friendly with fgets().

You work with what fgets() returns (if anything), and map it into your own data structures (possibily with dynamically allocated storage space) to parce as a function of what it has already been returned in the past.

Okay then:

printf("Please enter the source text (empty line to quit)\n");
char * string = (char *)malloc( MAXSTRLEN * sizeof(char));
string = fgets(string, MAXSTRLEN, stdin);
for(i=0; string[i]; i++);	// i becomes the index of the null, which is the length of the string 
if( i == (MAXSTRLEN - 1) ) {	// Then the string is longer than MAXSTRLEN - 1, and so the rest is lost.
	printf("Source is longer than %d characters. The rest is lost.\n", MAXSTRLEN-1);
}
if ( string[0]==0 ) {	// The entire string is null, or rather, the only character was \n, so no input.
	printf("Bye.\n");
	return 7;
}

Edit: Okay, at least it sort of works now. This stuff is all part of a while(1) loop. When I run the prog, it goes through this part of the code, but does not wait for user input and just finishes the loop and goes around again, but the second time, it does wait for user input. When it does wait and I do give it "\n" as input, i.e. no input, it just goes through the loop again without exiting properly.
1) Why does it go around without waiting for the user the first time through, but it does wait for user input the second time through, and
2) Why doesn't a blank initiate the "Bye" section, or better yet, how does fgets treat the "\n" string?

[chalsall]

Originally Posted by Dubslow

Okay then:

Getting there...

Now, wrap your head around the "realloc()" function, and properly deal with a text line which is longer than MAXSTRLEN.

And, as an aside, your "for loop" could be replaced with the strlen() function.

[Dubslow]

Originally Posted by chalsall

And, as an aside, your "for loop" could be replaced with the strlen() function.

strlen, and also removed the redundant string = fgets

		char * string = (char *)malloc( MAXSTRLEN * sizeof(char));
		fgets(string, MAXSTRLEN, stdin);
		i = (int)strlen(string);
		if( i == (MAXSTRLEN - 1) ) {	// Then the string is longer than MAXSTRLEN - 1, and so the rest is lost.
			printf("Source is longer than %d characters. The rest is lost.\n", MAXSTRLEN-1); // will add in realloc later once the behavior is correct
		}
		if ( string[0]==0 ) {	// The entire string is null, or rather, the only character was \n, so no input.
			printf("Bye.\n");
			return 7;
		}

However, the behavior is still as above, which is to say, not correct.

[chalsall]

Originally Posted by Dubslow

However, the behavior is still as above, which is to say, not correct.

So... Follow my suggestion...

How would you use realloc() to solve the problem?

[Dubslow]

Originally Posted by chalsall

So... Follow my suggestion...

How would you use realloc() to solve the problem?

What does realloc() and strlen()>MAXSTRLEN have to do with incorrect behavior for empty strings?

[chalsall]

Originally Posted by Dubslow

What does realloc() and strlen()>MAXSTRLEN have to do with incorrect behavior for empty strings?

Sorry... Different problem...

Empty strings are trivial, so long as you are expecting them...

BTW, you might want to look into "buffered" vs. "unbuffered" input and output....

[Dubslow]

Yeah, I've been wondering about that... I saw the P95 uses sprintf( buf, ...). On the other hand, it seems my if statement to catch empties is not working, but I also have a lab in ten minutes.

[LaurV]

I would read the characters one by one (contrary to line by line) and always keep the last read in a var, initialized to 0 before reading something.

oldchar=0;
newchar=read_new_char(); \\wait for it, with a timer for timeout if the user is sleeping, return zero if it is cr, lf, whatever are you interested in parsing, etc.
if (!(olchar|newchar)) exit;
oldchar=newchar;
//here do whatever you like and loop back at the beginning (for, while, goto, etc).

Oc course, you can directly initialize and compare with CR or LF (code 10 or 13, hex 0x0A or 0x0D), but you will lose flexibility. This version has the advantage that you move outside parsing of the characters (remember the problem with yafu, which is sending out \b characters, and yoyo's perl script doesn't know what to do with them?). Maybe later you would be interested to parse something else, like \b, \g (beeps?), ctrl+z (eof), instead of empty line, etc.
And sideways, it will take care of the empty strings too, because a "empty line" (after some text, or after nothing) is a sequence of two zeros (or two CR, etc).

[jyb]

Originally Posted by chalsall

Sorry... Different problem...

Empty strings are trivial, so long as you are expecting them...

BTW, you might want to look into "buffered" vs. "unbuffered" input and output....

Since *you* are apparently familiar with buffered vs unbuffered input, I'm wondering why you think that getchar is so "terribly inefficient from an OS perspective". I believe that from an OS perspective you'll find it to be exactly as efficient as fgets.

[chalsall]

Originally Posted by jyb

I believe that from an OS perspective you'll find it to be exactly as efficient as fgets.

OK, OS was the wrong term. The point I was trying to make is why call a function (say 70) times to read a line when you can call another once to get the same result?

[Dubslow]

Originally Posted by chalsall

OK, OS was the wrong term. The point I was trying to make is why call a function (say 70) times to read a line when you can call another once to get the same result?

But is not the latter a front end for the former? As in, my own loop accomplished exactly the same work, and there's not much you can do to make it more efficient.