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!
This is often done for backward compatibility, as stdbool.h which provides true and false wasn’t standard before C99 and even though that’s more than 25 years ago now a lot of old habits die hard.
Also, plenty of embedded systems don’t use the C standard library.
stdbool.h (along with float.h, limits.h, stdarg.h, stddef.h, stdint.h, and some other library facilities) is required to be provided even in freestanding environment so, at least as long as you use an ISO C conformant compiler, you can always include those even if you don’t have a libc implementation
Yeah in the late 90’s I was coding in C++ and I’m pretty sure I had to define true and false manually.
I seem to recall using the true and false literals C++ in the late '90s … looks like they were in the C++98 standard, but it’s not clear which pre-standard compilers might have supported them.
Ahh this makes some sense