C++ / SDL using bool vs. SDL_bool

What’s the benefits of using SDL_bool instead of regular bool on a C++ project using SDL?? I switched to SDL_bool because I figured it was some kind of portability thing.

I have the same question for SDL_free/SDL_malloc vs. malloc/free

I was also wondering if I can still use inexplicit if statements. for example:

Code:
SDL_bool power_on = SDL_FALSE;



if (power_on)
{

}

is that safe? or must it be explicit? ie. (if power_on == SDL_TRUE)

Remember that SDL is a C library and C doesn’t have bool (at least not
everywhere, I don’t remember exactly what was the situation with the
standard regarding boolean types in C).

SDL_free and SDL_malloc I think are indeed a portability issue though,
especially on systems like Windows where the standard library used by
the program can mismatch that of the other libraries it uses (you
really don’t want to accidentally mix those).

2013/3/16, bazz :> What’s the benefits of using SDL_bool instead of regular bool on a C++

project using SDL?? I switched to SDL_bool because I figured it was some
kind of portability thing.

I have the same question for SDL_free/SDL_malloc vs. malloc/free

The ‘bool’ type was added in C99 (see section 7.16 in the C99 standard).On Sat, Mar 16, 2013 at 1:31 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

Remember that SDL is a C library and C doesn’t have bool (at least not
everywhere, I don’t remember exactly what was the situation with the
standard regarding boolean types in C).

SDL_free and SDL_malloc I think are indeed a portability issue though,
especially on systems like Windows where the standard library used by
the program can mismatch that of the other libraries it uses (you
really don’t want to accidentally mix those).

2013/3/16, bazz :

What’s the benefits of using SDL_bool instead of regular bool on a C++
project using SDL?? I switched to SDL_bool because I figured it was some
kind of portability thing.

I have the same question for SDL_free/SDL_malloc vs. malloc/free


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.On Sat, Mar 16, 2013 at 4:52 PM, Steven Noonan 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 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.

Just typedef enum bool {false = 0, true = 1} bool; and you have it in any C
standard.

2013/3/16 Steven Noonan > The ‘bool’ type was added in C99 (see section 7.16 in the C99 standard).

On Sat, Mar 16, 2013 at 1:31 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

Remember that SDL is a C library and C doesn’t have bool (at least not
everywhere, I don’t remember exactly what was the situation with the
standard regarding boolean types in C).

SDL_free and SDL_malloc I think are indeed a portability issue though,
especially on systems like Windows where the standard library used by
the program can mismatch that of the other libraries it uses (you
really don’t want to accidentally mix those).

2013/3/16, bazz :

What’s the benefits of using SDL_bool instead of regular bool on a C++
project using SDL?? I switched to SDL_bool because I figured it was some
kind of portability thing.

I have the same question for SDL_free/SDL_malloc vs. malloc/free


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


Csala Tam?s

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 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

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?
VittorioSent from my iPad Mini

On 17/mar/2013, at 00:45, John 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 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

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 <@John6> 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 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

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. :slight_smile:

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 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 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


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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.

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. :wink:

–AndreasOn 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. :slight_smile:

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 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 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

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).On 03/17/2013 04:37 PM, Andreas Schiffler wrote:

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. :wink:

–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. :slight_smile:

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 <@John6> 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 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

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

Jonny DOn Sun, Mar 17, 2013 at 4:59 PM, John 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. :wink:

–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.
:slight_smile:

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 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 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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 <@John6 mailto:John6> 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 <@John6 <mailto:@John6>> 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>

                    _________________________________________________
                    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>

                _________________________________________________
                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>

            _________________________________________________
            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>



    _________________________________________________
    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>

_________________________________________________
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>

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

Jonny DOn Mon, Mar 18, 2013 at 10:55 AM, John wrote:

You can safely use bool in C++ :slight_smile:

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 >> 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. :wink:

    --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.orghttp://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org<
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://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.orghttp://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org
<http://lists.libsdl.org/**
listinfo.cgi/sdl-libsdl.orghttp://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.orghttp://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org
<http://lists.libsdl.org/**
listinfo.cgi/sdl-libsdl.orghttp://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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Practically speaking, yes. You can freely mix C, C99, and C++ types. Many of us
have been doing it for years across all the major platforms. It works. Don’t
hesitate to use all the standard C types. There is no portability issue with them.On 03/18/2013 10:59 AM, Jonathan Dearborn wrote:

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

Jonny D

On Mon, Mar 18, 2013 at 10:55 AM, John <@John6 mailto:John6> 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 <@John6 <mailto:@John6> <mailto:john at leafygreengames.__com <mailto:@John6>>> 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 <@John6 <mailto:@John6> <mailto:john at leafygreengames.__com <mailto:@John6>>> 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>
                                 <mailto: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> <mailto: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>
    <mailto: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>
    <mailto: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>
    <mailto: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>
    <mailto: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>
    <mailto: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>
    <mailto: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>

_________________________________________________
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>

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

Jonny D

Is it really some compilers nowadays, or just Microsoft’s
brain-dead, pathetic Visual Studio C compiler? (Yes, I know we won’t
break compatibility with Visual Studio, but their sorry excuses are
really holding everybody back.)

Is there any advantage in using bool at all?

In addition to some of the things already mentioned:

  • C99 _Bool/bool guarantees that non-zero values are constrained to 1.
    When you don’t have this guarantee, you can get into trouble when
    libraries don’t sanitize the values they return (what happens if the
    call returns 2 or 255 and you are explicitly comparing with == true).
    You can also get into subtle bugs when you use masks and aren’t paying
    attention to this. (This was a long thread on the Apple Objective-C
    mailing list not long ago.)

  • Language bindings can benefit from an explicit bool. Languages like
    Lua and Ruby treat everything except nil and false as true. This means
    the number 0 is treated as true. For generating language bindings that
    look at header files, explicit bools in the APIs express the actual
    intent of the API and they can map to the real boolean types of the
    target languages. Without other means of knowing the intent, the
    binding must assume a number type which is distinctly different than a
    boolean type for many languages. (Obj-C also adds encoding signatures
    which can be detected at runtime, but the encoding signature is
    different for _Bool and other types so it is the same problem as the
    headers with respect to expressing intent.)On 3/17/13, Jonathan Dearborn wrote:

On 03/17/2013 07:28 AM, Vittorio Giovara wrote:

On 3/18/13, John wrote:

Practically speaking, yes. You can freely mix C, C99, and C++ types. Many of
us
have been doing it for years across all the major platforms. It works. Don’t

hesitate to use all the standard C types. There is no portability issue with
them.

Actually, I don’t think that is completely true. I don’t think most
C++ compilers handle/accept C99 _Complex. And not exactly a type, but
C++ officially doesn’t handle restrict either and the cross-platform
compiler support is still shaky on that.

If you are using C99/C11, you can use _Bool or bool (stdbool.h). If
you are using C++, you can use bool. But in that case, remember you
are using C++, and not C. C++ is NOT a true superset of C and does
have subtle compatibility and portability implications. Most people
are not aware of these and don’t necessarily hit them, but sadly I
seem to be bitten by these on a regular basis because I have to
fix/deal with other people’s code who are not aware of these.

-Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/