7 ms·

Is this what he's looking for? public static void main(String[] args) throws IOException { int ch; while ((ch = System.in.read()) != -1)

by guelo 13y ago

Is this what he's looking for? public static void main(String[] args) throws IOException { int ch; while ((ch = System.in.read()) != -1) System.out.print((char) ch); }

marvy 13y ago
I think so. Or something like that. Might be better to use "write" instead of "print", to avoid character encoding issues.
- cbsmith 13y ago
  > Might be better to use "write" instead of "print", to avoid character encoding issues. Ya think!?
thomaswk 13y ago
I have a healthy love/hate relationship with Java - but that's the first thing I thought of too. Alternatively you could read into a byte[] buf and not have any casting. This is valid JDK 1 code. You only need to read the Javadoc for InputStream and PrintWriter. I think the author needs to check his biases. Now Javascript... (just kidding).
- cbsmith 13y ago
  > I have a healthy love/hate relationship with Java - but that's the first thing I thought of too. Alternatively you could read into a byte[] buf and not have any casting. Okay, that kind of points to the problem. You don't see anything wrong with that code beyond the casting (and avoiding casting is the wrong reason to read in to a byte[].. which opens up some additional complexity too).
  - thomaswk 13y ago
    Sigh so half of an interview is to probe the candidate's knowledge and the other half is to understand their thought process. So my ideal impl in java would be: public class F { public static void main(String [] args) throws Exception { byte[] buf = new byte[256]; int len = -1; while ( (len = System.in.read(buf)) != -1) { System.out.write(buf, 0, len); } System.out.flush(); } } In python #!/usr/bin/env python -u import sys while True: buf = sys.stdin.read(256) if buf: sys.stdout.write(buf) else: break Which both feel roughly the same. Although I kind of wish python would let me assign within the expression - just in this case. The similarity boils down to the fact that they're sitting on top of posix read and write calls. There's not much variation you can get from that. The differences get down to fd stream flushing. Python we enable unbuffered io with -u, java we must flush. In C++ we can count on all FDs being flushed in atexit. You certainly can muck this problem up for binary files and different charsets if you're not careful. But the OP's solution still works in many cases. A fine first answer. Any time a candidate writes code for you during an interview, the first answer will most likely have issues (stress, trying to finish quickly to impress, etc). I care very little about that stuff if there answer is roughly functional. After they have their first stab out, then you go thru the 'why did you do it this way?' 'what corner cases might you be concerned about?' and so on. The answers to those questions will let you make a good estimate of their knowledge and competence.
    - cbsmith 13y ago
      So, my first follow up would be: why are you bothering to read in to a byte array, and why a 256 byte array? And to be clear... the correct answer is that in Java it basically buys you nothing but some extra overhead initializing an array and in Python it merely saves you trips through the repl loop. Either way the choice of 256 bytes is arbitrary.
      - thomaswk 13y ago
        I'd phrase it in a nicer way in an interview, but on a forum: You're wrong. The explicit buffering afforded by read(byte[]) & write(byte[], off, len) vs. read() & write(int) saves demonstrable time as file size increases. 256 - yeah arbitrary :) tweak as necessary. on my junky MBP running java 6 - read(byte[]) & write(byte[], int, int): real 0m6.588s user 0m0.876s sys 0m1.406s vs. read() & write(int) real 0m16.836s user 0m10.624s sys 0m4.245s vs the mighty cat - < in > out: real 0m4.609s user 0m0.015s sys 0m0.458s For a 150 mb file. I'd say read(byte[]) / write(byte[], int, int) performed pretty well. Now some points. System.in is an InputStream, System.out is a PrintStream. Assuming anything more about their buffering nature is wrong. AFIAK there is nothing in the java spec that spells out any other explicit behaviour. So if you want to ensure your code works properly, code against the interfaces you're given, not the implementations you expect are sitting behind them. This question (and stdin/stdout/stderr questions in general) are heavily biased in favour of devs comfortable of working in a Unix-y environment. If you're fine with short changing people that use that other OS that's cool. But if you want a 'trivial' demonstration of programming skill - a FizzBuzz type of question is much less biased way of achieving that.
        cbsmith 13y ago
        Okay, I stand corrected that you can achieve some win due to doing buffering yourself. I guess it does depend on your implementation (though I'd think the JIT would eventually get around to eliminating most of that overhead you see), though you should still have buffering as per the platform's standard runtime, which I'd expect in most cases would be not insignificant. > So if you want to ensure your code works properly, code against the interfaces you're given, not the implementations you expect are sitting behind them. A test which the original code, and your initial review, failed on multiple fronts (failed to handle character encoding issues and failed to flush the output stream before exiting). > This question (and stdin/stdout/stderr questions in general) are heavily biased in favour of devs comfortable of working in a Unix-y environment. I honestly find it hard to believe that Java devs would have their skills sets be terribly different regardless of platform they run on, and I really would think people would learn the basics of working with streams regardless of the platform they work with, but I grok the gist of what you are saying. > But if you want a 'trivial' demonstration of programming skill - a FizzBuzz type of question is much less biased way of achieving that. FizzBuzz doesn't really test for knowledge of the language's libraries though. I always thought the purpose of these tests was more to validate that the programmer had successfully coded in the past, rather than any demonstration of skill.
cbsmith 13y ago
You know, I kind of thought he was joking that Java programmers messed this stuff up. I was so wrong. Three things wrong. The first is pedantic: you need to import IOException. The second though is one of those "scream out loud at the universe* questions: why the heck are you calling print() instead of write()? Finally, do you think maybe you might need to worry about buffering of System.out's stream?
- benjamincburns 13y ago
  I mean, if you really want to be pedantic... > you need to import IOException try { ... } catch(Exception ex){ ... } ;-) Edit: Or if you want to be just as pedantic, and not write an obnoxious catch-all try { ... } catch (java.io.IOException ex) { ... }
  - cbsmith 13y ago
    I'm not sure why you'd want to use a catch, but I agree there is more than one way to solve the problem. I was merely pointing out one thing that would prevent the code from passing the test framework.
    - benjamincburns 13y ago
      Sorry, I didn't think I was telling you something which you didn't already know. I just saw a hole in the pedantry and felt a strange need to point it out. Now that I've typed that, I realize what a horrible person I am. As to why you'd want to use a catch, I think it's kind of sloppy to let the user see an uncaught exception. You might as well just do public static void main(String args[]){ try { ... } catch (Exception e) { System.out.println("This is horrible software, and you shouldn't use it."); } } ... as that's what many users already see when exception goes uncaught.
      - cbsmith 13y ago
        I could see a try/catch with a System.exit(-1) maybe, but arguably the default handler does the right thing (returns an error code and writes diagnostics to stderr).
brilee 13y ago
Question: I see all this discussion about buffering and encoding and such. In python, this seems to work: import sys sys.stdout.write(sys.stdin.read()) What is being abstracted away/handled by python that I'm not seeing?
- cbsmith 13y ago
  Nothing beyond an automatic flush/close of stdout on exit. The python code above is also reading the entire file in to memory before writing it out to disk, which isn't exactly wise. Aside from the addition of a flush at the end, the correct Java code for this is simply a loop with an exit test over a read() & write() though, which is really no different from the proper Python code.
- sjy 13y ago
  .read() will read the entire contents of the file object into memory. That's fine if you're just doing `io.py < smallfile.txt`, but if the file is huge you'll run out of memory. And stdin is an infinite stream (eg. `io.py < /dev/urandom`), your Python code will never print anything. If you write `for line in sys.stdin: sys.stdout.write(line)` instead, you'll solve these problems by buffering line-by-line.
  - cbsmith 13y ago
    > If you write `for line in sys.stdin: sys.stdout.writte(line)` instead, you'll solve these problems by buffering line-by-line. Except no. Then you run in to problems with a binary file that might not have a line break.
- cbsmith 13y ago
  There seems to be confusion on how to write this properly, so don't feel bad about missing this (or alternatively feel bad for all of humanity). I believe this Java code I posted elsewhere handles things just fine: https://gist.github.com/cbsmith/9755809 https://gist.github.com/cbsmith/9755809
zoodle 13y ago
Any language right? Here's classic C++. #include <iostream> int main () { std::cout << std::cin.rdbuf(); return 0; }
- einhverfr 13y ago
  In perl: while (<>){ print };
  - jweese 13y ago
    perl -pe ""
chatman 13y ago
public static void main(String[]args) throws IOException { Scanner sc = new Scanner(System.in); String line; while((line=sc.readLine())!=null) System.out.println(line); } What's so verbose about it?
- jsight 13y ago
  You didn't import Scanner, and java.util.Scanner (what I assume you are using) does not have a readLine method. :)
- cbsmith 13y ago
  So, that actually is going to have problems with binary data in the file. However, you are correct it doesn't need to be terribly verbose (not as efficient as it could be, but that is easily fixable): https://gist.github.com/cbsmith/9755809 https://gist.github.com/cbsmith/9755809 It's amazing though how often the solutions posted are just wrong.

by guelo 13y ago

Is this what he's looking for? public static void main(String[] args) throws IOException { int ch; while ((ch = System.in.read()) != -1) System.out.print((char) ch); }

marvy 13y ago

I think so. Or something like that. Might be better to use "write" instead of "print", to avoid character encoding issues.

cbsmith 13y ago
> Might be better to use "write" instead of "print", to avoid character encoding issues. Ya think!?

thomaswk 13y ago

I have a healthy love/hate relationship with Java - but that's the first thing I thought of too. Alternatively you could read into a byte[] buf and not have any casting. This is valid JDK 1 code. You only need to read the Javadoc for InputStream and PrintWriter. I think the author needs to check his biases. Now Javascript... (just kidding).

cbsmith 13y ago
> I have a healthy love/hate relationship with Java - but that's the first thing I thought of too. Alternatively you could read into a byte[] buf and not have any casting. Okay, that kind of points to the problem. You don't see anything wrong with that code beyond the casting (and avoiding casting is the wrong reason to read in to a byte[].. which opens up some additional complexity too).
- thomaswk 13y ago
  Sigh so half of an interview is to probe the candidate's knowledge and the other half is to understand their thought process. So my ideal impl in java would be: public class F { public static void main(String [] args) throws Exception { byte[] buf = new byte[256]; int len = -1; while ( (len = System.in.read(buf)) != -1) { System.out.write(buf, 0, len); } System.out.flush(); } } In python #!/usr/bin/env python -u import sys while True: buf = sys.stdin.read(256) if buf: sys.stdout.write(buf) else: break Which both feel roughly the same. Although I kind of wish python would let me assign within the expression - just in this case. The similarity boils down to the fact that they're sitting on top of posix read and write calls. There's not much variation you can get from that. The differences get down to fd stream flushing. Python we enable unbuffered io with -u, java we must flush. In C++ we can count on all FDs being flushed in atexit. You certainly can muck this problem up for binary files and different charsets if you're not careful. But the OP's solution still works in many cases. A fine first answer. Any time a candidate writes code for you during an interview, the first answer will most likely have issues (stress, trying to finish quickly to impress, etc). I care very little about that stuff if there answer is roughly functional. After they have their first stab out, then you go thru the 'why did you do it this way?' 'what corner cases might you be concerned about?' and so on. The answers to those questions will let you make a good estimate of their knowledge and competence.
  - cbsmith 13y ago
    So, my first follow up would be: why are you bothering to read in to a byte array, and why a 256 byte array? And to be clear... the correct answer is that in Java it basically buys you nothing but some extra overhead initializing an array and in Python it merely saves you trips through the repl loop. Either way the choice of 256 bytes is arbitrary.
    - thomaswk 13y ago
      I'd phrase it in a nicer way in an interview, but on a forum: You're wrong. The explicit buffering afforded by read(byte[]) & write(byte[], off, len) vs. read() & write(int) saves demonstrable time as file size increases. 256 - yeah arbitrary :) tweak as necessary. on my junky MBP running java 6 - read(byte[]) & write(byte[], int, int): real 0m6.588s user 0m0.876s sys 0m1.406s vs. read() & write(int) real 0m16.836s user 0m10.624s sys 0m4.245s vs the mighty cat - < in > out: real 0m4.609s user 0m0.015s sys 0m0.458s For a 150 mb file. I'd say read(byte[]) / write(byte[], int, int) performed pretty well. Now some points. System.in is an InputStream, System.out is a PrintStream. Assuming anything more about their buffering nature is wrong. AFIAK there is nothing in the java spec that spells out any other explicit behaviour. So if you want to ensure your code works properly, code against the interfaces you're given, not the implementations you expect are sitting behind them. This question (and stdin/stdout/stderr questions in general) are heavily biased in favour of devs comfortable of working in a Unix-y environment. If you're fine with short changing people that use that other OS that's cool. But if you want a 'trivial' demonstration of programming skill - a FizzBuzz type of question is much less biased way of achieving that.
      - cbsmith 13y ago
        Okay, I stand corrected that you can achieve some win due to doing buffering yourself. I guess it does depend on your implementation (though I'd think the JIT would eventually get around to eliminating most of that overhead you see), though you should still have buffering as per the platform's standard runtime, which I'd expect in most cases would be not insignificant. > So if you want to ensure your code works properly, code against the interfaces you're given, not the implementations you expect are sitting behind them. A test which the original code, and your initial review, failed on multiple fronts (failed to handle character encoding issues and failed to flush the output stream before exiting). > This question (and stdin/stdout/stderr questions in general) are heavily biased in favour of devs comfortable of working in a Unix-y environment. I honestly find it hard to believe that Java devs would have their skills sets be terribly different regardless of platform they run on, and I really would think people would learn the basics of working with streams regardless of the platform they work with, but I grok the gist of what you are saying. > But if you want a 'trivial' demonstration of programming skill - a FizzBuzz type of question is much less biased way of achieving that. FizzBuzz doesn't really test for knowledge of the language's libraries though. I always thought the purpose of these tests was more to validate that the programmer had successfully coded in the past, rather than any demonstration of skill.

cbsmith 13y ago

You know, I kind of thought he was joking that Java programmers messed this stuff up. I was so wrong. Three things wrong. The first is pedantic: you need to import IOException. The second though is one of those "scream out loud at the universe* questions: why the heck are you calling print() instead of write()? Finally, do you think maybe you might need to worry about buffering of System.out's stream?

benjamincburns 13y ago
I mean, if you really want to be pedantic... > you need to import IOException try { ... } catch(Exception ex){ ... } ;-) Edit: Or if you want to be just as pedantic, and not write an obnoxious catch-all try { ... } catch (java.io.IOException ex) { ... }
- cbsmith 13y ago
  I'm not sure why you'd want to use a catch, but I agree there is more than one way to solve the problem. I was merely pointing out one thing that would prevent the code from passing the test framework.
  - benjamincburns 13y ago
    Sorry, I didn't think I was telling you something which you didn't already know. I just saw a hole in the pedantry and felt a strange need to point it out. Now that I've typed that, I realize what a horrible person I am. As to why you'd want to use a catch, I think it's kind of sloppy to let the user see an uncaught exception. You might as well just do public static void main(String args[]){ try { ... } catch (Exception e) { System.out.println("This is horrible software, and you shouldn't use it."); } } ... as that's what many users already see when exception goes uncaught.
    - cbsmith 13y ago
      I could see a try/catch with a System.exit(-1) maybe, but arguably the default handler does the right thing (returns an error code and writes diagnostics to stderr).

brilee 13y ago

Question: I see all this discussion about buffering and encoding and such. In python, this seems to work: import sys sys.stdout.write(sys.stdin.read()) What is being abstracted away/handled by python that I'm not seeing?

cbsmith 13y ago
Nothing beyond an automatic flush/close of stdout on exit. The python code above is also reading the entire file in to memory before writing it out to disk, which isn't exactly wise. Aside from the addition of a flush at the end, the correct Java code for this is simply a loop with an exit test over a read() & write() though, which is really no different from the proper Python code.
sjy 13y ago
.read() will read the entire contents of the file object into memory. That's fine if you're just doing `io.py < smallfile.txt`, but if the file is huge you'll run out of memory. And stdin is an infinite stream (eg. `io.py < /dev/urandom`), your Python code will never print anything. If you write `for line in sys.stdin: sys.stdout.write(line)` instead, you'll solve these problems by buffering line-by-line.
- cbsmith 13y ago
  > If you write `for line in sys.stdin: sys.stdout.writte(line)` instead, you'll solve these problems by buffering line-by-line. Except no. Then you run in to problems with a binary file that might not have a line break.
cbsmith 13y ago
There seems to be confusion on how to write this properly, so don't feel bad about missing this (or alternatively feel bad for all of humanity). I believe this Java code I posted elsewhere handles things just fine: https://gist.github.com/cbsmith/9755809 https://gist.github.com/cbsmith/9755809

zoodle 13y ago

Any language right? Here's classic C++. #include <iostream> int main () { std::cout << std::cin.rdbuf(); return 0; }

einhverfr 13y ago
In perl: while (<>){ print };
- jweese 13y ago
  perl -pe ""

chatman 13y ago

public static void main(String[]args) throws IOException { Scanner sc = new Scanner(System.in); String line; while((line=sc.readLine())!=null) System.out.println(line); } What's so verbose about it?

jsight 13y ago
You didn't import Scanner, and java.util.Scanner (what I assume you are using) does not have a readLine method. :)
cbsmith 13y ago
So, that actually is going to have problems with binary data in the file. However, you are correct it doesn't need to be terribly verbose (not as efficient as it could be, but that is easily fixable): https://gist.github.com/cbsmith/9755809 https://gist.github.com/cbsmith/9755809 It's amazing though how often the solutions posted are just wrong.