[Liblas-devel] .net/mono bindings in c#

[Mateusz Loskot]

Martin Rodriguez wrote:
> Hi:
> 
> 
>> Is it enough solution to add tests for MINGW and CYGWIN to these #ifdef's ?
> 
> I think the most important is the MACRO in the CAPI. This is easy to solve.
> 
> In respect to type in glib they solve all types like this:
> 
> typedef signed char gint8;
> typedef unsigned char guint8;
> typedef signed short gint16;
> typedef unsigned short guint16;
> typedef signed int gint32;
> typedef unsigned int guint32;
> 
> #ifndef _MSC_VER
> G_GNUC_EXTENSION typedef signed long long gint64;
> G_GNUC_EXTENSION typedef unsigned long long guint64;
> #else /* _MSC_VER */
> typedef signed __int64 gint64;
> typedef unsigned __int64 guint64;
> #endif /* _MSC_VER */

Martin,

I feel I'm lost. In the example above there is only _MSC_VER macro used.
We also do use _MSC_VER macro as you listed files in previous post.

I don't really catch the problem.


> There are other interesting macros to work with doubles and floats:
> #if G_BYTE_ORDER == G_LITTLE_ENDIAN
> union _GFloatIEEE754
> {
>   gfloat v_float;
>   struct {
>     guint mantissa : 23;
>     guint biased_exponent : 8;
>     guint sign : 1;
>   } mpn;
> };
> union _GDoubleIEEE754
> {
>   gdouble v_double;
>   struct {
>     guint mantissa_low : 32;
>     guint mantissa_high : 20;
>     guint biased_exponent : 11;
>     guint sign : 1;
>   } mpn;
> };
> #elif G_BYTE_ORDER == G_BIG_ENDIAN
> union _GFloatIEEE754
> {
>   gfloat v_float;
>   struct {
>     guint sign : 1;
>     guint biased_exponent : 8;
>     guint mantissa : 23;
>   } mpn;
> };
> union _GDoubleIEEE754
> {
>   gdouble v_double;
>   struct {
>     guint sign : 1;
>     guint biased_exponent : 11;
>     guint mantissa_high : 20;
>     guint mantissa_low : 32;
>   } mpn;
> };
> #else /* !G_LITTLE_ENDIAN && !G_BIG_ENDIAN */
> #error unknown ENDIAN type
> #endif /* !G_LITTLE_ENDIAN && !G_BIG_ENDIAN */


OK, just another way to go with endianness.
Are you suggesting there is something wrong with big-/little-endian 
support in libLAS?

>> Yes, I agree this is a good practice but the idea behind integer types 
>> in libLAS was to make them compatible with integer types defined in ANSI 
>> C99. That's why we use Boost-like defs.
>> IOW, those who use compilers that support ANSI C99 (like GCC) do not 
>> need libLAS definitions from cstdint.hpp, and it's #ifdef'ed out actually.
>> But if someone uses compiler without C99 support, like Microsoft Visual 
>> C++, then types defined in liblas/cstdint.hpp are used.
> 
> Ok. I see :
> http://www.boost.org/doc/libs/1_35_0/libs/integer/cstdint.htm
> 
> It seems like K-3D people have a boost version for MINGW. I see the cstdint
> file there and it's the same like the standard boost file and therefore I am
> sure works well in MINGW.
> http://www.k-3d.org/wiki/Windows_Build/MinGW


Yes, see the "A note to Cygwin and MinGW users" on top of this:

http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html

> I compiled liblas in mingw with g++ and works fine, but for me it was
> difficult understand cstdint file and I was not sure what types I finally
> had in mingw. I only had real problems with the CAPI and the MACRO, but if
> add mingw all fine.

The process of selection is simple, if this is true: #ifndef _WIN32
then POSIX platform is assumed and integer types definition is used from 
stdint.h:

http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html

If _WIN32 is defined, then Windows platform is assumed as non-POSIX, 
because there is no complete stdint.h version, then libLAS's cstding.hpp 
file defines all required integer types.

No more tricks or new definitions are required.

If you still are unsure what option is used in your environment, try to 
put #error (for VC++) or #warning (for GNU/MinGW) message. Example for 
GNU C (#ifdef __GNUC__)

#fndef _WIN32

#warning USING POSIX TYPES

...

#else

#warning USING LIBLAS TYPES

...

#endif


and see what message you will get in compiler output.

Best regards
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org