RE: [Boost-Users] int64_t problem

From: Jim.Hyslop (jim.hyslop_at_[hidden])
Date: 2003-05-30 11:12:53

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