Not to be compared to a number



  • @accalia said:

    ++i++

    I'm sure they just wanted to confront your increment operator phobia ...


  • FoxDev

    @aliceif said:

    I'm sure they just wanted to confront your increment operator phobia ...

    in that case....



  • How does ++i++ even compile? The order of operations is ++(i++) which means you're trying to pre-increment an rvalue! C++14 doesn't accept it.



  • @Dragnslcr said:

    Why isn't this on the front page?

    Where? What? This forum exists, I know that much.


  • BINNED

    @accalia said:

    ```
    // more code using j this time, and some that uses j*2

    
    *j* is the π of programming world? :trolleybus:


  • @accalia said:

    i feel my reaction of turning around and unloading an entire clip of nerf darts at the developer who wrote that was entirely justified.

    You need a heavier weapon. I can lend you a memetic GAU-8.



  • @accalia said:

    @PleegWat said:
    Ew.

    yeah.

    i'm not sure what is worse... assigning j = i/2 and then using j*2 when i was still in scope and unchanged or that ++i++

    After j = i/2, j isn't necessarily equal to i/2, so j*2 isn't necessarily equal to i. (i might be odd, see below.)

    And even if it could compile, ++i++ would be UB anyway.

    And I like how nobody commented on the fact that i is an int and j is a short. That didn't bother me as such, because my first experience of C programming was on 8- and 16-bit machines where short and int are the same size...



  • @Steve_The_Cynic said:

    so j*2 isn't necessarily equal to i. (i might be odd

    You mean like this?



  • @LB_ said:

    @Steve_The_Cynic said:
    so j*2 isn't necessarily equal to i. (i might be odd

    You mean like this?


    i might be odd, or, indeed, it might hold a non-integer, because ++i++, regardless of any compiler switches that allow it to compile, exhibits UB for modifying i twice between sequence points.



  • @Gaska said:

    It is distinguishable. There is separate built-in type for booleans.

    The problem is that it isn't distinguishable from integer types, because it is an integer type itself. As you say, automatic promotion nullifies any gains, but even if it didn't the system would still be wrong. The reason that operators still return integers is because boolean is an integer type.

    In any sane language, a boolean is not an integer type. It's a symbolic type, orthogonal to all other types, instances of which which can hold 2 symbolic values - True and False. [spoiler]And FILE_NOT_FOUND and NULL, of course.[/spoiler] Any other values are meaningless.

    Assigning a value other than true or false to a boolean should be an error. Interpreting any other type as a boolean should be an error. Interpreting a boolean as some other type should be an error. This would have solved the OP's problem, in that the typing of ~ should be integer ← integer and the typing of ! should be boolean ← boolean - his code would have failed to compile with a static type error.

    The reason it's been done the way it has is because it would otherwise break existing code. Well, so fucking what? What's the big deal with changing if (x) to if (x != 0)? Requiring proper typing of booleans would have fixed a metric fuckton of bugs, edge cases and obiwan errors in existing code - it would have been a major move forward for security. How many times have you seen while (x)?

    Turning off automatic promotion might help, but it won't solve the issue entirely, and still allows for nonsensical code. And there's UB in there as well. for example:

    for (uint32_t x = 0x10002; x; x--) { … }

    Now, we're using an integer value x as a boolean, but a boolean is only specified to be able to hold the values 0 or 1. How is the conversion from uint32_t defined? Is it (possibly) x & 0x00000001, (improbably) x & 0x00010000, (most likely) x > 0?


  • Banned

    @tufty said:

    The problem is that it isn't distinguishable from integer types, because it is an integer type itself.

    Exactly. But it doesn't have to be.

    @tufty said:

    The reason it's been done the way it has is because it would otherwise break existing code.

    Backwards compatibility is #1 reason why computers suck. The moment the standard ccoommiittee realizes that this new C is completely new language and doesn't have to be fully compatible with this old language that's also called C, it will instantly become significantly better. Applies to every technology ever.



  • @Gaska said:

    Backwards compatibility is #1 reason why computers suck

    Quite.



  • Seen in the codebase today:

    If lstSomeUsers.SelectedItems.Count - 1 Then
       ' <Code that shows an error message that says that no user was selected>
       Exit Sub
    End If
    

  • BINNED

    INB4 list with multiselect enabled?



  • Oh belgium, it is?!

    That wouldn't make any sense though ...

    Thanks!


  • Banned

    Multiselect or not, the correct way is !=.



  • @Steve_The_Cynic said:

    And adding an operator bool() to a class should be punished by stabbing the offender with a GAU-8.

    ?

    Just how does one go about stabbing someone with a half-ton rotary cannon the size of a VW Beetle?


  • Banned

    With bayonet, of course!



  • <>, this is VB.NET


  • Banned

    My comment still stands - the correct way is !=.



  • @ScholRLEA said:

    Just how does one go about stabbing someone with a half-ton rotary cannon the size of a VW Beetle?

    Well, it's the memetic version. It can be stored in your back pocket and pulled out of there by people with ordinary-length arms (the real one is more than 20 feet long), so why can't it be pointy and blunt at the same time?

    And as Gaska says, with a bayonet, of course!



  • @Steve_The_Cynic said:

    UB for modifying i twice between sequence points.

    I'm pretty sure ++++i is not undefined behavior.



  • @ben_lubar said:

    Why wasn't it originally this:

    if (!(part in widget.availableParts)) throw new Error("Part "+part+" not available");
    ```</blockquote>
    
    @young gleemonk said:<blockquote>I DIDN'T KNOW YOU COULD DO THAT!</blockquote>
    
    I'm not sure whether I didn't remember or made a conscious choice not to use `in`. I still can't really decide which one would have been better. The `if (!(expression in expression))` construct is a bit noisy, I long for `if (expression not in expression)`. 
    
    To avoid the negation in the condition, I might have written it like this:
    
    

    if (part in widget.availableParts) {
    // good
    } else {
    throw new Error("Part "+part+" not available");
    }

    
    I find this breaks the flow of reading the least. I'm sure other people have gone :wtf: over this pattern because it's really unexpected to have empty blocks. It also collides head-on with my golfing habit :smile:

  • Java Dev

    @LB_ said:

    @Steve_The_Cynic said:
    UB for modifying i twice between sequence points.

    I'm pretty sure ++++i is not undefined behavior.

    IIRC, C++ doesn't even have sequence points anymore? And in plain C ++i is not an lvalue.


  • Winner of the 2016 Presidential Election

    @PleegWat said:

    IIRC, C++ doesn't even have sequence points anymore?

    The concept is still there, they just changed the phrasing AFAIK.



  • "Maid Vulkan" it says on the side. Probably the best kind.


Log in to reply