Digital Mars - c++ - Multi-faceted typedef conflict problem

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

I'm compiling some C & C++ source files with DMC++.

The C compilation is breaking on a typedef in some internal Synesis header
file, which basically typedefs bool from 
unsigned int, in the case where native bool support is not detected:

    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as
something else
    It was declared as: int
    It is now declared: unsigned

The same problem can be seen with the simple file

    #include <stddef.h>
    typedef unsigned bool;
    int main()
    {
        return 0;
    }

The reason this is happening is that STLport typedefs int to bool in
stl/_config.h:

    #if defined(_STLP_NO_BOOL)
    # if (defined (__IBMCPP__) && (__IBMCPP__ < 400)) && ! defined (_AIX)
    #  include <isynonym.hpp>
    #  if defined (__OS400__)
        typedef int bool;
    #  elif !( defined (__xlC__) || defined (_AIX))
        typedef Boolean bool;
    #  endif
    # else
    #  if defined(_STLP_YVALS_H)
    #   include <yvals.h>
    #  else
    #    if defined (_STLP_DONT_USE_BOOL_TYPEDEF)
    #     define bool int
    #    else
          typedef int bool;
    #    endif
    #    define true 1
    #    define false 0
    #  endif
    # endif /* __IBMCPP__ */
    #else
    #    define _STLP_BOOL_KEYWORD 1
    #endif /* _STLP_NO_BOOL */

as a result of the following in stl_dm.h:

    #  ifndef _BOOL_DEFINED
    #   define _STLP_NO_BOOL
    #  else
    #   define _STLP_DONT_USE_BOOL_TYPEDEF
    #  endif

The reason this is being picked up is that STLport has a stddef.h.

The reason that is being picked up is that STLport has to be before the main
DMC++ include directory otherwise the 
(non-functioning) SGI std lib is picked up.

Anyone got any ideas for a solution that does not involve a hack in my source
(which otherwise works perfectly with all 
other Win32 and Linux compilers)?

The only thing I can think of is that it'd be nice to have different sections
in SC.INI for C and C++ compilation, e.g.


    [Environment]
    PATH=%PATH%;"% P%\..\bin"
    BIN="% P%\..\bin"
    LIB=%LIB%;"% P%\..\lib";"% P%\..\mfc\lib"
    HELP="% P%\..\help"

    [Environment:C]
    INCLUDE="% P%\..\include";"% P%\..\mfc\include";%INCLUDE%;


    [Environment:C++]
    INCLUDE=%INCLUDE%;"% P%\..\include";% P%\..\mfc\include;


Cheers

Matthew

Apr 01 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

I'm also running into the same problem with RC. I have no idea how to hack this
into shape. :-(


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d2le95$2gdu$1 digitaldaemon.com...
 I'm compiling some C & C++ source files with DMC++.

 The C compilation is breaking on a typedef in some internal Synesis header
file, which basically typedefs bool from 
 unsigned int, in the case where native bool support is not detected:

    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as
something else
    It was declared as: int
    It is now declared: unsigned

 The same problem can be seen with the simple file

    #include <stddef.h>
    typedef unsigned bool;
    int main()
    {
        return 0;
    }

 The reason this is happening is that STLport typedefs int to bool in
stl/_config.h:

    #if defined(_STLP_NO_BOOL)
    # if (defined (__IBMCPP__) && (__IBMCPP__ < 400)) && ! defined (_AIX)
    #  include <isynonym.hpp>
    #  if defined (__OS400__)
        typedef int bool;
    #  elif !( defined (__xlC__) || defined (_AIX))
        typedef Boolean bool;
    #  endif
    # else
    #  if defined(_STLP_YVALS_H)
    #   include <yvals.h>
    #  else
    #    if defined (_STLP_DONT_USE_BOOL_TYPEDEF)
    #     define bool int
    #    else
          typedef int bool;
    #    endif
    #    define true 1
    #    define false 0
    #  endif
    # endif /* __IBMCPP__ */
    #else
    #    define _STLP_BOOL_KEYWORD 1
    #endif /* _STLP_NO_BOOL */

 as a result of the following in stl_dm.h:

    #  ifndef _BOOL_DEFINED
    #   define _STLP_NO_BOOL
    #  else
    #   define _STLP_DONT_USE_BOOL_TYPEDEF
    #  endif

 The reason this is being picked up is that STLport has a stddef.h.

 The reason that is being picked up is that STLport has to be before the main
DMC++ include directory otherwise the 
 (non-functioning) SGI std lib is picked up.

 Anyone got any ideas for a solution that does not involve a hack in my source
(which otherwise works perfectly with 
 all other Win32 and Linux compilers)?

 The only thing I can think of is that it'd be nice to have different sections
in SC.INI for C and C++ compilation, 
 e.g.


    [Environment]
    PATH=%PATH%;"% P%\..\bin"
    BIN="% P%\..\bin"
    LIB=%LIB%;"% P%\..\lib";"% P%\..\mfc\lib"
    HELP="% P%\..\help"

    [Environment:C]
    INCLUDE="% P%\..\include";"% P%\..\mfc\include";%INCLUDE%;


    [Environment:C++]
    INCLUDE=%INCLUDE%;"% P%\..\include";% P%\..\mfc\include;


 Cheers

 Matthew

Apr 02 2005

↑ ↓ ← → Jack <Jack_member pathlink.com> writes:

I'm using my own boolean type with all capital letters in some projects, 'BOOL'
instead 'bool' like this,

#ifdef __cplusplus
typedef bool BOOL
#define TRUE true
#define FALSE false

#else // not C++, don't have boolean type

typedef int BOOL
#define TRUE 1
#define FALSE 0
#endif

In article <d2lq2h$2upi$1 digitaldaemon.com>, Matthew says...
I'm also running into the same problem with RC. I have no idea how to hack this
into shape. :-(


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d2le95$2gdu$1 digitaldaemon.com...
 I'm compiling some C & C++ source files with DMC++.

 The C compilation is breaking on a typedef in some internal Synesis header
file, which basically typedefs bool from 
 unsigned int, in the case where native bool support is not detected:

    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as
something else
    It was declared as: int
    It is now declared: unsigned

 The same problem can be seen with the simple file

    #include <stddef.h>
    typedef unsigned bool;
    int main()
    {
        return 0;
    }

 The reason this is happening is that STLport typedefs int to bool in
stl/_config.h:

    #if defined(_STLP_NO_BOOL)
    # if (defined (__IBMCPP__) && (__IBMCPP__ < 400)) && ! defined (_AIX)
    #  include <isynonym.hpp>
    #  if defined (__OS400__)
        typedef int bool;
    #  elif !( defined (__xlC__) || defined (_AIX))
        typedef Boolean bool;
    #  endif
    # else
    #  if defined(_STLP_YVALS_H)
    #   include <yvals.h>
    #  else
    #    if defined (_STLP_DONT_USE_BOOL_TYPEDEF)
    #     define bool int
    #    else
          typedef int bool;
    #    endif
    #    define true 1
    #    define false 0
    #  endif
    # endif /* __IBMCPP__ */
    #else
    #    define _STLP_BOOL_KEYWORD 1
    #endif /* _STLP_NO_BOOL */

 as a result of the following in stl_dm.h:

    #  ifndef _BOOL_DEFINED
    #   define _STLP_NO_BOOL
    #  else
    #   define _STLP_DONT_USE_BOOL_TYPEDEF
    #  endif

 The reason this is being picked up is that STLport has a stddef.h.

 The reason that is being picked up is that STLport has to be before the main
DMC++ include directory otherwise the 
 (non-functioning) SGI std lib is picked up.

 Anyone got any ideas for a solution that does not involve a hack in my source
(which otherwise works perfectly with 
 all other Win32 and Linux compilers)?

 The only thing I can think of is that it'd be nice to have different sections
in SC.INI for C and C++ compilation, 
 e.g.


    [Environment]
    PATH=%PATH%;"% P%\..\bin"
    BIN="% P%\..\bin"
    LIB=%LIB%;"% P%\..\lib";"% P%\..\mfc\lib"
    HELP="% P%\..\help"

    [Environment:C]
    INCLUDE="% P%\..\include";"% P%\..\mfc\include";%INCLUDE%;


    [Environment:C++]
    INCLUDE=%INCLUDE%;"% P%\..\include";% P%\..\mfc\include;


 Cheers

 Matthew

Apr 02 2005

↑ ↓ ← → Jack <Jack_member pathlink.com> writes:

I think you just need to define _BOOL_DEFINED when __cplusplus is defined in
DMC++ config files of STLport.

Btw, I think the problem is in your SLBase.h, it tries to redefine 'bool', the
same problem will occur too when you compiling it in C++ mode.

In article <d2le95$2gdu$1 digitaldaemon.com>, Matthew says...
I'm compiling some C & C++ source files with DMC++.

The C compilation is breaking on a typedef in some internal Synesis header
file, which basically typedefs bool from 
unsigned int, in the case where native bool support is not detected:

    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as
something else
    It was declared as: int
    It is now declared: unsigned


Jack

Apr 02 2005

↑ ↓ ← → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

As you may note below, I'm talking only about C compilation. ;)

The problem may be seen as the fact that the STLport directory has to come
before the 'std' DMC++ include, in order to 
prevent selection of the SGI STL, coupled with the fact that DMC++ uses a
single INCLUDE variable in SC.INI for both C 
and C++. STLport has its own stddef.h etc, and so we pick up the definition of
bool.

"Jack" <Jack_member pathlink.com> wrote in message
news:d2miqf$jn4$1 digitaldaemon.com...
I think you just need to define _BOOL_DEFINED when __cplusplus is defined in
 DMC++ config files of STLport.

 Btw, I think the problem is in your SLBase.h, it tries to redefine 'bool', the
 same problem will occur too when you compiling it in C++ mode.



 In article <d2le95$2gdu$1 digitaldaemon.com>, Matthew says...
I'm compiling some C & C++ source files with DMC++.

The C compilation is breaking on a typedef in some internal Synesis header
file, which basically typedefs bool from
unsigned int, in the case where native bool support is not detected:

    h:\dev\include\SLBase.h(3131) : Error: 'bool' previously declared as
something else
    It was declared as: int
    It is now declared: unsigned


 Jack

Apr 02 2005

c++ - Multi-faceted typedef conflict problem - any ideas?!?