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