Console input reading

[David Spades]

static String ReadLn (int maxLg)  // utility function to read from stdin
    {
        byte lin[] = new byte [maxLg];
        int lg = 0, car = -1;
        String line = "";

        try
        {
            while (lg < maxLg)
            {
                car = System.in.read();
                if ((car < 0) || (car == '\n')) break;
                lin [lg++] += car;
            }
        }
        catch (IOException e)
        {
            return (null);
        }

        if ((car < 0) && (lg == 0)) return (null);  // eof
        return (new String (lin, 0, lg));
    }

I got this sample code and I'm wondering if this is best practice if I want to avoid excessive flushing? thanks

[Campbell Ritchie]

It looks pretty awful. Who gave you it?

[James Boswell]

That is awful code. The only sensibly named variable is called line which ironically is never used. Like Campbell says, where did you find it?

[Paul Clapham]

Apart from the quality of that code, what's this "flushing" you want to avoid? And why do you want to avoid it?

[David Spades]

I got it from my nephew who's doing some programming bootcamp and he asked me for help regarding java. Apparently he got it from his group leader, and since I haven't done any console programming, I need some help here. Aside from variable names that are not very user friendly, the code quality is awful? well, any suggestion as how it should've been written?

as to what flushing, I'm not sure. I just got that from the documentation that my nephew gave me:

Use buffered I/O to avoid long processing time due to excessive flushing.

so, the spec for the problem is that our app must receive and process a sequence of 6 digits from another program with the following format:

1 0 0 5 6 8
0 0 2 3 5 4
8 4 10 251 3 6
0 0 20 200 1 5
.........
0 0 0 0 0 0 

so, what I'm a bit confused is the input reading part. And I'm not sure how java works for this kind of situation (flushing involved, whatever that may mean?)
thanks

[Paul Clapham]

Okay. When you write data to some output target, the data may be stored in a buffer and not written immediately. When this buffer fills up, the contents will be flushed -- they will be written to the actual output target. If the word makes you think of a toilet, that was probably intentional. So the larger the buffer, the less flushing is done. And if you don't use any buffer, then each individual byte will be separately flushed, which could use excess resources.

Clearly flushing is irrelevant to input. That's why I asked why you were trying to avoid it in an input situation.

As for the problem spec you posted, I don't see any reason to use code which reads a line but puts an upper limit on the number of characters it will process, i.e. only read a partial line if the whole line is longer than that upper limit. Your spec doesn't say anything about that at all. So the code you posted isn't useful in your case. Just write simple code which reads a line and extracts the six numbers from it, and repeat.

[David Spades]

ok, so there'll be hundreds of thousand of lines containing the 6 digits.
the line where all 6 digits are zeroes marks the end of input by external app.
So, reading and extract number per line without buffering is the recommended way?
thanks

[Winston Gutkowski]

David Spades wrote:ok, so there'll be hundreds of thousand of lines containing the 6 digits.

OK, well the first thing is: Are you sure they're lines? It's perfectly reasonable that they would be, but it's not required to do the I/O.

So, reading and extract number per line without buffering is the recommended way?

Not at all. Indeed, your previous post suggests that your nephew was specifically asked to use buffered input.

My advice: have a look at the BufferedReader class (←click), and more specifically, its readLine() method.

Winston

[Campbell Ritchie]

David Spades wrote: . . . programming bootcamp . . .

Is he paying for the bootcamp? Tell him to ask for his money back

Flushing is something you do to a writer. Look up BufferedWriter and the corresponding Java Tutorials section. What happens is that the data to be written are all put into a buffer and when that buffer is full, they are transferred to their destination. You usually have to close a BufferedWriter when you have finished with it, so as to release its associated resources, but if you look for the BufferedWriter#close() method, you find it flushes the stream as well. If you search this forum every now and again (maybe twice a year) there is a post from somebody who has forgotten to clsoe a Writer and is wondering why the destination file hasn't been written. But you don't usually have to do any flushing when reading something.

[Campbell Ritchie]

Did they really say 6 digits? The example you show includes a line with 9 digits in. Do they mean six small integers? Do they permit negative numbers? Do you mean you stop reading when all six numbers input in a single line are all 0?
There are classes in the standard Java® API which will read an int directly from the keyboard? Why did they not use them?
If anything goes wrong, they are performing the dangerous practice of returning null.
What do they mean about sequence of digits from another program? That doesn't constitute reading from the console, even though the code says System.in.read(). I would create a class which encapsulates those six numbers. If you need to transmit such an object, you can serialise it and deserialise it. You can give it a hasAllZeroes method if you wish. Otherwise, you can write your output into a file, either a text file or a random access file, and read from that file.

But using read() into an array of bytes, and then trying to create a String to represent six numbers, looks pretty bad practice to me. Unless they are trying to show people what System.in.read() does so as to immunise them against ever using it again

[David Spades]

sorry, not 6 digits, I should've said 6 positive integers, nad yes, stop reading when all 6 integers are 0.
I'm not sure how it all fits in, but I think it's something like this, the other app will "start" our app and keep feeding these 6 integers to main and keep doing that and they expect our app to shutdown when 6 zeroes are fed to it. So, I don't think it's going to read from file. So, BufferedReader for now? is this the recommended way for this case?
and flushing is for writers only? pretty sure we're not writing anything, or is printing something to System.out considered writing? is this where the flushing happens?
thanks

[Stefan Evans]

Sounds like a feasible use case. Particularly for a *nix type system where you can redirect the output of one program to the input of another.

Yes, BufferedReader is the way to go.
Though if you are getting input from System.in you will probably also have to wrap it in an InputStreamReader.

Considering System.out, I'm of two minds for that one.
System.out is normally buffered by the operating system, so why bother with an extra one?
However it is a good practice to get into for when you are NOT writing to System.out (eg writing to a file) so wrapping it in a Buffer shouldn't hurt. Again the java.io package should provide the relevant helper classes.

[David Spades]

I tried this one in Java:

class Main {
	
	public static void main(String [] args){
		
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
		String input;
		
		try {
			
			while((input = br.readLine()) != null){
				
				String[] integers = input.split(" ");
				
				int one = Integer.parseInt(integers[0]);
				int two = Integer.parseInt(integers[1]);
				int three = Integer.parseInt(integers[2]);
				int four = Integer.parseInt(integers[3]);
				int five = Integer.parseInt(integers[4]);
				int six = Integer.parseInt(integers[5]);
				
				if(one + two + three + four + five + six == 0) return;
				
				System.out.println("abc");
				
			}
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		
	}
	
}

this one took 0.106 secs to complete

and then I tried doing the same using C++
#include<stdio.h> int main(){ int a,b,c,d,e,f; while(scanf("%i %i %i %i %i %i","&a,&b,&c,&d,&e,&f)){ if(a+b+c+d+e+f == 0) return 0; printf("abc"); } }

and this took only 0.003 sec --> more than 30 times faster than java

is this normal?
thanks

[Winston Gutkowski]

David Spades wrote:I tried this one in Java ... this one took 0.106 secs to complete
and then I tried doing the same using C++ ... and this took only 0.003 sec --> more than 30 times faster than java
is this normal?

How did you time it? If it was with a system tool then any Java program is going to look slow, because it needs to load the JVM first. Try using System.nanoTime() and see how long Java thinks it took to run.

I'd care to bet that no language is 30 times faster than Java these days - for anything - and especially I/O, since both programs are likely to use the same underlying system calls.

Winston

[Dave Tolls]

Also, the JVM compiles stuff to native code as it goes, so any single run will not be representative of the actual time taken to execute a simple process.
It needs "warming up" sometimes.

So, it depends on how big the data coming in is.