Comment by Magma7404

1 day ago

The comment reappeared, and while you're right about using proper libraries to handle data, it doesn't excuse the "undefined behavior (uninitialized local variables)" that I still see all the time despite all the warning and error flags that can be fed to the compiler.

Most of the time, the programmers who do this do not follow the simple rule that Stroustrup said which is to define or initialize a variable where you declare it (i.e. declare it before using it), and which would solve a lot of bugs in C++.

15 comments

Magma7404

Reply
trinix912  1 day ago

While it doesn't excuse the bad habits, we do have to keep in mind C++98 (or whatever more ancient was used back then) didn't have the simple initializers we now take for granted. You couldn't just do 'Type myStruct = {};' to null-initialize it, you had to manually NULL all nested fields. God forbid you change the order of the variables in the struct if you're nesting them and forget to update it everywhere. It was just considerably more practical to do 'Type myStruct;' then set the fields when needed.

  • mrighele  1 day ago

    I haven't been using C++ for a number of years but I think you could set the default values of fields even back then. Something like

        struct test {
        int my_int = 0;
        int* my_ptr = std::nullptr;
    };

    Or is this something more recent ?

    You cannot initialize them with a different value unless you also write a constructor, but it not the issue here (since you are supposed to read them from the file system)

    • MrRadar  1 day ago

      That's C++11 syntax. Before then you'd have to manually initialize them in every constructor, with a hand-written default constructor as a minimum:

          struct test {
        int my_int;
        int *my_ptr;
        
        test() : my_int(0), my_ptr(NULL) {}
    };

Yeask  1 day ago

And it did not matter at all. The game shipped and was a success.

  • ryandrake  1 day ago

    This is the thing that drives artists and craftsmen to despair and drink: That a flawed, buggy, poor quality work can be "successful" while something beautiful and technically perfect can fail.

    • soulofmischief  1 day ago

      San Andreas might be rough under the hood, but on the surface it was nothing short of a masterpiece of game design. The engine was so complex and the cities felt alive, and the game could handle a lot of general nonsense. Still one of my favorite go-to games.

    • butlike  1 day ago

      The job of the artist is to take the years of expertise and distill it down into something "enjoyable." The hardest mental hurdle to get over is that people just don't care about the technicals being perfect. Hell, the final product doesn't even need to be beautiful; it just needs to be arresting.

      1 reply →

    • RHSeeger  1 day ago

      One artist can take months painting a picture of a landscape where everything is perfect. And the next artist can throw 4 colors of paint at a wall. The fact that lots of people enjoy the work of the second artist doesn't invalidate the work of the first. The two artists are focusing on different things; and it's possible for both of them to be successful at reaching their goals.

    • Yeask  1 day ago

      Some artist also think "is mot music because it has no guitars".

      The standars "artist" have are atificial and snoby.

      How can Deadmau5/whatever EDM artist sell so much?

  • usefulcat  1 day ago

    Let's be clear that it was a success very much in spite of UB, not because of it. And there was still a cost--likely at least hundreds of person-hours spent fixing other similar bugs due to UB (if not more).

    I worked in gamedev around the time this game was made and this would have been very much an ordinary, everyday kind of bug. The only really exceptional thing about it is that it was discovered after such a long time.

mschuster91  1 day ago

> it doesn't excuse the "undefined behavior (uninitialized local variables)" that I still see all the time despite all the warning and error flags that you can feed to the compiler.

Yeah but we're talking about a 2004 game that was pretty rushed after 2002's Vice City (and I wouldn't be surprised if the bug in the ingestion code didn't exist there as well, just wasn't triggered due to the lack of planes except that darn RC Chopper and RC plane from that bombing run mission). Back then, the tooling to spot UB and code smell didn't even exist or, if at all, it was very rudimentary, or the warnings that did come up were just ignored because everything seemed to work.