A field of mutually exclusive bits.



  • @blakeyrat said:

    So in conclusion, this code only runs on those non-mainstream consoles, like Xbox 360, PS3 and Wii-U. All those SUPER-MAINSTREAM consoles like Ouya you're scre-- wait... it runs on Ouya too? Shit.

    I explicitly said XBox and PS3 were mainstream consoles, but that Mono didn't run on other mainstream consoles. Stop failing at reading comprehension.

    @blakeyrat said:

    @Arnavion said:
    I was just using that as an example to say that there's no Java for XBox.

    Well herpderp, who said there was?

    You're the one who brought up writing games in managed languages, then mentioned C# and Java. I gave reasons why writing it in C# would mean the game won't run on any mainstream consoles except the XBox and PS3, and that writing it in Java would cause it to not even run on those two.

    @blakeyrat said:

    @Arnavion said:
    I'm agreeing that KSP is a single data point and not statistically significant. While I have a (subjective) feeling that it's slower than a comparative native game would have been, it is a meaningless comparison because it, as you said, is still in development.

    THEN WHY THE FUCK WOULD YOU EVEN TYPE IT

    You deserve to be insulted.

    Look, I'm trying to be on your side here. Stop being dumb.



  • @blakeyrat said:

    @eViLegion said:
    Fair enough. I agree that bad coders could easily read this, and conclude they should do it in unsuitable situations (e.g. where memory isn't tight), and they wont consider the things that need considering, and that would be bad.

    There's a lot of trash on the streets. I can't solve that problem. But I can put my own trash in a trash can.

    Again fair enough.



    Don't get me wrong though... I'm not advocating this design pattern* as a general solution, it's just an interesting talking point. If I wasn't concerned by tight memory, I doubt I'd ever use it at all. But where such potentially dangerous patterns have some genuine use, I think they should be used carefully, but without worrying too much about if some dumb-ass pleb is going to subsequently misuse them. I can't be held responsible for the plebs fucking shit up!


    • I use the term as loosely as it can be used


  • @Arnavion said:

    You're the one who brought up writing games in managed languages, then mentioned C# and Java. I gave reasons why writing it in C# would mean the game won't run on any mainstream consoles except the XBox and PS3, and that writing it in Java would cause it to not even run on those two.

    Yeah, well we all agree Java is shit. For everything, but especially game development. I don't believe that was ever in any doubt.

    The only reason I brought up a successful game written in Java is to demonstrate that it doesn't matter what a game is written in. If it's a well-designed game, it'll sell well. If it's not, it won't. So game developers are foolish to use a hard-to-write language instead of an easy-to-write language.

    @Arnavion said:

    Look, I'm trying to be on your side here. Stop being dumb.

    I call out bullshit when I see it, regardless of what "side" people are on. Saying, "mono games suck because Kerbal Space Program, a game that is version 0.22, runs a bit slow" is one of the dumbest things I've heard on this site. Demonstrating that you already knew it was dumb before you typed it only makes things worse.



  • Lol @ the concept of being on blakeyrat's side.


    Blakey is clearly only on the side of what he regards as the truth. I have to say I rather respect that... Regardless of whether I agree with him, he'll bring it strong, with solid conviction, and that's not a bad thing. People who give ground, and agree to things they don't believe in, are essentially liars.



  • @blakeyrat said:

    Saying, "mono games suck because Kerbal Space Program, a game that is version 0.22, runs a bit slow" is one of the dumbest things I've heard on this site. Demonstrating that you already knew it was dumb before you typed it only makes things worse.

    Then do you have a counter-example? We're comparing managed to non-managed games here. I already admitted I don't know how XNA games compare to native games on XBox, so I don't care if XNA games are as good as (or better than) native games on XBox. If you know a Mono game that is as good as a native game, then I'd like to know, because so far my only experience with such a game has been KSP and for "certain reasons that may not be objectively relevant" I find KSP to be worse.

    My opinion about this matters to no one but myself. I'm just curious about other people's point of view on managed games.



  • I realize now that
    @Arnavion said:

    Look, I'm trying to be on your side here. Stop being dumb.

    is open to misinterpretation. By "Stop being dumb." I was referring to my previous statement about you failing at reading comprehension. I wasn't implying that I was sucking up to you or something.


  • Discourse touched me in a no-no place

    @eViLegion said:

    Re-read what I said. I know it is "undefined behaviour". But the point is, on any given system it is deterministic behaviour
    You're really not getting this 'undefined behaviour' business are you? In other parts of the specs, the undefined behaviour can change with something as simple as the optimisation settings used to compile the code (i = i++ is usually used as an example of this because it tends to be susceptible to this.) Just because for your compiler it appears to be stable, doesn't mean it either (i) will be stable in future (ii) stable even now and you're just getting lucky. Unless the documentation for your compiler indicates that they have defined such behaviour as, erm, defined for their implementation?


  • ♿ (Parody)

    @Arnavion said:

    By "Stop being dumb." I was referring to my previous statement about [blakeyrat] failing at reading comprehension.

    I suggest you find a new windmill to tilt at.


  • Considered Harmful

    @Arnavion said:

    Go read the LLVM blog entries about clang and UB: Part 1 Part 2 Part 3

    +1 Informative



  • @eViLegion said:

    I'm not sure what you mean by 'duplicate your struct definition'. I'm genuinely interested to know.

    You'll have to forgive me, my C is a bit rusty. Your typical flyweight struct with union:

    struct Foo
    {
        int foo;
        union
        {
            int bar;
            float floatBar;
        }
    }

    Now what do you do here?

    void derp(Foo foo)
    {
        foo.bar = 12;  // ??
        foo.floatBar = 12.0;  // ???
    }

    Using two structs instead:

    struct Foo
    {
        int foo;
        int bar;
    }
    struct FloatFoo
    {
        int foo;
        float bar;
    }

    Add alignment and padding as necessary if you absolutely must reinterpret_cast. Problem solved.



  • @blakeyrat said:

    @Arnavion said:
    Game programming (and game-related programming like drivers) is one of those dark recesses of software development where people ignore the standard libraries' list class for optimization concerns, abuse UB to copy bits, abuse processor timings for effects, use display drivers with undocumented fast-paths to cheat in framerate contests...

    All of which is unnecessary and a waste of time in 2013. How many times have you seen a buggy-ass game, because it was written in C++ when there was absolutely no reason to write it in a non-managed language? If XNA has contributed anything, it's to demonstrate that C# is more than sufficiently optimized to write any game you can imagine. And, meanwhile, one of the highest selling games ever isn't just written in Java (probably the WORST language to use for game development), it's not even GOOD Java.

    More like: game development is a field full of terrible programmers who operate almost solely on the "we've always done it that way" principle.

     

    Oh yes. I would like to present for your amusement: StarCraft and the trouble with linked lists.

    No, of course, part3 of that 3-part series doesn't exist.

    Most of the articles on that site are worth reading, too if you're a developer with some experience and for some reason had the thought of maybe working in the games industry.



  • @Faxmachinen said:

    @eViLegion said:
    I'm not sure what you mean by 'duplicate your struct definition'. I'm genuinely interested to know.

    You'll have to forgive me, my C is a bit rusty. Your typical flyweight struct with union:

    struct Foo
    {
        int foo;
        union
        {
            int bar;
            float floatBar;
        }
    }

    Now what do you do here?

    void derp(Foo foo)
    {
        foo.bar = 12;  // ??
        foo.floatBar = 12.0;  // ???
    }

    Using two structs instead:

    struct Foo
    {
        int foo;
        int bar;
    }
    struct FloatFoo 
    {
        int foo;
        float bar;
    }

    Add alignment and padding as necessary if you absolutely must reinterpret_cast. Problem solved.

    I must say I'm not really sure what that gains you. reinterpret_cast has the same undefined behaviour problems, does it not? (I'm sure you'll correct me if I'm wrong! :o)    )

    Plus, as I understand it, if you're using a union of a float and an int, and you write to the float, then you may read from that float no problem (assuming you haven't written to the int in the meantime), right?




    If you want to do something like the compact bitfield in a specifically portable way, wouldn't you use bit masking and shifting and some kind of Flags enumeration to help you?



    Meh... I guess what it comes down to is how idealistic you are about code. I understand that future proofing stuff is a big deal for some people, so 100% standards compliance seems important to them. I'm personally not that bothered about future proofing, and I'm generally happy to deal with problems as and when they occur. If I was trying to write the kernel of some operating system, then certainly I'd do everything to ensure compliance... but if writing something that uses DirectX, it's really not worth caring, as it will already be obsolete in about a minutes time. I never like to subscribe to any coding religions like "don't use goto" or whatever; I feel that if you take the time to learn the arguments, then it's fair enough to make an informed decision to use potentially dangerous stuff in your code.

    @Arnavion said:

    Go read the LLVM blog entries about clang and UB: Part 1 Part 2 Part 3

    I finally got the time to actually look through that article properly... it's interesting stuff. I accept that in theory a union could be rather dangerous if hidden optimisations are applied. I had been under the impression that the compiler was specifically not allowed to fuck with unions in that manner, although I cannot find any evidence to support this, so I can only presume I've been operating with false information. Even so, I'd be interested to know of some concrete examples of optimisations that will cause such unions to fail, specifically in mainstream compilers if there are some; I rather want to know exactly how likely this is to be a problem.



    Have you got any more good articles like that?



    @Arnavion said:

    :facepalm:

    Yeah, sorry, but one doesn't have infinite time to read everything that is linked to, right away. It seemed pretty reasonable to skim the article to find the specific point you were getting at. Turns out that there wasn't a specific bit, just the concept of the article in general WAS the point.


    Incidentally - please don't be angry if I'm rabidly disagreeing with you. I am prepared to take nothing on faith, so I tend to argue aggressively; its never personal, it's just that I tend to get fuller, better responses from people that way.



  • @eViLegion said:

    Have you got any more good articles like that?

    I don't have any references for how unions-related UB specifically is handled by real world compilers. I've never had any reason to look it up, so I'm content with the knowledge that it's UB and thus I shouldn't do it.

    @eViLegion said:

    Incidentally - please don't be angry if I'm rabidly disagreeing with you. I am prepared to take nothing on faith, so I tend to argue aggressively; its never personal, it's just that I tend to get fuller, better responses from people that way.

    If you're talking to me, I wasn't angry with you. That ":facepalm:" was in response to your attitude of "Arnavion linked me some articles about UB-handling in a real world compiler. I skimmed it and didn't see anything about unions. Therefore I'm going to ignore it and repeat the wrong things I've been saying so far." But now that you have read and assimilated it, all is forgiven.



  • @eViLegion said:

    I must say I'm not really sure what that gains you. reinterpret_cast has the same undefined behaviour problems, does it not? (I'm sure you'll correct me if I'm wrong! :o)    )

    Most likely, which is why you shouldn't use reinterpret_cast either. But a union is ambiguous at compile time, thus placing the burden of not fucking up on everyone that uses it in some way, not just on the dumb ass who decided to use reinterpret_cast.

    @eViLegion said:

    If you want to do something like the compact bitfield in a specifically portable way, wouldn't you use bit masking and shifting and some kind of Flags enumeration to help you?

    Why would I do that? A bit field is already compact and portable.

    @eViLegion said:

    Meh... I guess what it comes down to is how idealistic you are about code. I understand that future proofing stuff is a big deal for some people, so 100% standards compliance seems important to them.

    If by "future proofing" you mean "maintainable", then yes. In most business environments, unmaintainable code is worse than useless.

    @eViLegion said:

    I never like to subscribe to any coding religions like "don't use goto" or whatever; I feel that if you take the time to learn the arguments, then it's fair enough to make an informed decision to use potentially dangerous stuff in your code.

    Of course. When I say "anyone who uses unions should be shot" I actually mean "anyone who knows how unions work and understand the potential consequences of using it, yet still continues to do so, should be executed by a firing squad". Most people are ignorant, which just puts them in the "anyone who doesn't RTFM need a meeting with the clue bat" category.


  • Considered Harmful

    Actually, the article does momentarily contrast the difference between undefined behavior and an undefined value, with the latter limited to a much smaller subset of bad effects.


Log in to reply