You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Maciek Samsel (JIRA)" <xe...@xml.apache.org> on 2005/03/17 00:00:21 UTC
[jira] Created: (XERCESC-1382) Unreliable bool definition for compilers without bool type
Unreliable bool definition for compilers without bool type
----------------------------------------------------------
Key: XERCESC-1382
URL: http://issues.apache.org/jira/browse/XERCESC-1382
Project: Xerces-C++
Type: Bug
Versions: 2.6.0
Environment: Solaris 2.8 SPARCompiler 4.2
Reporter: Maciek Samsel
For those compilers that do not recognize bool type yet the definition as it is now (see below) will not cut:
#if defined(NO_NATIVE_BOOL)
#ifndef bool
typedef int bool;
#endif
#ifndef true
#define true 1
#endif
#ifndef false
#define false 0
#endif
#endif
That will cause compiler errors whenever you have declaration/definition of a method with int and and another with bool. Compiler tries to build the same signature and gets confused. It happend with:
XSerializeEngine.hpp:
XSerializeEngine& operator<<(int);
XSerializeEngine& operator<<(bool);
// NO GO! Compiler error if bool is typedef as alias to int
The better approach that will not confuse compiler without bool type is to base bool on enumeration like that:
#if defined(NO_NATIVE_BOOL)
#ifndef bool
typedef enum {false=0, true=1} bool;
#endif
#endif
... as long as we do not set enum as not convertible to integer (which was possible at least with IBM VisualAge for C++ compiler).
Please adjust the file... as it compiles with proposed definition quite well. There are also other approaches to deal with bool type or "smart enumeration types". See how it was done in Java without enum but strict type checking - it would be preferable way to apply to undefined bool type as other vendor may define bool differently for libraries and it will cause conflicts with current or proposed here solution in Xerces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
[jira] Commented: (XERCESC-1382) Unreliable bool definition for compilers without bool type
Posted by "Gareth Reakes (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1382?page=comments#action_61095 ]
Gareth Reakes commented on XERCESC-1382:
----------------------------------------
Hi, I don't feel comfortable committing this path as I don't have the multi platform knowledge requided to be sure it will work on the huge number of platforms we support. Could you post to the list with your opinion and we can kick off a discussion and get everyone elses view?
Cheers,
Gareth
> Unreliable bool definition for compilers without bool type
> ----------------------------------------------------------
>
> Key: XERCESC-1382
> URL: http://issues.apache.org/jira/browse/XERCESC-1382
> Project: Xerces-C++
> Type: Bug
> Versions: 2.6.0
> Environment: Solaris 2.8 SPARCompiler 4.2
> Reporter: Maciek Samsel
>
> For those compilers that do not recognize bool type yet the definition as it is now (see below) will not cut:
> #if defined(NO_NATIVE_BOOL)
> #ifndef bool
> typedef int bool;
> #endif
> #ifndef true
> #define true 1
> #endif
> #ifndef false
> #define false 0
> #endif
> #endif
> That will cause compiler errors whenever you have declaration/definition of a method with int and and another with bool. Compiler tries to build the same signature and gets confused. It happend with:
> XSerializeEngine.hpp:
> XSerializeEngine& operator<<(int);
> XSerializeEngine& operator<<(bool);
> // NO GO! Compiler error if bool is typedef as alias to int
> The better approach that will not confuse compiler without bool type is to base bool on enumeration like that:
> #if defined(NO_NATIVE_BOOL)
> #ifndef bool
> typedef enum {false=0, true=1} bool;
> #endif
> #endif
> ... as long as we do not set enum as not convertible to integer (which was possible at least with IBM VisualAge for C++ compiler).
> Please adjust the file... as it compiles with proposed definition quite well. There are also other approaches to deal with bool type or "smart enumeration types". See how it was done in Java without enum but strict type checking - it would be preferable way to apply to undefined bool type as other vendor may define bool differently for libraries and it will cause conflicts with current or proposed here solution in Xerces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
[jira] Commented: (XERCESC-1382) Unreliable bool definition for compilers without bool type
Posted by "Maciek Samsel (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1382?page=comments#action_61253 ]
Maciek Samsel commented on XERCESC-1382:
----------------------------------------
Hi,
Sure no problem. I just can't commit to be a big part of that discussion. I have found ways around non-existent (for older compilers) bool type on commercial projects. I also encounterd problems with some of them.
The thing is that it is not about platform, but about compiler behavior. Xerces has to be recompiled for any platform and compiler (and options) anyway as otherwise programs using it in conjuction with other products (e.g. RogueWave defines its own bool type) may have problems with compile options.
I will start some discussion, but I am affraid it will go nowhere due to number of visions (one particular is that "upgrade your compiler.. the best to GNU"). Unfotuntally thank to this attitude C++ is slowly being replaced by Java or C# these days (and faster hardware) and nobody in sane world of commerce except hardcore environments is willing to upgrade to any new C++ compiler.
I will try do my best... when time allows.
Thanks,
Maciek
> Unreliable bool definition for compilers without bool type
> ----------------------------------------------------------
>
> Key: XERCESC-1382
> URL: http://issues.apache.org/jira/browse/XERCESC-1382
> Project: Xerces-C++
> Type: Bug
> Versions: 2.6.0
> Environment: Solaris 2.8 SPARCompiler 4.2
> Reporter: Maciek Samsel
>
> For those compilers that do not recognize bool type yet the definition as it is now (see below) will not cut:
> #if defined(NO_NATIVE_BOOL)
> #ifndef bool
> typedef int bool;
> #endif
> #ifndef true
> #define true 1
> #endif
> #ifndef false
> #define false 0
> #endif
> #endif
> That will cause compiler errors whenever you have declaration/definition of a method with int and and another with bool. Compiler tries to build the same signature and gets confused. It happend with:
> XSerializeEngine.hpp:
> XSerializeEngine& operator<<(int);
> XSerializeEngine& operator<<(bool);
> // NO GO! Compiler error if bool is typedef as alias to int
> The better approach that will not confuse compiler without bool type is to base bool on enumeration like that:
> #if defined(NO_NATIVE_BOOL)
> #ifndef bool
> typedef enum {false=0, true=1} bool;
> #endif
> #endif
> ... as long as we do not set enum as not convertible to integer (which was possible at least with IBM VisualAge for C++ compiler).
> Please adjust the file... as it compiles with proposed definition quite well. There are also other approaches to deal with bool type or "smart enumeration types". See how it was done in Java without enum but strict type checking - it would be preferable way to apply to undefined bool type as other vendor may define bool differently for libraries and it will cause conflicts with current or proposed here solution in Xerces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org