As long as it compiles...



  • It's code from one of my students, so it doesn't really count, but it made me say "WTF" regardless. Slightly anonymized, the language is C++:

    [code]SomeClass * a = new SomeClass;
    SomeClass * b = new SomeClass;
    SomeClass * c = new SomeClass;

    // logic goes here...

    delete a, b, c;[/code]

    Well, it compiles...

     

    For those not familiar with C++: the operator "[code],[/code]" evaluates both of its operands and returns the value of the second. Its precedence is also the lowest, so "[code]delete a, b, c[/code]" is equivalent to "[code](delete a), b, c;[/code]" and it deletes only the first pointer (and returns the value of [code]c[/code], which is immediately discarded).



  •  Considering it's from a student who's probably seen things like:

    int a,b,c;

    I wouldn't call this a WTF, I'd call it common sense pattern recognition failing in the face of how obtuse some parts of programming can be.

     

    Or, alternatively, you're the WTF for not making sure your student understood the difference.



  • I blame the language on this one.  I've never found the comma operator particularly useful, and whatever value it may have is vastly outweighed by the fact that it makes your code obtuse.



  •  Well, duh. C++ is one of the most assinine languages I've ever seen. Give me Java or C# over C++ any time unless there's a very specific reason I need such control over the memory.



  • @JohnWestMinor said:

     Well, duh. C++ is one of the most assinine languages I've ever seen. Give me Java or C# over C++ any time unless there's a very specific reason I need such control over the memory.

    Anytime I have to start dealing with binary data I want to start working with C/C++. I've yet to see a high-level language that handles binary data nicely.



  • For high-level, abstraction-based, safe, object-oriented stuff you have Java and C#.

    For low-level bit bashing, C is perfect.

    And as you can connect modules written in C to CLR, JVM, and just about everything else, I don't see any good reason for using C++ on new projects.

    Except, maybe, job security.
    Or having mind so twisted by C++ already that one likes it and believes it's appropriate choice.



  • @Lingerance said:

    Anytime I have to start dealing with binary data I want to start working with C/C++. I've yet to see a high-level language that handles binary data nicely.
    Ugh, this is one of those dumb things people say.  What the hell do you need to do with binary data that, say, Python can't do well?



  • @bstorer said:

    @Lingerance said:

    Anytime I have to start dealing with binary data I want to start working with C/C++. I've yet to see a high-level language that handles binary data nicely.
    Ugh, this is one of those dumb things people say.  What the hell do you need to do with binary data that, say, Python can't do well?

    Read a bit stream?  And by bitsteam I mean the sort of thing that goes: the first three bits indicate the type of object, then depending on the type of object the next n bits are option flags and then property values etc etc etc.



  • @bstorer said:

    Ugh, this is one of those dumb things people say.  What the hell do you need to do with binary data that, say, Python can't do well?
    Dealing with some of the more retarded binary streams that banks want us to send them, the C code tends to be quite simple, but the Python/PHP/MySQL (yes, having to do the last one is a WTF of it's own) code tends to be more complicated, and less clear. The clearer I make it, the bigger the function gets. It's mostly due to me wanted to deal with the raw string, and having to break through the abstractions to get to it. Eg: this one format requires EBDIC-encoded strings in some situations, 7-bit even parity "ASCII" in others, binary-coded-decimal for numbers, bit fields (which are fairly easy), and network-endian longs in certain other situations.



  • I have a Java application (game, actually) that serializes data over the network with all sorts of bitwise information. Bit fields and byte masks are pretty fundamental in any language. Maybe it's just because I've never done the equivalent with C, but to me, [code]int thingy = bytes[i] >>5;[/code] or [code]bool flag = b & FLAG_MASK;[/code] looks pretty straightforward. For Java and surely most all modern languages of the same brush, converting between bytes and Strings is trivial, even for custom encodings that don't come built-in. At worst, it would be the same to the way it's handled in C. Running things through BigInteger may cost you a bit more typing, but it's certainly better than having to deal with rest of the baggage C forces you to take care of.



  • @DescentJS said:

    Read a bit stream?  And by bitsteam I mean the sort of thing that goes: the first three bits indicate the type of object, then depending on the type of object the next n bits are option flags and then property values etc etc etc.

    Seriously?  What language have you looked at?  Sticking with Python for example, bitstring makes this utterly trivial.  God, I love Python's array splicing.

    @Lingerance said:

    Dealing with some of the more retarded binary streams that banks want us
    to send them, the C code tends to be quite simple, but the
    Python/PHP/MySQL (yes, having to do the last one is a WTF of it's own)
    code tends to be more complicated, and less clear. The clearer I make
    it, the bigger the function gets. It's mostly due to me wanted to deal
    with the raw string, and having to break through the abstractions to get
    to it. Eg: this one format requires EBDIC-encoded strings in some
    situations, 7-bit even parity "ASCII" in others, binary-coded-decimal
    for numbers, bit fields (which are fairly easy), and network-endian
    longs in certain other situations.
      I can't speak for PHP, but Python is extremely versatile in this field.  You get all the same bitwise operators C/C++ give you, but you also get intelligent objects to streamline things.  Some are better than others, but the same is more or less true for most HLLs.



  • @Xyro said:

    I have a Java application (game, actually) that serializes data over the network with all sorts of bitwise information. Bit fields and byte masks are pretty fundamental in any language. Maybe it's just because I've never done the equivalent with C, but to me, <font face="Lucida Console" size="2">int thingy = bytes[i] >>5;</font> or <font face="Lucida Console" size="2">bool flag = b & FLAG_MASK;</font> looks pretty straightforward. For Java and surely most all modern languages of the same brush, converting between bytes and Strings is trivial, even for custom encodings that don't come built-in. At worst, it would be the same to the way it's handled in C. Running things through BigInteger may cost you a bit more typing, but it's certainly better than having to deal with rest of the baggage C forces you to take care of.
    I actually think Java's a bit on the weak end of the scale, too.  For example, it complains constantly of possible precision losses when assigning bytes the results of bitwise operations.  Also, BitSet sucks hairy donkey nuts.



  • @Xyro said:

    I have a Java application (game, actually) that serializes data over the network with all sorts of bitwise information. Bit fields and byte masks are pretty fundamental in any language. Maybe it's just because I've never done the equivalent with C, but to me, <FONT size=2 face="Lucida Console">int thingy = bytes[i] >>5;</FONT> or <FONT size=2 face="Lucida Console">bool flag = b & FLAG_MASK;</FONT> looks pretty straightforward. For Java and surely most all modern languages of the same brush, converting between bytes and Strings is trivial, even for custom encodings that don't come built-in. At worst, it would be the same to the way it's handled in C. Running things through BigInteger may cost you a bit more typing, but it's certainly better than having to deal with rest of the baggage C forces you to take care of.

    Ever tried parsing a stream of unsigned byte values in Java?



  • @Abdiel said:

    Filed
    under: TRWTF is a language without a single damn unsigned type
    No argument here.

    Basically what you end up having to do is either use an [code]int[/code] or [code]long[/code] if the unsigned value is less than 32 or 64 bits, or BigInteger if it's larger.  To Java, bytes and shorts are all integers anyway, so casting all the [code]byte[/code]s you're directly manipulating into [code]int[/code]s (and applying a mask of 0xff) is a pretty common practice.  The real trouble is when you need have a mix of arrays of [code]byte[/code]s, [code]int[/code]s, and/or [code]char[/code]s. That's when java.io falls flat on its face because of the shockingly short-sighted Stream/Reader/Writer classes and their completely inconsistent use of primitives.  Then you have to break out the ByteBuffers and related objects to get anything done. Buuut... it's really not all THAT difficult to do.



  •  @bannedfromcoding said:

    For low-level bit bashing, C is perfect.

    The one time I really needed some bit bashing, I ended up using assembly.

    I had to flip a bitmap upside down, which means you also have to flip individual bytes. The fastest way I found to do that was with a repeated SCR/SCL (shift right carry/shift left carry).



  • @b_redeker said:

    The one time I really needed some bit bashing, I ended up using assembly.

    I had to flip a bitmap upside down, which means you also have to flip individual bytes. The fastest way I found to do that was with a repeated SCR/SCL (shift right carry/shift left carry).

    Hmm, that's an interesting problem with a variety of solutions.  Rather than using assembly, I think my vote would be for a lookup table.  Then you could do something like

    FLIPPED_BYTES = [0x00, 0x80, 0xC0, ..., 0x7F, 0xFF];
    for (i in output) {
        input[i] = FLIPPED_BYTES[output[length-i]];
    }
    

    where output and input are an array of bytes or equivalent.

    EDIT:  WHAT THE HELL WHY CAN'T I GET RID OF THOSE &nbsp;S!??!?!   THEY DON'T EVEN SHOW UP IN THE EDITOR!!  RRROOOOAAR





    <pre> instead of [code] makes us all sane boys. --Ling



  • TRWTF is allowing students to compile without warnings enabled. GCC gives a nice warning with -Wall and clang++ doesn't even need an option.



  • @bstorer said:

    @DescentJS said:

    Read a bit stream?  And by bitsteam I mean the sort of thing that goes: the first three bits indicate the type of object, then depending on the type of object the next n bits are option flags and then property values etc etc etc.

    Seriously?  What language have you looked at?  Sticking with Python for example, bitstring makes this utterly trivial.  God, I love Python's array splicing.

    @Lingerance said:

    Dealing with some of the more retarded binary streams that banks want us
    to send them, the C code tends to be quite simple, but the
    Python/PHP/MySQL (yes, having to do the last one is a WTF of it's own)
    code tends to be more complicated, and less clear. The clearer I make
    it, the bigger the function gets. It's mostly due to me wanted to deal
    with the raw string, and having to break through the abstractions to get
    to it. Eg: this one format requires EBDIC-encoded strings in some
    situations, 7-bit even parity "ASCII" in others, binary-coded-decimal
    for numbers, bit fields (which are fairly easy), and network-endian
    longs in certain other situations.
      I can't speak for PHP, but Python is extremely versatile in this field.  You get all the same bitwise operators C/C++ give you, but you also get intelligent objects to streamline things.  Some are better than others, but the same is more or less true for most HLLs.

    PHP handles it pretty well on a syntactical level, but is rather slow when it comes time to execute.  PHP was not built to do bitstream manipulation.  You do get the standard C operators, and there's no suprises there, but if you end up having to do bitstream operations inside of php code, you better rethink what you're doing.



  • @Xyro said:



    <pre> instead of [code] makes us all sane boys. --Ling
    True, although beware that pre can't save you from CS fucking up "[]".



  • @bstorer said:

    @Xyro said:



    <pre> instead of <font face="Lucida Console" size="2"> makes us all sane boys. --Ling</i>
    True, although beware that pre can't save you from CS fucking up "[". </p></font>

    I fixed that...



  • @Lingerance said:

    @bstorer said:

    @Xyro said:



    <pre> instead of <font size="2" face="Lucida Console"> makes us all sane boys. --Ling</i>
    True, although beware that pre can't save you from CS fucking up "[". </p></font>

    I fixed that...
    Wow, CS shat all over that, didn't it?  Anyway, my point was not directed at you, but everyone.  Rules of CS:

    1. Using pre tags won't solve everything
    2. Using code bbcode won't solve everything
    3. There is nothing you can do but lie down and wait for the sweet release of death



  • @bstorer said:

    Using pre tags won't solve everything

    I use pre tags all the time.



  • @morbiuswilters said:

    @bstorer said:

    Using pre tags won't solve everything

    I use pre tags all the time.

    So do I, but they aren't the silver bullet Ling implied they are.  CS fucks them up, too, because CS is awful and deserves to die.



  • @Shishire said:

    PHP handles it pretty well on a syntactical level, but is rather slow when it comes time to execute.  PHP was not built to do bitstream manipulation.  You do get the standard C operators, and there's no suprises there, but if you end up having to do bitstream operations inside of php code, you better rethink what you're doing.

    Actually, my experience was just the opposite. I was working with Sphinx, and due to our needs, we needed it to return upwards of 10k results to PHP. The native php extension for sphinx works by downloading the entire binary stream, decoding into PHP objects, and then returning. On some of our tests, it took over 500 mb of ram to do that... So I rewrote the class to stream the data, and the same resultset only took 1mb of ram to process. It's not nearly as fast as if I did it in native C, but it was plenty fast as it stood. That said, I'm not saying that PHP is great at bit streams, but it can do it if you need it to...



  • @bstorer said:

    CS fucks them up, too, because CS is awful and deserves to die.
     

    From all evidence I would guess CS has already died. It's more like a zombie.

    Not even a proper zombie: it's the one (you know who you are) who occasionally loses an arm or a vital organ, and then the whole gang has to wait (grumbling) until he picks it up and sticks it back on with some gaffer tape or a bit of spit. Disgraceful.



  • @JohnWestMinor said:

     Well, duh. C++ is one of the most assinine languages I've ever seen. Give me Java or C# over C++ any time unless there's a very specific reason I need such control over the memory.

    Agreed, why are you teaching C++? Corrupting their young minds with it?

    I mean, it could be worse. You could be teaching Perl.



  •  @bstorer said:

    @morbiuswilters said:

    @bstorer said:

    Using pre tags won't solve everything

    I use pre tags all the time.

    So do I, but they aren't the silver bullet Ling implied they are.  CS fucks them up, too, because CS is awful and deserves to die.

    Paste code. Go to the HTML window. Turn P into PRE.

    DONE.

    Like Morbius johnny, it is not hard.



  • @Abdiel said:

    Filed
    under: TRWTF is a language without a single damn unsigned type
    <input name="ctl00$ctl00$bcr$bcr$ctl00$PostList$ctl14$ctl23$ctl01" id="ctl00_ctl00_bcr_bcr_ctl00_PostList_ctl14_ctl23_ctl01_State" value="value:Filed%20under%3A%20%3Ca%20href%3D%22%2Ftags%2FTRWTF%2Bis%2Ba%2Blanguage%2Bwithout%2Ba%2Bsingle%2Bdamn%2Bunsigned%2Btype%2Fdefault.aspx%22%20rel%3D%22tag%22%3ETRWTF%20is%20a%20language%20without%20a%20single%20damn%20unsigned%20type%3C%2Fa%3E" type="hidden">
    I read an interview where Gosling said that they left unsigned out because it's complicated.

    Kinda puts everything in perspective doesn't it?



  • @dhromed said:

     @bstorer said:

    @morbiuswilters said:
    @bstorer said:
    Using pre tags won't solve everything
    I use pre tags all the time.
    So do I, but they aren't the silver bullet Ling implied they are.  CS fucks them up, too, because CS is awful and deserves to die.

    Paste code. Go to the HTML window. Turn P into PRE.

    DONE.

    Like Morbius johnny, it is not hard.

    PRE is a block element though, so for inline code bits, you'd still need to use [code][​​code​][/code]...



  • @belgariontheking said:

    @Abdiel said:

    Filed
    under: TRWTF is a language without a single damn unsigned type
    I read an interview where Gosling said that they left unsigned out because it's complicated.

    Kinda puts everything in perspective doesn't it?


    @Gosling said:
    Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up.
    😞



  • @Xyro said:

    PRE is a block element though, so for inline code bits, you'd still need to use <font face="Lucida Console" size="2">[​​code​]</font>...
    ... or you could use <code> or <tt>, both of which actually work and use a monospace font.



  • @Xyro said:

    Filed under: I used zero-width spaces to get it to display "[]code]" inside the []code].

    Just use the "official" CS BBCode escape, and type []]] to get []], and []] to get [].



  • @Lingerance said:

    @Xyro said:
    PRE is a block element though, so for inline code bits, you'd still need to use <font face="Lucida Console" size="2">[​​code​]</font>...
    ... or you could use <code> or <tt>, both of which actually work and use a monospace font.
    Oh ... wait, then why would I want to use <pre> at all if we've got <code> and the editor puts in the &nbsp;s in for us?

    Hmm... var testing = "testing testing"; ... I like <code> better.



  • @Xyro said:

    Filed
    under: <tt>? What does that stand for? Trouble Ticket?
     

    It's for obsolete stuff, apparently.



  • @DescentJS said:

    Read a bit stream?  And by bitsteam I mean the sort of thing that goes: the first three bits indicate the type of object, then depending on the type of object the next n bits are option flags and then property values etc etc etc.

     

    Google has released a pretty cool-looking cross-language library for dealing with binary data formats. I haven't tried it out yet, but it does, as I said, look pretty cool.



  • @Xyro said:

    @belgariontheking said:

    @Abdiel said:

    Filed under: TRWTF is a language without a single damn unsigned type
    I read an interview where Gosling said that they left unsigned out because it's complicated.

    Kinda puts everything in perspective doesn't it?

    @Gosling said:
    Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up.
    😞

    What is this Gosling dude smoking and where can I get some of it?

    Unsigned - easy. You have bit by bit exactly what you expect. Signed? What is (-14) ^ 9? Sign bit? Two's complement? And what about overflow? Naah, not touching that with a ten foot pole if I don't have to. Of course, talking about bitwise operators now - for standard arithmetic, + - * /, it's all the same, signed or unsigned. Ultil we get to modulus, which gets complicated with signed numbers again.



  •  At least javascript automatically converts its 64 bit signed floats to 32 bit unsigned integers when you use a bitwise operator on them.

    How's that for easy!



  • @dhromed said:

     At least javascript automatically converts its 64 bit signed floats to 32 bit unsigned integers when you use a bitwise operator on them.

    How's that for easy!

    Uhm... HWÆT? How the fck is that supposed to work?



  • @Abdiel said:

    How the fck is that supposed to work?
     

    Minor mistake: the result is a signed 32-bit int.

    @ECMA-262 5th edtion p.76 said:


    The production ShiftExpression : ShiftExpression << AdditiveExpression is evaluated as follows:
    1. Let lref be the result of evaluating ShiftExpression.
    2. Let lval be GetValue(lref).
    3. Let rref be the result of evaluating AdditiveExpression.
    4. Let rval be GetValue(rref).
    5. Let lnum be ToInt32(lval).
    6. Let rnum be ToUint32(rval).
    7. Let shiftCount be the result of masking out all but the least significant 5 bits of rnum, that is, compute rnum & 0x1F.
    8. Return the result of left shifting lnum by shiftCount bits. The result is a signed 32-bit integer.

    Does that answer your question?

     



  • @dhromed said:

    @Abdiel said:

    How the fck is that supposed to work?
     

    Minor mistake: the result is a signed 32-bit int.

    @ECMA-262 5th edtion p.76 said:


    The production ShiftExpression : ShiftExpression << AdditiveExpression is evaluated as follows:
    1. Let lref be the result of evaluating ShiftExpression.
    2. Let lval be GetValue(lref).
    3. Let rref be the result of evaluating AdditiveExpression.
    4. Let rval be GetValue(rref).
    5. Let lnum be ToInt32(lval).
    6. Let rnum be ToUint32(rval).
    7. Let shiftCount be the result of masking out all but the least significant 5 bits of rnum, that is, compute rnum & 0x1F.
    8. Return the result of left shifting lnum by shiftCount bits. The result is a signed 32-bit integer.

    Does that answer your question?

     

     

    Don't you guys be dissin' Javascript. It's designed to be a simple, easy-to-parse embeddable scripting langauge, like Lua. You're not supposed to be writing applications in it-- yes I know people are, but that's not Javascript's fault.



  • @blakeyrat said:

    You're not supposed to be writing applications in it-- yes I know people are, but that's not Javascript's fault.

     

    Except of course that the main designer of Javascript now belongs to exactly those guys that push the "The Web is our OS and JS is our assembly" paradigm the most...



  • Hm, so it at least does something moderately sane - rounding the floats to the nearest integer and operating on those, if I understand it correctly. I first thought it would do the bitwise operation on whatever happened to be the floating point representation of the number or something.

    Point 7 can be quite confusing for the inexperienced though. That is, (x << a) << b might not be the same as x << (a + b).



  • @blakeyrat said:

    Don't you guys be dissin' Javascript.
     

    I aint dissin'

    I be lovin'.

    Yo.



  • Yo, sup.




Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.