I’m working through the vulkan tutorial and came across GLFW_TRUE and GLFW_FALSE. I presume there’s a good reason but in looking at the docs it’s just defining 1 and 0, so I’m sorta at a loss as to why some libraries do this (especially in cpp?).

Tangentially related is having things like vk_result which is a struct that stores an enum full of integer codes.

Wouldn’t it be easier to replace these variables with raw int codes or in the case of GLFW just 1 and 0?

Coming mostly from C, and having my caps lock bound to escape for vim, the amount of all caps variables is arduous for my admittedly short fingers.

Anyway hopefully one of you knows why libraries do this thanks!

    • Hoimo@ani.social
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      4 hours ago

      I have seen this, but with “Y”, “N” instead. That was the way the database stored it and the way the UI displayed it, but everything inbetween converted to boolean instead, because there was logic depending on those choices. It wasn’t that bad, all things considered, just a weird quirk in the system. I think there was another system that did just use those strings plain (like WHERE foo = 'Y' in stored procedures), but nothing I had to work with. We just mapped “Y” to true when reading the query results and were done with it.

      (And before anyone asks, yes, we considered any other value false. If anyone complained that their “Yes”, “y” or empty was seen as false, we told them they used it wrong. They always accepted that, though they didn’t necessarily learn from it.)

    • floofloof@lemmy.ca
      link
      fedilink
      English
      arrow-up
      2
      ·
      11 hours ago

      It would probably carry less risk, but in terms of bytes used this would be even worse. And we have other problems there that I’d tell you about but it would make me too sad.