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

Mateusz Loskot mateusz at loskot.net
Fri Aug 8 10:23:12 EDT 2008


Martin Rodriguez wrote:
>> 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.
> 
> Yes, I am sorry hehe. The only excepcion in types it´s seems it´s  VC and
> therefore GCC==MINGW=CYGWIN. Liblas do the same. I had problems to
> understand the cstdint.hpp source code but it´s almost the same.

Martin,

Yes, indeed.

> You only
> can see _MSC_VER in glib because is the only exception.
> http://www.winehq.org/pipermail/wine-patches/2002-August/003110.html

OK, I've read it. Do you mean that the typedef is not properly handled 
by MinGW so #define is preferred, as said:

"Using a typedef can tweak bugs in the C++ parser under Mingw32"

If yes, they I can add new level of #ifdef dedicated for MinGW and 
changing integer types definition to #define instead of typedef.

Is this what you need?

> I think liblas c++ API is fully compatible with mingw right now. I need do
> many more test but I am almost sure of it. The only problem is in the CAPI
> module.

You mean the problem with #define vs typedef ?

> Perhaps we can study a method to test the libraries with las files. I could
> do test for mingw and .net/mono.

C++ and C API is tested with a bunch of unit tests

http://liblas.org/browser/trunk/test/unit

They are not completed and more test cases will be added in future.
Python bindings use tests based on Python native feature called docstring:

http://liblas.org/browser/trunk/python/tests

I understand that C++ unit tests and Python tests are useless for
you directly, and .NET/Mono needs to be equipped with its own tests.

Perhaps you could create 'tests' subdirectory insinde your bindings 
module and create dedicated unit tests based on native features of 
.NET/Mono. I think it would be a good idea for you to use teste cases 
from the C++ and Python tests but implement in .NET/Mono way.

> PERL people have something like this but more freak:
> Perl is distributed with some 120,000 functional tests.

Yes, Perl is well-covered with tests. I like it :-)

> These run as part of the normal build process, and extensively
> exercise the interpreter and its core modules.

We do run tests as a part of build process as well using command

$ make check

It will build and test libLAS.

On Windows, when using Visual Studio 2005, tests run after every build 
automatically on Post-Build Event:

http://liblas.org/browser/trunk/build/msvc80/liblas_test/liblas_test.vcproj#L93

> Perl developers rely
> on the functional tests to ensure that changes to the interpreter
> do not introduce bugs; conversely, Perl users who see the
> interpreter pass its functional tests on their system can have a
> high degree of confidence that it is working properly.

Yes, I agree it's a good idea.

As I said, test cases are not complete and we are still extending them.
If you have suggestion of new test cases, anywhere in C++ and Python 
stuff, feel free to post your ideas (here or as Trac Ticket) or submit 
your improvements directly to SVN. It will be greatly appreciated.

>> #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?
> 
> It´s only I can not see where liblas manage double and float conversions in
> liblas source code?¿?¿

There are only two macros that do all swapping job for intrinsic types:

LIBLAS_SWAP_BYTES
LIBLAS_SWAP_BYTES_N

Here they are defined:

http://liblas.org/browser/trunk/include/liblas/detail/endian.hpp#L94

Usage example is like this:

- size of x determined with sizeof operator

double x = 0.003;
LIBLAS_SWAP_BYTES(x);

- size given explicity:

char buf[100] = { ... };
LIBLAS_SWAP_BYTES_N(buf, 100);

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



More information about the Liblas-devel mailing list