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!

  • @over_clox
    link
    13
    edit-2
    14 hours ago

    Some languages define True as -1, which is NOT False…

    • @pHr34kY
      link
      17 hours ago

      I once wrote a library to replace an older one. Someone did this, and users were multiplying variables by booleans and negating them in formulas.

      I just made the new library less stupid and left the users to clean up their mess when migrating.

    • @[email protected]
      link
      fedilink
      1013 hours ago

      which is NOT False…

      You really didn’t need this; I would have just assumed that you were speaking the truth.

      • @over_clox
        link
        812 hours ago

        CONST False = 0, True = NOT False

        NOT as in the binary operator. What’s NOT of 0 in a 32 bit space? 0xFFFFFFFF, which is -1, which is ≠ 1

        Different languages, and even different programmers might interpret the concept and definition of True and False differently, so to save any ambiguity and uncertainty, defining your own critical constants in your own library helps make sure your code is robust.