[Spatialindex] Namespace use request
mhadji at gmail.com
Tue Oct 20 17:08:31 EEST 2009
There is no standard header in windows that defines these types?
If we simply move the typedefs inside the SpatialIndex namespace, would
that fix the problem?
Howard Butler wrote:
> On Oct 19, 2009, at 6:46 PM, Mateusz Loskot wrote:
>> I was trying to report a bug to the SpatialIndex Trac but it's read
>> for me, even after I've registered and logged in.
> That reminds me that I need to complete our migration to OSGeo's
>> The spatialindex is a troublemaker. It pollutes global namespace with
>> its own definitions of types and it uses very common names for this
>> types. These definitions seriously breaks compilation of client's code
>> that use different definitions of such aliases. Meaning, the
>> SpatialIndex defines the following aliases in Tools.h in global
>> typedef __int8 int8_t;
>> typedef __int16 int16_t;
>> typedef __int32 int32_t;
>> typedef __int64 int64_t;
>> typedef unsigned __int8 uint8_t;
>> typedef unsigned __int16 uint16_t;
>> typedef unsigned __int32 uint32_t;
>> typedef unsigned __int64 uint64_t;
>> It clashes with for example boost::uint* and boost::int* types,
>> with liblas::uint* and liblas::int* types as well as with other
>> definitions like stdint.h.
>> For example, even if a client use his own types in properly
>> namespaced code:
>> namespace boost
>> uint32_t a;
>> SpatialIndex' types cause conflict or a full qualificatoin is
>> Elements of SpatialIndex should be defined in namespace or rename all
>> its integral types using unique names.
> I agree. I think what is desired is to ensure the full complement of
> modern stdint *_t types, but there are no #ifdef guards in place for
> the cases where we're filling them in. Marios would have to back my
> statement up, but I don't think we're trying to make our own types,
> just ensure the names are the same as expected. I think it would be a
> PITA to namespace our own definitions of the same names as the
> stdint.h types for practically no gain.
> I will work with you on #liblas tomorrow on a solution if you are
> BTW, I think we're just about ready for a libspatialindex 1.5.0 release.
> - C API added
> - MSVC 2003 support fixed
> - change from size_t to uint32_t to ensure platform compatibility of
> index storage
> - bulkloader bug with bleaf and bindex transposed in createLevel call
> Mateusz's bug here is the only thing left we need to fix for the release
> Spatialindex mailing list
> Spatialindex at lists.gispython.org
More information about the Spatialindex