Sigis wrote:
I am using OpenInventor and boost 1.29 librariess. Both of them have defined int64_t:
typedef __int64 int64_t;
The only solution I found is to add #undef just before define at boost/cstdint.hpp: #undef int64_t typedef __int64 int64_t;
But it looks as dirty solution. Maybe it is possilbe to solve this problme in more elegant way? First step is to send a complaint (or enhancement request, if you prefer :=) to OpenInventor - any new types they introduce should be wrapped in their own namespace. Also, if #undef really *does* work, then that means either your compiler is buggy (#undef should only work on macros, not typedefs), or OpenInventor are using a #define, not a typedef - double penalty points for
[...] that! (well, I suppose if it's a C library, that _might_ be acceptable. Barely.) If it is a #define, you could try wrapping the OpenInventor headers in another header: // Wrapper file for using OpenInventor with Boost [include guard #ifdefs] #include "OpenInventorHeader.h" #undef int64_t #endif // #include guard In any source file that uses both Boost and OpenInventor, include the wrapper header instead of the OpenInventor header. You'll want to check for any include order problems, i.e. you may have to ensure all Boost headers are included after all OpenInventor headers. Subtle issue, though - could this violate the ODR (One Definition Rule)? I think we'd have to see exactly how OpenInventor defines/typedefs int64_t to be sure. Other possible solutions: - Decouple Boost and OpenInventor, by wrapping the OpenInventor objects you are using in proxy objects. The proxies will use an opaque handle to the OpenInventor objects. Use these proxy objects wherever you currently use OpenInventor. This, by the way, has the advantage of decoupling your application from OpenInventor, allowing you the option to move to a different library if you ever decide that should be necessary. - If OpenInventor's int64_t is a typedef, put it inside an OpenInventor namespace (this probably won't work if you do not have the source code to OI in order to rebuild the binaries). If it's not a typedef, then make it a typedef in an OpenInventor namespace (same caveats). - If OpenInventor really does use a typedef, and if the typedef is inside an OI namespace, then hunt down and destroy any using directives (i.e. "using namespace OI;" or "using OI::whatever;") in any headers, and move any using directives inside your source files *after* all #include directives. If you find a "using namespace" directive in any of the OpenInclude directives, then that's triple penalty points against them, and definite cause for a complaint (not an enhancement request :=). - [radical solution, probably unrealistic] change library vendors, and be sure to tell OI why you are dropping them (because they don't play well with everyone else). - <sigh> change library vendors, and be sure to tell Boost why you are dropping them :=( Boost plays nicely - int64_t is a typedef, and it is declared inside namespace boost. -- Jim
Hi, thanks for replay, though I could not use any of your suggestions directly, but your letter bring some ideas.. Jim.Hyslop wrote:
Sigis wrote:
I am using OpenInventor and boost 1.29 librariess. Both of them have defined int64_t:
typedef __int64 int64_t;
[...]
The only solution I found is to add #undef just before define at boost/cstdint.hpp: #undef int64_t typedef __int64 int64_t;
But it looks as dirty solution. Maybe it is possilbe to solve this problme in more elegant way?
First step is to send a complaint (or enhancement request, if you prefer :=) to OpenInventor - any new types they introduce should be wrapped in their own namespace. Also, if #undef really *does* work, then that means either your compiler is buggy (#undef should only work on macros, not typedefs), or OpenInventor are using a #define, not a typedef - double penalty points for that! (well, I suppose if it's a C library, that _might_ be acceptable. Barely.)
Reading this, I was a little bit confused about all that #define/#undef stuff. My compiler is MSVC (I forgot to mention). As all know it is not bug free but there was strange to me if it can be so buggy. So I decided to find a #define of the int64_t. And I was lucky - I found third (!) librarary (log4cpp) where the int64_t was defined. But there it was really defined using #define directive, and it was in some config related file. So IMO removing that line will not make much damage to log4cpp library, and it seems it is working. <...>
- [radical solution, probably unrealistic] change library vendors, and be sure to tell OI why you are dropping them (because they don't play well with everyone else).
- <sigh> change library vendors, and be sure to tell Boost why you are dropping them :=( Boost plays nicely - int64_t is a typedef, and it is declared inside namespace boost.
There is no need to doo this ;) boost is great library and has a lot of nice features. Also there are written to much code using OI, so there would be a lot of work to change it. OI typedef is in global namespace however boost's int64_t is in it's one. So typedef's from these libraries do not conflict and I still can use both of them ;) -- thanx, Sigis
participants (2)
-
Jim.Hyslop
-
Sigis