[Spatialindex] Namespace use request

[Marios Hadjieleftheriou]

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:
> 
>> Hi,
>>
>> I was trying to report a bug to the SpatialIndex Trac but it's read  
>> only
>> for me, even after I've registered and logged in.
> 
> That reminds me that I need to complete our migration to OSGeo's  
> infrastructure.
> 
> http://trac.osgeo.org/osgeo/ticket/379
> 
>> 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  
>> namespace:
>>
>>  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  
>> required.
>>
>> 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  
> around.
> 
> 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
> 
> Howard
> _______________________________________________
> Spatialindex mailing list
> Spatialindex at lists.gispython.org
> http://lists.gispython.org/mailman/listinfo/spatialindex