Thanks Nyall,
Looking at the documentation it seems to be what I'm looking for.
Thanks,
Paul
*Paul Meems *
Release manager, configuration manager
and forum moderator of MapWindow GIS.
www.mapwindow.org
Owner of MapWindow.nl - Support for
Dutch speaking users.
www.mapwindow.nl
*The MapWindow
Checking http://en.cppreference.com/w/cpp/compiler_support shows C++11
support starting to take shape starting with gcc 4.3 (but it's missing
almost everything at that point).
Greg,
Can you explain the use case as to what keeps you on an older NetBSD but
unable to use a branch of a recent GDAL?
Even Rouault writes:
>> How will that be impacted by a C++11 requirement?
>
> GCC 4.8 is needed for C++11 I think. There are folks using recent GDAL on
> older distros like
> Ubuntu 12.04 (which ships with gcc 4.6). I guess they could switch to adding
> a PPA with a
> more recent toolchain.
On 6 Jan 2017 7:37 AM, "Paul Meems" wrote:
We're using GDAL v2.1.2 on Windows.
We use the GDAL library with MapWinGIS to connect to a PostGIS database.
When the PostGIS table has NULL values in integer, numeric or double fields
and that data is read the returned values are 0 (zero), which is une
We're using GDAL v2.1.2 on Windows.
We use the GDAL library with MapWinGIS to connect to a PostGIS database.
When the PostGIS table has NULL values in integer, numeric or double fields
and that data is read the returned values are 0 (zero), which is unexpected
by us.
We use Feature->GetFieldAsDou
MS4W builds are moving to VS2015, because PHP 7's requirement for that
compiler, but stable releases are done now with VS2012. (I've
officially moved away from the old VS2008)
-jeff
--
Jeff McKenna
President Emeritus, OSGeo Foundation
http://wiki.osgeo.org/wiki/Jeff_McKenna
On 2017-01-05 1
Hi Even,
Your change fix the warning. Thanks.
The other issue I was having is that because on:
/frmts/pdf/GNUmakefile
LDFLAGS and CPPFLAGS defines libstdc++ while the result setting from
./configure is libc++.
I simply change the PDF driver makefile to use libc++ instead of libstdc++ and
Why is there a desire to support old compilers for new code? Those that
don't want to upgrade compilers can always use existing distributions.
On Thu, Jan 5, 2017 at 11:32 AM, Kurt Schwehr wrote:
> Even responded while I was trying to write up something, so I'm going to
> stop writing and send
Even,
Thanks! I'm working on a change that will do:
nBlockXSize = std::min(nRasterXSize, 2048);
nBlockYSize = std::min(nRasterYSize, 128);
Getting a performance monitoring system setup is definitely on my todo
list, but sadly still down a ways.
On Thu, Jan 5, 2017 at 7:40 AM, Even Rouault
Even responded while I was trying to write up something, so I'm going to
stop writing and send :)
Howard,
Thanks for the thoughts. I believe we are thinking along the same lines.
All,
After time for comments, I plan to write up an RFC for the initial strategy
that is explicit about assumptions
>
> What is the list of compilers that GDAL actively and accidentally supports?
Currently, at least:
GCC >= 4.4 (actually must be 4.1 since this is what ancient mingw uses)
clang >= 3.something (3.0 probably)
VS >= 2008
ICC 15 probably
One aspect is to also consider the various analyzers used. I
> On Jan 5, 2017, at 9:08 AM, Kurt Schwehr wrote:
>
> A ping to bring the topic of C++11 back to the front post holidays.
>
> Thoughts?
>
> On Fri, Dec 23, 2016 at 10:05 AM, Kurt Schwehr wrote:
> Hi all,
>
> I would like to continue the C++11 discussion over the next couple weeks
> while ma
On jeudi 5 janvier 2017 07:18:45 CET Kurt Schwehr wrote:
> Frank, Even or anyone with experience with jp2k block sizes,
>
> Any chance you could comment on the change I proposed here?
>
> https://trac.osgeo.org/gdal/ticket/6764
>
> Is it reasonable to change this:
>
> if( nRasterXSize >= 20
Frank, Even or anyone with experience with jp2k block sizes,
Any chance you could comment on the change I proposed here?
https://trac.osgeo.org/gdal/ticket/6764
Is it reasonable to change this:
if( nRasterXSize >= 2048 )
nBlockXSize = 2048;
else
nBlockXSize = nRasterXSiz
A ping to bring the topic of C++11 back to the front post holidays.
Thoughts?
On Fri, Dec 23, 2016 at 10:05 AM, Kurt Schwehr wrote:
> Hi all,
>
> I would like to continue the C++11 discussion over the next couple weeks
> while many people are on slower development cycles with a proposal:
>
> *
15 matches
Mail list logo
