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

Jonathan Dearborn grimfang4 at gmail.com
Sun Mar 17 17:10:13 PDT 2013


But to be portable to C++, you can't use C99 features.  Some common C++
compilers do not provide C99.

Jonny D


On Sun, Mar 17, 2013 at 4:59 PM, John <john at leafygreengames.com> wrote:

> 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<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<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<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<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<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<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130317/f0bb5111/attachment-0009.htm>


More information about the SDL mailing list