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

Jonathan Dearborn grimfang4 at gmail.com
Mon Mar 18 07:59:42 PDT 2013


Is that necessarily compatible with a library built with a C99 compiler?

Jonny D


On Mon, Mar 18, 2013 at 10:55 AM, John <john at leafygreengames.com> wrote:

> You can safely use bool in C++ :)
>
>
>
>
> On 03/17/2013 08:10 PM, Jonathan Dearborn wrote:
>
>> 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
>> <mailto:john at leafygreengames.**com <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
>>                     <mailto:john at leafygreengames.**com<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
>>                             <mailto:alex.barry at gmail.com>>**:
>>
>>
>>                                 On Sat, Mar 16, 2013 at 4:52 PM, Steven
>> Noonan
>>                                 <steven at uplinklabs.net
>>                                 <mailto: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 <mailto:
>> SDL at lists.libsdl.org>
>>                             http://lists.libsdl.org/__**
>> listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-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 <mailto:SDL at lists.libsdl.org
>> >
>>                         http://lists.libsdl.org/__**
>> listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-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 <mailto:SDL at lists.libsdl.org>
>>                     http://lists.libsdl.org/__**
>> listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-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 <mailto:SDL at lists.libsdl.org>
>>                 http://lists.libsdl.org/__**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-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 <mailto:SDL at lists.libsdl.org>
>>         http://lists.libsdl.org/__**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-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 <mailto:SDL at lists.libsdl.org>
>>     http://lists.libsdl.org/__**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/__listinfo.cgi/sdl-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/20130318/5178b84a/attachment-0009.htm>


More information about the SDL mailing list