this post was submitted on 15 Jan 2025
114 points (93.8% liked)

Programming

17832 readers
110 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

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!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 1 day ago (2 children)

why not just take it a step further and make true = “Yes” and false = “No”

[–] [email protected] 2 points 1 day ago* (last edited 1 day 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.)

[–] [email protected] 2 points 1 day 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.