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
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?
VittorioSent 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:
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?
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
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 - LadyHavoc's DarkPlaces Quake Modification
Co-designer of Nexuiz - Nexuiz Classic – Alientrap
“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.
–AndreasOn 3/17/2013 10:18 AM, Forest Hale wrote:
Two technical notes on C++ bool:
- 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).
- 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?
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
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 warnThe 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:
- 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).- 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?
VittorioSent 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 warnThe 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:
- 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).- 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?
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.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++
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 warnThe 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?
VittorioSent 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’thesitate 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.
Beginning iPhone Games Development