[postgis-devel] Re: [postgis-users] MSVC Patch #1

[Mateusz Loskot]

Mark Cave-Ayland wrote:
> On Fri, 2007-09-21 at 12:47 -0600, Charlie Savage wrote:
>> Hi Mark,
>>
>> Did you ever get a chance to look at this patch?  Any chance of getting 
>> it applied - assuming its ok?
>>
>> Charlie
> 
> 
> Hi Charlie,
> 
> Okay I've had a look at this, and applied some parts of the non-MSVC new
> files to the tree. I really liked the changes to the PROJ.4 bindings, as
> it gets rid of the auto-import warnings for PROJ.4 on MingW :)
> 
> Some feedback on the other parts of the patch that weren't applied:
> 
> - inttypes.h / stdint.h
> 
> I'm guessing that these are required to allow MSVC compatibility with
> snprintf()? Will these be useful for other platforms or is this purely
> for MSVC?

Mark,

I haven't track this subject well, but just want to share some euro
cents. The problem is that Visual C++ compiler does not provide these
headers. These files come from C99 standard library, addendum to C89,
also part of POSIX.

Unfortunately, Visual C++ does not provide C99 features, so they are
better to be avoided for better portability.

> - rint.c
> 
> I was quite surprised that MSVC required this, since MingW doesn't
> require this at all. This seems to imply that rint() is already included
> as part as the MSVCRT - perhaps all that is needed is an alias from
> rint() to _rint() or something similar?

No, unfortunately the situation is the same as with the headers above.
That's also the reason why we added custom implementation of rounding
functions with Sandro to GEOS:

http://svn.refractions.net/geos/trunk/source/util/math.cpp

> - config.h.vc/ config.h / unistd.h
> 
> I think I see that this is again adding extra headers for MSVC mainly to
> do with snprintf(); 

BTW, here you can find more define of equivalents for Visual C++:

http://svn.osgeo.org/gdal/trunk/gdal/port/cpl_config.h.vc

> however it struck me that it may be better to
> combine these changes in a single header file and include it the main
> liblwgeom.h which should prevent duplication of the #ifdef _MSVC_VER
> statements and help maintenance in the future.

In GDAL, we use separate config.h files.many features, then

> Anyway, I hope this helps. I think that with a little bit more thought
> (and perhaps help from Mateusz) we should be able to get something
> applied for MSVC - I imagine that most of the questions are due to my
> lack of understanding of the MSVC build environment.

I hope my notes are helpful, but I'm here if you have more questions
or want me to test something with Visual C++ 2005.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net