Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Java Puzzlers 239

Posted by samzenpus from the coffee-talk dept.
Kylar writes "When you have spare time and decide to do something with a book (That's like an analog webpage, for the neuronauts among us), how often do you turn to a computer related book? How often has it happened in the last year? Right. The problem being that computer books are often either: a) boring, b) difficult to read, c) poorly written, or possibly: d) made of cheese." Read on for the rest of Kylars' review.
Traps, Pitfalls, and Corner Cases - Java Puzzlers
author Joshua Bloch, Neal Gafter
pages 282
publisher Addison-Wesley
rating 9 out of 10
reviewer Tom Byrne
ISBN 0-321-33678-X
summary 95 Corner cases and traps that any serious java developer should be aware of (or entertained by.)


Java Puzzlers is none of the above(*), being well written, amusing, whimsical, and above all, informative. Bloch and Gafter have brought us a book that entertains us with corner-cases, one-in-a-million chances and other happenings that explore the ins, outs, and guts of the Java Programming Language.

Anyone who has been a serious java programmer in the last several years should know the name Josh Bloch, and more importantly, should have read his book Effective Java. Josh, acting as java's platform architect has been directing and guiding Java into it's current incarnation as a mature, robust (Cue the laughter from the peanut gallery) programming language.

This book primarily references the Java 1.5 programming language, and some of the puzzles are 1.5-specific, although a significant portion of the problems are applicable to previous versions. Also, this book is aimed towards people who are competent-to-expert java programmers, and although there is a lot of good information, people who are new to Java will probably be a bit lost. As it stands, I have 7 years of Java experience, and I was only able to figure out about 15% of the puzzles without resorting to code, or more frequently the answer. The reason that I didn't stop to try out most of these problems is that the book is eminently readable, and difficult to put down (unusual for a computer book, and doubly so for one that delves deeply into a language specification document.)

This book dives into a lot of esoteric bits of the Java Language Specification, also known as "The Big Paper That Sometimes Tells Us Why Java Acts Like That," and there are lots of bits in there that don't even make sense, let alone seem intuitive.

Divided into 10 parts, each part presents a series of different code problems that usually present a small method or class that looks innocuous, but in reality exposes a piece of behavior that is strange, spectacular, or, more often, completely confusing. The book exposes flaws in the language, including one of my personal pet peeves, their inability to have a consistent Date object, and this is noted in Puzzle 62 by my favorite line in the book: "The lesson for API designers is: If you can't get it right the first time, at least get it right the second..."

One topic that I found was a continually recurring theme had to do with handling primitives and what happens when they are cast into different types. Java provides a lot of ways to deal with primitives, and for the most part, they play nicely with each other. There are several occurrences that really surprised me. A perfect example is the following innocent statements:

byte b = -1;
char c = (char)b;

so c=-1, right? Wrong. Places like this are things that you could potentially knock your head against the wall trying to figure out why something doesn't do what it appears to do.
(In this case, byte is signed, char isn't, and the widening cast fills in bits, leaving c=65535.)

A good job is also done describing best-practices for API and library designers, as well as us, the more mundane programmers.

The only downside (from my background and point of view - that of an applications architect, and not generally as a language or API designer) - is that some of the amazing optical illustrations can cause dizziness and nausea - although I can't guarantee that won't happen by the loops and twists that your mind will be tied into because of the puzzles.

Lastly, Bloch & Gafter include an appendix that serves as a summary to all the pitfalls and traps that are introduced in the book, and almost could be an appendix to Bloch's 'Effective Java'.

The bottom line is that in reading this book I learned a fair amount about several edge cases and issues that I had actually encountered - and it increased my understanding as to HOW java does things - although I'm fairly certain that I'll never understand the WHY. And most of all - I enjoyed this book, from start to finish, and that's rare, and worth the time.

You can purchase Java Puzzlers from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Java Puzzlers More

Java Puzzlers

Comments Filter:

  • I enjoyed Java Puzzlers, but... (Score:5, Funny)

    by Anonymous Coward on Monday November 07, 2005 @02:29PM (#13971441)
    ...it took a long time to load the first page. On the other hand, if you drop the book on the ground, it automatically throws itself into the garbage can.
  • byte b = -1;
    char c = (char)b;
    so c=-1, right? Wrong. Places like this are things that you could potentially knock your head against the wall trying to figure out why something doesn't do what it appears to do.
    (In this case, byte is signed, char isn't, and the widening cast fills in bits, leaving c=65535.)


    That's not expected??

    • Kind of (Score:2, Insightful)

      by brunes69 ( 86786 )
      See, to a C coder, this is non-obvious because both the types would be signed, and if you wanted it unsigned you would have to say so.

      It has always diven me nuts how Java forces its own signed-ness on it's primitives. The fact that you can't have an unsigned int in Java 1.5 is a huge pain, because it is not like it is simpler to just use char everywhere, since then you lose all the autoboxing capability of Integer/int. So, you have to deal with it yourself. It's a big mistake IMO.

      • Re:Kind of (Score:5, Insightful)

        by codegen ( 103601 ) on Monday November 07, 2005 @02:59PM (#13971792) Journal
        See, to a C coder, this is non-obvious because both the types would be signed, and if you wanted it unsigned you would have to say so.

        Sigh... Not true. Wether chars default to signed or unsigned is vendor specific in the ANSI C spec. If you code depends on chars being signed or not then you have to state it explicitly if you want your code to be portable. I have been bitten by this on one important occasion when I was still in Industry and have never forgotten it.

        • Read "Deep C Secrets" and learn about type promotion and automatic widening of primitives---there are some strange side effects when a compiler "invisibly" stores smaller data types in the native word size of the hardware. Signed vs. unsigned is one area you can see this, but there are others.

      • The fact that you can't have an unsigned int in Java 1.5 is a huge pain

        Or even worse, the lack of an unsigned byte when reading in binary data structures. I don't claim to be a Java expert by any stretch (so I may be missing an obvious way to do this), but do you know how unnecessarily complex it is to convert a read-in byte to it's CORRECT unsigned value? Why isn't there an automatic way to do this at all? You can't just assign the byte to an int, as it'll still be negative (if above 127). I think in

        • Re:Kind of (Score:3, Informative)

          by MillionthMonkey ( 240664 )
          Or even worse, the lack of an unsigned byte when reading in binary data structures. I don't claim to be a Java expert by any stretch (so I may be missing an obvious way to do this), but do you know how unnecessarily complex it is to convert a read-in byte to it's CORRECT unsigned value? Why isn't there an automatic way to do this at all? You can't just assign the byte to an int, as it'll still be negative (if above 127). I think in the end I just asigned the byte to an int, then did a bitwise-AND to throw o

    • Yikes! (Score:3, Funny)

      by Anonymous Coward
      If that c != -1 example isn't obvious, it may be safe to assume that former VB programmers have started programming in Java! Run!
    • I think the whole notion of a "character" type being assigned a numerical value is dubious in the first place. That's not to say the idea of a character coding that translates between characters and numbers isn't sensible, but the character itself is not a number - it's a character. I like Python's approach to the solution - there simply is no "atomic" character type (defining such a thing when character sets have characters that aren't uniform size is questionable anyway)

      So given that characters aren't n
      • I think the whole notion of a "character" type being assigned a numerical value is dubious in the first place.

        Can't be helped. You have to give the computer a way of understanding characters. Array indexes are a natural way for computers to do that.

        That's not to say the idea of a character coding that translates between characters and numbers isn't sensible, but the character itself is not a number - it's a character.

        A character in Java *is* a character. Nothing more, nothing less. It's a character. What

    • Re:master of the obvious (Score:5, Insightful)

      by AKAImBatman ( 238306 ) * <akaimbatman AT gmail DOT com> on Monday November 07, 2005 @02:59PM (#13971793) Homepage Journal
      Amen. The Java Language Specification states that char IS NOT A NUMBER. It's a character representation and should be treated as such. Thus the entire example is contrived, and makes no sense. It *might* be interesting from the perspective of loading a file (e.g. buffer.append((char)in.read());), except that the IO streams provide Integers to get around the sign problem.

      This is why in computer science they have a term for supposed "idiosyncracies" like this: "Garbage In Garbage Out" (GIGO)
      • The Java Language Specification states that char IS NOT A NUMBER. It's a character representation

        Well, maybe that's the intended purpose. But its semantics don't sit totally easy with that. What does this print? (from p.25)

        System.out.println('H' + 'a');

        It prints '169'. The book goes on:

        From a linguistic standpoint, the resemblance between char values and strings is illusory. As far as the language is concerned, a char is an unsigned 16-bit primitive integer - nothing more.

        Yeah, in practice this

        • Well, maybe that's the intended purpose. But its semantics don't sit totally easy with that. What does this print? (from p.25)

          System.out.println('H' + 'a');

          It prints '169'. The book goes on:

          The real problem is the overloading of the '+' sign. This is just more evidence that operator overloading is harmful in general purpose langauges. Sure, that '+' is convenient for putting strings together, but it does cost in clarity.

          The reason for this behavior, BTW, is do you can do things like this:

          char lowerCase = '

          • Actually implicit casts are a bigger problem than operator overloading and less useful too.

      • Actually, the Java Language Specification is pretty clear that char is a number [sun.com]. From the spec:

        The integral types are byte, short, int, and long, whose values are 8-bit, 16-bit, 32-bit and 64-bit signed two's-complement integers, respectively, and char, whose values are 16-bit unsigned integers representing Unicode characters.

        char, being a number, is subject to integer math operations. Like someone posted, 'A' + 'B' comes up with the result 131 - as an int, at that, because all integer math on types

        • Char is actually implicitly cast to 'int' to perform mathematical operations. The char type itself has no bytecode support for math.

          In other words, char represents a Unicode value from '\u0 to \uffff'. The fact that it can be cast to a numerical value and operated on is secondary to the fact that it's not really a number and should not be treated as such.
    • Actually, the thing that's surprising is that (c == b) is false. You'd expect that the implicit conversion for equality testing would match the explicit one, whatever it is that it gives. Of course, the real issue is that Java really shouldn't have a "char" primitive, and certainly not one that accepts casts from numeric types.

  • Not interested (Score:4, Funny)

    by TreeHugger04 ( 739276 ) on Monday November 07, 2005 @02:36PM (#13971534)
    If the title of a puzzle book does not contain the letters s,u,d,o,k and u in it, I am not interested. Sorry.

  • /. is made of cheese (Score:4, Funny)

    by fohat ( 168135 ) on Monday November 07, 2005 @02:37PM (#13971548) Homepage
    The problem being that Slashdot Headlines are often either: a) Dupes, b) boring, c) difficult to read, d) poorly written, or possibly: q) made of cheese

    To the moon, Java!

  • is surprize good? (Score:3, Informative)

    by gtrubetskoy ( 734033 ) * on Monday November 07, 2005 @02:37PM (#13971553)
    There are several occurrences that really surprised me

    I'm somewhat puzzled by the premise of the book. I thought C/C++ was full of puzzlers, and that Java was supposed to fix all that. Puzzlers may be cute, but they are definitely bad (except for job security may be). BTW, my little test shows that this example also applies to C, except that it isn't as surprising since you have to specifically declare the variable as unsigned, e.g.

    int b = -1;
    unsigned char c = (unsigned char)b;

    Without "unsigned", char is -1, as expected.

    • Thats the whole point of the "puzzler" (Score:5, Insightful)

      by brunes69 ( 86786 ) <`gro.daetsriek' `ta' `todhsals'> on Monday November 07, 2005 @02:41PM (#13971593)
      It is to expose a flaw in the language.

      Why should a primitive byte be signed, but not a primitive char?

      And why can't I have an unsigned int primitive in Java?

      Primitives in Java are a real pain to work with compared to most languages.

      • Re:Thats the whole point of the "puzzler" (Score:5, Insightful)

        by $RANDOMLUSER ( 804576 ) on Monday November 07, 2005 @02:47PM (#13971651)
        > Why should a primitive byte be signed, but not a primitive char?

        Because a byte is a numeric class, and a char is a character class? Your question is like asking why booleans can't be signed or unsigned.

        • Agreed. There is no Unicode value -1, so how does it make sense that you should be allowed to store that value in a type that represents a system where that value doesn't exist? I think it makes perfect sense, and I'm a pretty damn hardcore C fanboy. I never did like the unsigned-ness of char, I always thought there should have been a type 'byte' that represented an unsigned 8-bit value, and left char to deal with ASCII stuff.

          Off topic, but is there any C that defines sizeof(char) != 1? I'd be interested to

        • Re:Thats the whole point of the "puzzler" (Score:5, Informative)

          by _xeno_ ( 155264 ) on Monday November 07, 2005 @03:57PM (#13972440) Homepage Journal

          What's the difference between short and char in Java?

          One is signed, the other is unsigned.

          chars are treated just like numbers in Java. You can do numeric comparisons with them, you can add them, you can subtract them, they're just numbers.

          By definition, a char in Java is a 16-bit unsigned value. It happens to represent a single UTF-16 sequence, although arguably you could have done that using a short.

          But, here, check the language spec [sun.com]. A char is just an unsigned short. That's it.

          • By definition, a char in Java is a 16-bit unsigned value. But, here, check the language spec. A char is just an unsigned short. That's it.

            I think you misunderstand the spec. From your link:

            For char, from '\u0000' to '\uffff' inclusive, that is, from 0 to 65535

            Just because it's a numerical value doesn't mean that it's an actual number.

            chars are treated just like numbers in Java. You can do numeric comparisons with them, you can add them, you can subtract them, they're just numbers.

            This is incorrect. If you

            • And this differentiates char from short how, exactly?

              The answer? A short gets translated to an int using a signed cast, and a char gets translated to an int using an unsigned cast.

              Beyond that, the two data types are identical.

              In fact, that whole "always convert to integer" thing essentially makes the use of bytes and shorts completely worthless outside of arrays, since all math done using them is just integer math.

              • And this differentiates char from short how, exactly?

                That's a good point. I supposed I should have also mentioned that byte and short are really just for low-footprint memory storage. 'int' is the currency of choice in the Java language. Casting up to int ensures that all math happens in a byte aligned fashion, not to mention that reduces the amount of silicon required by an embedded Java processor.
      • The rationale is that char is a type representing a character, and that in such a context a negative value doesn't make any particular kind of sense. A char is an index into unicode, nothing more. A byte is a data representation, so sign makes sense in that context.

        You can't have an unsigned int primitive because that would lead to confusion when trying to index into arrays. The type of an array index is signed int, and is that way for a bounds checking reason. If you had access to a primitive unsigned

        • That never really stuck me as a reasonable explanation.

          I always felt it was a cop out at some level on the part of java to exclude unsigned ints. Its java, for christ's sake, can't the array bounds issue be taken care of?
          • I think the problem is that Sun is too opposed to making language level changes (anything that requires a change in the VM). They've done so much work in optimizing the performance for the existing VM, they're afraid of anything with consequences for their optimizer, and unfortunately from that perspective it seems fairly clear that allowing for unsigned ints would present a danger to the optimizer.

            Frankly, I'm with you though, I wish they would just bite the bullet and fix up the raw types to have a signe
          • Adding unsigned operators would burn a whole lot of opcode space and
            there are only 256 potential opcodes. You'd need unsigned comparisons,
            unsigned flavors of all the arithmetic operators for each data width and
            so forth. Probably have to introduce a one-byte "unsigned" prefix, and you
            might have to deal with the combination of the "unsigned" prefix and the
            "far" prefix for conditional jumps. This would slow down, complexify, and
            expand the size of the interpreter, which already takes 8 Meg to print
            "Hello Wo

      • Re:Thats the whole point of the "puzzler" (Score:5, Insightful)

        by kaffiene ( 38781 ) on Monday November 07, 2005 @03:51PM (#13972385)
        >Primitives in Java are a real pain to work with compared to most languages.

        Bullshit. I've coded through asm, c, c++, java and they all have their own ways of doing things which you need to be aware of. The language is NOT the problem.
      • One generally uses Java for its excellent OO-ness, not because they want to use primitives...
      • Why should a primitive byte be signed, but not a primitive char?

        Because all numeric types are signed in Java, whereas char is not intended as a numeric type but rather a direct mapping to UTF-16 (which uses codepoints 0 through 65535). It makes perfect sense.

        And why can't I have an unsigned int primitive in Java?

        Highly debatable issue, but I think the simplification in types is worth more than unsigned types are.

    • Re:is surprize good? (Score:2, Informative)

      by Anonymous Coward
      Every language with some substance will evolve have its "puzzlers".

      By the way, here is a great online puzzlers lecture by the two same guys. Its located here: http://www.javalobby.com/av/javapolis/25/bloch-puz zlers?source=archives [javalobby.com] but unfortunately you'll need to login to see it. Enjoy!

    • I'm somewhat puzzled by the premise of the book. I thought C/C++ was full of puzzlers, and that Java was supposed to fix all that.

      Java is a quite a bit simpler than C++, but it certainly has its share of tricky corner cases and surprising features. I started reading through the first few chapters while browsing in a bookstore, and although I was quite proficient in Java years ago there were some puzzles that stumped me. It reminded me just how complicated parts of Java are. Anyone who claims to know Java

    • Whether the base 'char' type is signed or unsigned in C is implementation dependent, which makes it a little more interesting.
    • As any platform + language, Java tries to do a lot of things. And like everything in this world, it is not perfect. Some of the problems could have been avoided (the rather unnecessary overloading of the operator &, meaning both && with both expressions evaluated and the bitoperand AND). Others could not. Don't forget that Java is pretty old (1985 if I am not mistaken), and when it was invented people tended to scream at you when you did anything like wasting a byte or a CPU cycle. And some thin

      • Don't forget that Java is pretty old (1985 if I am not mistaken)

        Actually it was invented in 1994 [about.com] and is younger than most big scriping languages today, many of which support arbitary sized numbers automagically (using int for numbers small enough internally and a more complicated type for big ones). There is absolutely no excuse for Javas flaws through the age argument. Most other languages invented around that time even managed to make the primitives look like objects from the language user point of view.

    • Re:is surprize good? (Score:2, Informative)

      by dascandy ( 869781 )
      > Without "unsigned", char is -1, as expected.

      Without "unsigned", the signedness of char is undefined. See also the C standard (ISO 9899:1999).

      Which explains why in C++ (a derived language) special specializations were made from templates to include both signed char and unsigned char, with a third charT template type for internal "char"-like data.

      GCC includes a compile-time flag that allows you to make them unsigned (-funsigned-char).

      • Without "unsigned", the signedness of char is undefined.

        Nitpick of the day: not "undefined" but "implementation defined".

        In C's version of standardese, "undefined" basically means something you shouldn't ever do, but the compiler isn't required to stop you from doing. "Implementation defined" means something that may vary in some way from one compiler to the next, but that it's still perfectly reasonable to do.

        --
        The universe is a figment of its own imagination.

    • C and C++ full of puzzlers? C has no puzzlers- its the perfect WYWIWYG language (What you write is what you get). The compiler never assumes or makes a choice on anything. C++ has some, mainly around when constructors/destructors get called.

      Java has a shit ton. The Java language spec is several times the size of C++. Its larger even if you ignore the standard libraries. And 1.5 is just adding on more cruft. THe only other language even close to Java on this front is perl.

  • Java puzzles? I do them everyday (Score:3, Insightful)

    by helix_r ( 134185 ) on Monday November 07, 2005 @02:49PM (#13971666)

    Unfortunately, real-life java problems are never very interesting.

    Invariably the solution consists of editing an annoying xml config file, or perhaps correcting one of my daily misconceptions about some boring detail in whatever convoluted j2ee framework I am forced to work with.

  • Code books in general? (Score:4, Insightful)

    by RingDev ( 879105 ) on Monday November 07, 2005 @02:52PM (#13971701) Homepage Journal
    Why bother? I have 1 HTML/CSS book I keep on hand just because I've used it so much. Everything else, I use google. Its faster (for me) to find designs, references, and code samples online then it is for me to get a book, look up the index and flip through the pages. I even gave up on my old SQL bible as Google can get me syntax and samples faster then I can find them in the book.

    -Rick
    • The tutorials and code samples that are online are often trivial when compared to the in depth detail that you will find in a good book. Also, they're often out of date and some what misinformed. Don't get me wrong, I've done a lot of research online and lots of the information was very well presented and put together however I don't think I've ever seen a tutorial or paper that is as good or equivalent to some of the professionally written books available. I also hate reading large books or tutorials on

  • I'm sure (Score:3, Funny)

    by jkind ( 922585 ) on Monday November 07, 2005 @02:52PM (#13971705) Homepage
    I'm sure a book called C Puzzlers would sell at least twice as well as this.
    • I think you would have to title the book "GCC Puzzlers" or something of the sort. Different compilers give you different behavior for C. For example, how big is an int? Java is much more concrete.

    • I'm sure a book called C Puzzlers would sell at least twice as well as this.

      Would you settle for slightly different titles like these?
      C Traps and Pitfalls [literateprogramming.com]
      Enough Rope to Shoot Yourself in the Foot [holub.com]

      Fortunately, there's also:
      The C Answer Book [about.com]
      Which obviously has all the answers. :-)

      Actually, none of these is settling at all -- all three are excellent books, at least IMO. Much of Holub's book also applies about as well to Java as to C or C++, for that matter.

      --
      The universe is a figment o

    • Sure, if you measure sales by mass. That would be quite the thick book!

  • Online Version? (Score:3)

    by kevin_conaway ( 585204 ) on Monday November 07, 2005 @02:57PM (#13971769) Homepage
    Is there an online version? This seems like the type of thing I'd do on my lunch break or when I need a diversion. Something along the lines of the Python Challenge [pythonchallenge.com], would be cool. To me, it seems more natural to do these puzzles in soft form.

  • Missing Option (Score:3, Insightful)

    by Anonymous Coward on Monday November 07, 2005 @03:00PM (#13971804)
    Most technical books are: ...

    E) Out of date before the ink is dry.

    • Re:Missing Option (Score:3, Interesting)

      by Miniluv ( 165290 )
      Thats why I buy technology books instead. If I want a technical reference I use the internet, but if instead I want a book that explains the concepts and assumptions of a specific technology, and then walks through some use cases where the technology makes sense versus some where it doesn't, then it won't go out of date until that whole technology does. I've gotten a tremendous benefit from reading books like this on SANs, performance optimization, various wireless technologies, SIP, etc. All techs that hav

  • disappointed -- try the java cert exam (Score:5, Insightful)

    by SamSeaborn ( 724276 ) on Monday November 07, 2005 @03:02PM (#13971820)
    I was excited when I saw the "Java Puzzlers" subject heading. But that byte to char example left me under-whelmed.

    Have any other more interesting/fun examples?

    If you want some puzzlers, look for copies of the Sun Java Programmer certification exam. There's lots of "we're not testing to see if you're a good programmer, just testing to see if you can find the unexpected result in the insanity-pepper code" snippets there.

    boxlight

    • I enjoy obscure code examples as an antidote to drinking the Java is perfect Koolaid. Examples like:

         private int foo()
         {
            try
            {
               return 0;
            }
            finally
            {
               return 1;
            }
         }

      • Re:disappointed -- try the java cert exam (Score:4, Informative)

        by pclminion ( 145572 ) on Monday November 07, 2005 @05:58PM (#13973701)
        At least you get a warning when compiling that code: "finally clause cannot complete normally."

        When the Java syntax was being invented (borrowed from C is more like it), this should have been addressed by disallowing return statements within finally blocks. The only way control should exit a finally clause is by falling out the end.

    • I own the book (got it as a goodbye present when I left my previous job) and it is really, REALLY good. Yeah the example in the review isn't that interesting, but the other 100 or so are really amazing.

      I consider myself a somewhat experienced java developer, but they got me every single time. If you think you'r smart you certainly have to read this book, it'll slap you back to the ground.

      Example (let's hope I don't violate any copyright here, my intentions are to get more copies sold anyway ;-)

      Provide a dec

    • Another Example (Score:2, Interesting)

      by Anonymous Coward
      I've been to one of their talks -- they work at Google, and give occasional tech talks for the other engineers. Here's an example that they actually got from somebody else: it was accompanied by some general banter, and multiple options. (Disclaimer: I don't know if this is in the book.)

      public class bad {
      public static void main(String[] args) {
      bad.String s = new bad.String("hello");
      System.out.print(s + " ");

      • Haha... that's certainly tricky, but I don't think you can really fault Java for behaving that way. It's just doing exactly what you're telling it to do.

        Garbage In, Garbage Out :)
  • a book (That's like an analog webpage, for the neuronauts among us)
    Books are just as digital as webpages, with the possible exception of illustrations.
  • "byte b = -1;
    char c = (char)b;

    so c=-1, right? Wrong." ...surprised you?
  • Enough Rope to Shoot Yourself in the Foot [amazon.com] is an excellent example. It's a nice book that's easy to read. I keep a copy near the throne. It can be a bit preachy and I don't always agree with the author's stance, but it's still a good read.

    The Exceptional C++ [amazon.com] books are also easy reading.

    It really just depends on what you want. Way back when I was first moving from C to C++, I bought the book Simple C++ [amazon.com]. While it was a good book that was easy to read, it took far too long for me to gleam the information

  • Typo (Score:2)

    by vocaro ( 569257 )
    guiding Java into it's current incarnation --> guiding Java into its current incarnation

  • a char with a value of 65535? (Score:4, Insightful)

    by poot_rootbeer ( 188613 ) on Monday November 07, 2005 @04:04PM (#13972510)
    (In this case, byte is signed, char isn't, and the widening cast fills in bits, leaving c=65535.)
    char
    , being a character datatype, shouldn't have its value expressed as an integer.

    The correct value of
    c
    is the glyph or other character corresponding to entry 65535 in whatever character encoding Java is currently using. (Assuming UCS-2, it's an invalid codepoint and therefore undefined.)

    Yes, for purposes of demonstrating that
    int
    is stored as a signed value and
    char
    isn't the example is correct, but that's still a little more of an under-the-hood mentality that's more appropriate to C than to Java.
    • char, being a character datatype, shouldn't have its value expressed as an integer. The correct value of c is the glyph or other character [...]

      Now you're confusing the issue. You have conflated three distinct concepts -- a character code, which is a value denoting a specific character within a given encoding; a character, which is the abstract identity of a specific written glyph; and the glyph itself, which is a physical realization of the character in question. So no wonder you are confused.

      A "char,

  • Oh come on! (Score:2, Insightful)

    by Xarius ( 691264 )
    Kylar writes "When you have spare time and decide to do something with a book (That's like an analog webpage, for the neuronauts among us), how often do you turn to a computer related book? How often has it happened in the last year? Right. The problem being that computer books are often either: a) boring, b) difficult to read, c) poorly written, or possibly: d) made of cheese. Read on for the rest of Kylars' review.

    I know slashdot is hardly the pinnacle of good reporting, but that summary is bordering on t

    • Re:Oh come on! (Score:3, Funny)

      by Surt ( 22457 )
      Perhaps kylar has been submitting a lot of stories, gradually moving where he inserts the random garbage into the story description, to find out just how far the slashdot editors will read before posting a story. His research seems to indicate the slashdot eds give up around 350 characters.

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close