[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