[SDL] C++ / SDL using bool vs. SDL_bool

John john at leafygreengames.com
Sun Mar 17 13:59:26 PDT 2013


On 03/17/2013 04:37 PM, Andreas Schiffler wrote:
> Since SDL is compiled as "C", I am not sure how one would switch to C++'s "bool"
> type and maintain binary compatibility across all platforms.

I think the proposal is that SDL should switch to *C*'s bool type (not C++'s).



>
> Using SDL_bool or similar enumerations have a clear advantage in C: they convey
> the programmers intent of a binary decision or result. In most cases, how this
> is implemented at the low level (bit, byte, int) is secondary unless data
> structures which are using these constructs need to scale to large numbers (i.e.
> think of a particle system tracking state with 8 SDL_bool's implemented as 32bit
> int vs an implementation as single 8bit byte and a bitmask - memory overhead is
> 32:1).
>
> A clear practical benefit is, that compilers can use this "boolean intent" to
> fail code during compilation which prevents bugs. Example:
>
> \\ int boolean
> int binary_result = MyFunctionReturningZeroOrOne(); \\ assume it returns 2
> instead of 0 because of a bug
> if (binary_result == 0) { DoSomethingGood(); } else { DoSomethingBad(); } \\
> DoSomethingBad can be called and we wouldn't know why until debugging
> if (binary_result == 2) { ... } \\ Compiler is fine with this, yet for a
> correctly implemented function, this would never be called
>
> \\ enum boolean
> SDL_bool binary_result = MyFunctionReturningTrueOrFalse(); \\ By definition of
> the result type, we cannot return anything else but TRUE or FALSE
> if (binary_result == SDL_TRUE) { DoSomethingGood(); } else { DoSomethingBad(); }
> \\ TRUE is clearly associated with DoSomethingGood; aka intent in code
> if (binary_result == 2) { ... } \\ Compiler will fail to compile or minimally warn
>
> The only downside is that one has slightly more code to write ... but that
> should never deter a good programmer. ;-)
>
> --Andreas
>
> On 3/17/2013 10:18 AM, Forest Hale wrote:
>> Two technical notes on C++ bool:
>> 1. comparison operators produce bool, and 0 and 1 are not considered
>> equivalent to false and true (or rather they are convertible but the compiler
>> may choose to warn about it).
>> 2. bool is 1 byte at least on x86 compilers, unlike an enum which is 4 bytes
>> on x86 compilers, they are not bit packed but they are still considerably
>> smaller than an enum definition of bool, it's
>> best to group them in a struct to save memory (for the same reason one should
>> group all same-size types so they don't need to be padded to alignment).
>>
>> On 03/17/2013 09:38 AM, John wrote:
>>> It's just a matter of it being a modern built-in type. You would use it for
>>> the same reasons you would use the built-in "string" type in a language. The
>>> advantage is code clarity and widespread
>>> familiarity.
>>>
>>> In C, there is a small technical advantage to using the built-in bool over a
>>> UDT. bool might minimize use of space in memory, registers, etc., because
>>> bool is typically 8-bits, while enums are
>>> typically native ints, unless forced to be otherwise via compiler-specific
>>> options.
>>>
>>> In C++, there are several technical advantages of bool being a distinct type,
>>> such as overloading, template specialization and implicit conversion.
>>>
>>> For SDL, I'd say the advantage is mostly one of keeping up appearances. :)
>>>
>>>
>>>
>>> On 03/17/2013 07:28 AM, Vittorio Giovara wrote:
>>>> Is there any advantage in using bool at all?
>>>> As far as I know packing one bit in memory or in a struct will usually
>>>> wrap the variable or struct in at least a byte segment in memory; so
>>>> using a uint8_t type and a 0 or 1 value could achieve the same thing
>>>> and without adding a new type.
>>>> Or did I miss something?
>>>> Vittorio
>>>>
>>>> Sent from my iPad Mini
>>>>
>>>> On 17/mar/2013, at 00:45, John <john at leafygreengames.com> wrote:
>>>>
>>>>> C99 declares both bool and _Bool, plus a macro, __bool_true_false_are_defined.
>>>>> The point of the macro is so you can fix these sort of custom boolean types
>>>>> in older code without breaking anything.
>>>>>
>>>>>
>>>>>
>>>>> On 03/16/2013 05:47 PM, Sik the hedgehog wrote:
>>>>>> I think C99's support for boolean values consists of stdbool.h and a
>>>>>> _Bool type (*not* bool). Correct me if I'm wrong.
>>>>>>
>>>>>> 2013/3/16, Alex Barry <alex.barry at gmail.com>:
>>>>>>> On Sat, Mar 16, 2013 at 4:52 PM, Steven Noonan
>>>>>>> <steven at uplinklabs.net>wrote:
>>>>>>>
>>>>>>>> The 'bool' type was added in C99 (see section 7.16 in the C99 standard).
>>>>>>> That's true, but I think Sam's logic is to support the lowest common
>>>>>>> denominator - in this case, not every compiler will support a bool in
>>>>>>> standard C, and it is typical for a C library to define a TRUE/FALSE value.
>>>>>>>
>>>>>>> I think typically, if a programmer is using SDL from C++, they would be
>>>>>>> wrapping a lot of functions in C classes where SDL_Bool could be translated
>>>>>>> into bool true/false values.
>>>>>> _______________________________________________
>>>>>> SDL mailing list
>>>>>> SDL at lists.libsdl.org
>>>>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>>>> _______________________________________________
>>>>> SDL mailing list
>>>>> SDL at lists.libsdl.org
>>>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>>> _______________________________________________
>>>> SDL mailing list
>>>> SDL at lists.libsdl.org
>>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>>>
>>> _______________________________________________
>>> SDL mailing list
>>> SDL at lists.libsdl.org
>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>>
>>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



More information about the SDL mailing list