Wait, its what type again?



  • Here's the representative line from my latest annoyance:

     byte b = 128;

     

    Background info:

    1) This is in java.

    2) the "byte" type in Java is a signed byte.

    3) The allowable range for a signed byte is -128 to 127.



  • @RichP said:

    2) the "byte" type in Java is a signed byte.

    This is TRWTF!



  • Right. Who'd ever need to sign a byte?



  • @veggen said:

    Right. Who'd ever need to sign a byte?

    Was that genuine or sarcasm? On the one hand, signed bytes are legitimate - if you have both signed and unsigned 16-, 32-, and 64-bit integers, why not have both signed and unsigned 8-bit integers as well? But on the other hand, making bytes signed by default is rather stupid - unless you're using the way old-school 7-bit ASCII, you're going to have a lot of gotchas when doing pretty much anything! .NET at least calls the unsigned one "byte" and the signed one "sbyte"; sure, it breaks the convention introduced by "ushort", "uint", and "ulong", but IMO bytes are special enough to warrant this inconsistency.



  • @ekolis said:

    @veggen said:
    Right. Who'd ever need to sign a byte?

    Was that genuine or sarcasm? On the one hand, signed bytes are legitimate - if you have both signed and unsigned 16-, 32-, and 64-bit integers, why not have both signed and unsigned 8-bit integers as well? But on the other hand, making bytes signed by default is rather stupid - unless you're using the way old-school 7-bit ASCII, you're going to have a lot of gotchas when doing pretty much anything! .NET at least calls the unsigned one "byte" and the signed one "sbyte"; sure, it breaks the convention introduced by "ushort", "uint", and "ulong", but IMO bytes are special enough to warrant this inconsistency.

    Except Java doesn't have unsigned numeric types.



  • @ekolis said:

    @RichP said:
    2) the "byte" type in Java is a signed byte.

    This is TRWTF!

    In Java, 'byte' simply means an 8-bit integer, 'short' means a 16-bit integer (discouraged for performance reasons), 'int' means a 32-bit integer and 'long' means a 64-bit integer. Also, all integers (and all numeric types for that matter) in Java are signed.

    Whether this is a good idea or not is open to debate, but the thinking behind this is that in the C of 1995, the size of 'int' was not defined, and therefore 'int' on one machin/architecture could be something different from 'int' on another. That, at least, Java solved.



  •  @RichP said:

    Here's the representative line from my latest annoyance:

     byte b = 128;

     

    I that code you inherited? Because i can't see a way such code would compile in java:

    128 is out of range for a byte
    according to language specifications, 128 is an int. The compiler can allow implicit casting to byte only if this immediate value is within range. Otherwise you get a typecast error at compile time (can not convert from int to byte)

     

    If that's code you typed, don't start whinning about how it does not work, go learn language.

     



  • @tchize said:

    @RichP said:

    Here's the representative line from my latest annoyance:

     byte b = 128;

     

    I that code you inherited? Because i can't see a way such code would compile in java:

    It doesn't.

    @javac said:

    error: possible loss of precision



  • @tchize said:

     @RichP said:

    Here's the representative line from my latest annoyance:

     byte b = 128;

     

    I that code you inherited? Because i can't see a way such code would compile in java:

    128 is out of range for a byte
    according to language specifications, 128 is an int. The compiler can allow implicit casting to byte only if this immediate value is within range. Otherwise you get a typecast error at compile time (can not convert from int to byte)

    If that's code you typed, don't start whinning about how it does not work, go learn language.

     

    Yea, I know it's out of range for a signed byte. That's kinda the whole premise of my WTF.

    It's code I inherited.

    I'm not whining it doesn't work, I'm bewildered at how it ever ran. Based on the code surrounding it, either the compiler automagically converted the variable to an int, or this method was never really called. Or tested. Or code reviewed. Or investigated as to why it generated warnings when the project was built.

    I base that on the fact that later on, b gets bit-shifted while b <> 0. I think they intended for b to be = '10000000' and shift the one to the right each time through the loop. Guess what happens to a signed byte when you do a >> operation if the sign bit is set? End result is, the loop gets stuck looping forever with b = -1.

     

     



  •  @Severity One said:

    Java (discouraged for performance reasons)

    Your words, man, but I totally agree.



  • @badcaseofspace said:

    @Severity One said:
    Java (discouraged for performance reasons)
    Your words, man, but I totally agree.

    Hey, I'm a Java programmer of heavy server applications and I resent that remark. ...Unless of course you're referring to the startup time, client-side behavior, the web plugin, or anything GUI-related. Or you're talking about memory performance rather than speed. But other than that it's pretty good! We use it constantly on my team and my well-programmed Java code blows badly-programmed C code out of the water any day!



  • @Xyro said:

    my well-programmed Java code blows badly-programmed C code out of the water any day!
     

    Is this one of those "my finely-sculptured turd is better-looking than your misshapen lump of gold" comparisons?



  • @Cassidy said:

    @Xyro said:

    my well-programmed Java code blows badly-programmed C code out of the water any day!
     

    Is this one of those "my finely-sculptured turd is better-looking than your misshapen lump of gold" comparisons?


    Nah, not really.


Log in to reply