[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
