> We are working on 150Cay here.
>
> If all source modules use HXBOOL instead of BOOL, the
attached
> patch to define HXBOOL directly to C++'s bool datatype
would work
> well.
>
> However, there are all kind of modules still using BOOL
in 150Cay
> branch. I tried making changes to 30+ files, but there
are likely
> many more to change. It is possible that automated
search-and-
> replace is needed to speed up the changes.
>
> One question comes to mind; is this kind of large scale
BOOL to
> HXBOOL replacement acceptable for 150Cay?
In Atlas and later (including head), BOOL is deprecated. But
in
150Cay, BOOL and HXBOOL should be equivalent. hxtypes.h
needs to have
a line like: "typedef BOOL HXBOOL;" (or vice
versa) for your compiler.
We need to keep BOOL the same as HXBOOL in the 150Cay
branch.
I really don't think we should do any wholesale BOOL ==>
HXBOOL
replacements in 150Cay. (And it shouldn't be necessary,
since BOOL
should be the same as HXBOOL in 150Cay.)
Massimo, it doesn't sound like HXBOOL vs. BOOL is what's
really
causing your problem. But HXBOOL vs. BOOL has kept me awake
for
years. In case you're curious, here's the background page on
HXBOOL
vs. BOOL:
http://lists.helixcommunity.org/pipermail/common
-dev/2005-March/
002238.html
--Bob
On Oct 3, 2007, at 1:18 AM, Daniel Yek wrote:
>
> Greg Wright wrote:
>> Massimo Perga wrote:
>>> In fact, reworking the hxtypes.h in the
following way:
>>>
>>> #ifndef BOOL
>>> #if (defined _UNIX && defined
__x86_64__)
>>> typedef bool BOOL;
>>> #else
>>> typedef int BOOL; /*
signed int value (0 or
>>> 1) */
>>> #endif
>>> #define BOOL_DEFINED
>>> #endif
>>>
>>> I get this build error:
>>>
>>> ../include/hxtypes.h:164: error: expected '=',
',', ';', 'asm' or
>>> '__attribute__' before 'BOOL'
>>> ../include/hxtypes.h:174: error: expected '=',
',', ';', 'asm' or
>>> '__attribute__' before 'HXBOOL'
>>
>> Perhaps it is because you are changing BOOL. BOOL
is no
>> longer supported on HEAD or 310Atlas, only HXBOOL
is.
>> Try changing just HXBOOL instead of BOOL and see
what
>> happens.
>
> We are working on 150Cay here.
>
> If all source modules use HXBOOL instead of BOOL, the
attached
> patch to define HXBOOL directly to C++'s bool datatype
would work
> well.
>
> However, there are all kind of modules still using BOOL
in 150Cay
> branch. I tried making changes to 30+ files, but there
are likely
> many more to change. It is possible that automated
search-and-
> replace is needed to speed up the changes.
>
> One question comes to mind; is this kind of large scale
BOOL to
> HXBOOL replacement acceptable for 150Cay?
>
> --
> Daniel Yek.
>
>
>
>
> Index: hxtypes.h
>
============================================================
=======
> RCS file: /cvsroot/common/include/hxtypes.h,v
> retrieving revision 1.24.4.6
> diff -u -w -r1.24.4.6 hxtypes.h
> --- hxtypes.h 31 Dec 2006 17:48:22 -0000 1.24.4.6
> +++ hxtypes.h 3 Oct 2007 08:05:38 -0000
>  -166,7 +166,13
>
> #endif /* _SYMBIAN */
>
> -typedef BOOL HXBOOL;
> +# ifndef HXBOOL
> +# ifdef __cplusplus
> + typedef bool HXBOOL;
> +# else
> + typedef BOOL HXBOOL; /* signed int
value (0 or
> 1) */
> +# endif /* __cplusplus */
> +# endif /* HXBOOL */
>
> #define ARE_BOOLS_EQUAL(a,b) (((a) && (b)) ||
(!(a) && !(b)))
>
> -372,11 +378,19
> #endif
>
> #ifndef TRUE
> +# ifdef __cplusplus
> +# define TRUE true
> +# else // __cplusplus
> #define TRUE 1
> +# endif // __cplusplus
> #endif
>
> #ifndef FALSE
> +# ifdef __cplusplus
> +# define FALSE false
> +# else // __cplusplus
> #define FALSE 0
> +# endif // __cplusplus
> #endif
>
> #ifndef NULL
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
--
Bob Clark
Lead Software Development Engineer
RealPlayer Mac/Unix
RealNetworks, Inc.
_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
|
