Purpose of orxBOOL, orxFLOAT...

edited January 2012 in General discussions
Here's a basic question that I've been wondering about since I started my project. What's the purpose of variable types orxBOOL, orxFLOAT compared to regular bool or float ? Why should I use those instead of bool, float ? Why isn't there orxINT as well ? I'm a bit puzzled since I think you're able to set an orxBOOL to true or false while you're supposed to set it to orxTRUE or orFALSE.

Is it for portabiblity, to be sure every platform has the same limitations with variables ? Is it for the sake of having 'orx' written everywhere and helping orx being found by google ?

Wouldn't a program be smaller or faster if I didn't use these variable types ?

Comments

  • edited January 2012
    So, yep, it's for portability sake, not just for the fun of writing orx everywhere. :)

    - There's no bool type in ANSI C (and no false/true either). Orx is mainly written in C, not in C++.
    C99 introduced a _Bool type (with helper macros defined in stdbool.h) but wasn't widespread when orx was started, over 10 years ago.
    Also C++ bool doesn't have the same size as C _Bool, which trigger a whole new world of issues when dealing with serialization or memory alignment.

    - orxFLOAT (and orxDOUBLE) is defined so that users don't have to care if there's a FPU or not on the target architecture (think GBA & Nintendo DS, for example, where there's no FPU).
    In this case we'd replace all the floating points by fixed points, through the set of helper macros (orxFLOAT, orx2F, orxU2F, etc...).

    - There's no orxINT as int by itself doesn't give much valuable information and depends on the underlying architecture.
    Instead are defined orxS8, orxS16, orxS32, orxS64 / orxU8, orxU16, orxU32, orxU64.

    There won't be any impact of speed as all the orx types are just typedefs. As for space, the only bigger type would be bool as it's always using 32 bits whereas C++ would pack them. That's why orx is using flags instead when size matters.

    All the portability stuff is defined in orxDecl.h and orxType.h, that includes OS, compiler, CPU and endianness recognition as well.
  • edited January 2012
    Thank you for the explanations. I understood that I needed to write orx2F before float values I typed, like orx2F(0.5f) instead of just 0.5f. Apparently orxS32 is the equivalent to int.

    I'm reading a site that says a bool is 32 bits in c++, I thought naively it was just 1 bit. Then it doesn't sound so wierd that an orxBOOL is 32 bits as well.
  • edited January 2012
    grumly wrote:
    Thank you for the explanations. I understood that I needed to write orx2F before float values I typed, like orx2F(0.5f) instead of just 0.5f. Apparently orxS32 is the equivalent to int.

    No problem! Now you see what the logic behind the orx2F and such is. :)
    orxS32 is indeed the equivalent of int on 32b architectures. orxU32 being the equivalent of unsigned int.
    I'm reading a site that says a bool is 32 bits in c++, I thought naively it was just 1 bit. Then it doesn't sound so wierd that an orxBOOL is 32 bits as well.

    Well, it might be implementation defined, I don't have the standards at hand.
    I know that Microsoft used to have 32b bools back in old versions of visual studio but switched to 1bit bools a few years ago, all those bools being packed which means that having 1 bool or 8 bool variables consecutively in memory would still take 1 byte of memory (there's no way to address less than 1 byte in modern architectures): ie. sizeof(bool) == 1 == sizeof(char).
Sign In or Register to comment.