www.digitalmars.com         C & C++   DMDScript  

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

reply "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)



        typedef int bool;

        typedef Boolean bool;








          typedef int bool;





    #else

    #endif /* _STLP_NO_BOOL */

as a result of the following in stl_dm.h:







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
next sibling parent reply "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)



        typedef int bool;

        typedef Boolean bool;








          typedef int bool;





    #else

    #endif /* _STLP_NO_BOOL */

 as a result of the following in stl_dm.h:







 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
parent 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)



        typedef int bool;

        typedef Boolean bool;








          typedef int bool;





    #else

    #endif /* _STLP_NO_BOOL */

 as a result of the following in stl_dm.h:







 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
prev sibling parent reply 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
parent "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