I see a link to download the source
http://download.osgeo.org/gdal/2.0.2/gdal202.zip
when can I find a prebuilt version of GDAL 2.0.2
Thanks
Gane
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
> I misinterpreted this thread because of the title. It seems this isn't
> really about code style or C++ 11.
I agree this thread mixes different topics, which causes some confusion. The
word C++11 appearing in a doc has created some passion, whereas it is probably
not the heart of the subje
On Thu, May 5, 2016 at 10:19 AM, Kurt Schwehr wrote:
> Thanks all for your comments! I will try to write up a similar proposal
> for C++11 based on what people have written.
>
> This local stack storage change is for a real need, so it's probably good
> that I add a use case that explains why th
How about C++11 threads?
Ray
On 5/5/2016, Thursday 12:43 PM, Mark Coletti wrote:
On Thu, May 5, 2016 at 11:15 AM, Even Rouault
mailto:even.roua...@spatialys.com>> wrote:
[...]
That would be interesting if you (or anyone) could list which
C++11 features would be killer features
Hello devs,
I just have posted my GSoC project info at
https://trac.osgeo.org/gdal/wiki/DWG_driver
Now it has a draft of new CAD support library (named libopencad), and detailed
timeline.
There are also links where you can see what have already been done in that way.
I will be very pleased with
On Thu, May 5, 2016 at 11:15 AM, Even Rouault
wrote:
> [...]
> That would be interesting if you (or anyone) could list which C++11
> features would be killer features
> to justify the upgrade to C++11 vs the potential pains that such a move
> might cause (especially
> as I raised in other emails,
On 5/5/2016 9:00 AM, Kurt Schwehr
wrote:
Thanks! I've integrated your derived class in the
alternates section and Even's response about commenting on resize
into the drawbacks line
Can you provide (on the list would be best) a bit more on w
I'm currently stuck on the following compilers:
- Visual Studio 2010 SP1
- GCC 4.7
C++11 is only partially supported with these compilers.
Regards
Damian
On 4 May 2016 at 23:51, Mateusz Loskot wrote:
> On 4 May 2016 at 23:30, Kurt Schwehr wrote:
>
>>
>> To start off the conversation,
In the VS World...
If you delete C/C++ memory/objects in a DLL that has been compiled with the
same VS compiler you are ok.
If you attempt to delete a memory/object in DLL/application compiled with a
different version of the VS compiler all bets are off.
For example:
Allocate an object in VS201
On Thu, May 5, 2016 at 10:15 AM, Even Rouault
wrote:
>
> > As for the notion of replacing some allocations with vectors, well,
> great.
> > But the GDAL codebase is creaky in lots of places and to get too
> particular
> > about the advantage/disadvantage of vectors seems a little silly. At
> som
Thanks all for your comments! I will try to write up a similar proposal
for C++11 based on what people have written.
I've integrated (and still working on) a number of the points from the
discussion so far on the stack storage issue into the doc and added a
section titled "Impact of the proposed
Le jeudi 05 mai 2016 16:49:37, Andrew Bell a écrit :
> On Thu, May 5, 2016 at 8:26 AM, Even Rouault
>
> wrote:
> > Might be a little trickier with GCC, particularly with the new GCC 5
> > C++11 *ABI* and the dual ABI thing
> > (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html),
On 5 May 2016 at 16:31, Even Rouault wrote:
> Le jeudi 05 mai 2016 16:14:34, David Strip a écrit :
>> On 5/4/2016 4:30 PM, Kurt Schwehr wrote:
>>
>> Drawbacks:
>>
>>
>> It is possible to change the size of the vector later on in the code
>> Vector has some storage overhead and bookkeeping that has
On Thu, May 5, 2016 at 8:26 AM, Even Rouault
wrote:
>
> Might be a little trickier with GCC, particularly with the new GCC 5 C++11
> *ABI* and the dual ABI thing
> (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html),
> but if
> I understand well, if people use the same GCC versi
Le jeudi 05 mai 2016 16:14:34, David Strip a écrit :
> On 5/4/2016 4:30 PM, Kurt Schwehr wrote:
>
>
>
>
>
>
>
> Drawbacks:
>
>
> It is possible to change the size of the vector later on in the code
> Vector has some storage overhead and bookkeeping that has to be done (but
> often the comp
On 5/4/2016 4:30 PM, Kurt Schwehr
wrote:
Drawbacks:
It is possible to change the size of the vector later on in the code
Vector has some storage overhead and bookkee
What version of GDAL are you using? Can you provide the command or calling
code that you are using? Can you use a debugger and give a stack trace?
On Thu, May 5, 2016 at 12:42 AM, jramm wrote:
> Hi I am getting a segfault in a call to GDALWriteBlock with this code:
>
>
>
> Stepping through se
Le jeudi 05 mai 2016 14:22:03, Jeff McKenna a écrit :
> On 2016-05-05 9:10 AM, Jeff McKenna wrote:
> > On 2016-05-05 5:14 AM, Dmitry Baryshnikov wrote:
> >> Hi,
> >>
> >> I think it's time to go forward and shift to C++11 in i.e. GDAL 2.2 and
> >> drop old staff as it was with Windows mobile suppo
I'm also updating my builds to support 2015 for a future inclusion in GMT.
There is, however, a bit storm ahead. Files created with HDF5.10 break
compatibility with older versions and can't be read. Put netCDF in this
bag as well. See GMT's #3495 for a recent case.
http://gmt.soest.hawaii.ed
On 2016-05-05 9:10 AM, Jeff McKenna wrote:
On 2016-05-05 5:14 AM, Dmitry Baryshnikov wrote:
Hi,
I think it's time to go forward and shift to C++11 in i.e. GDAL 2.2 and
drop old staff as it was with Windows mobile support, VB, etc.
Yes, it may be some regression in ABI, but this is less evil tha
On 2016-05-05 5:14 AM, Dmitry Baryshnikov wrote:
Hi,
I think it's time to go forward and shift to C++11 in i.e. GDAL 2.2 and
drop old staff as it was with Windows mobile support, VB, etc.
Yes, it may be some regression in ABI, but this is less evil than
support lot of ancient compilers.
During
On 5 May 2016 at 11:28, Even Rouault wrote:
> Le jeudi 05 mai 2016 11:09:48, Mateusz Loskot a écrit :
>> On 5 May 2016 at 01:45, Even Rouault wrote:
>> > Of the potential issues with requiring C++11, I can think of OSGeo4W. It
>> > is mostly(completely?) built with Visual Studio 2010. And from
>>
Le jeudi 05 mai 2016 11:09:48, Mateusz Loskot a écrit :
> On 5 May 2016 at 01:45, Even Rouault wrote:
> > Of the potential issues with requiring C++11, I can think of OSGeo4W. It
> > is mostly(completely?) built with Visual Studio 2010. And from
> > https://msdn.microsoft.com/en-us/library/hh56736
On 5 May 2016 at 01:45, Even Rouault wrote:
> Of the potential issues with requiring C++11, I can think of OSGeo4W. It is
> mostly(completely?) built with Visual Studio 2010. And from
> https://msdn.microsoft.com/en-us/library/hh567368.aspx , support of C++11 is
> only partial in VS 2010
VS2013 i
I am a humble geologist, rather than a Computer Scientist, and do not
pretend to understand all the ins-and-outs of this type of discussion - and
hence read, in the hopes of learning, but otherwise keep quiet!
I suspect that I am also something of a 'throw-back' in that I continue to
use Simula as
Hi,
I think it's time to go forward and shift to C++11 in i.e. GDAL 2.2 and
drop old staff as it was with Windows mobile support, VB, etc.
Yes, it may be some regression in ABI, but this is less evil than
support lot of ancient compilers.
During our work on cmake build system for GDAL I faced
Hi I am getting a segfault in a call to GDALWriteBlock with this code:
Stepping through seems to suggest that the segfault is arising from line 171
of "geo_new.c" in libgeotiff:
I cant find previsely what it is I have done wrong to cause this in my
codeany ideas?
--
View this message i
27 matches
Mail list logo
