Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 3 June 2016 at 15:54, Kurt Schwehr wrote: > I would make some of assertions (some just restating what Even wrote) > > * The cost to heap allocation is a fair question (but I would suggest we > defer the work until required) > > * Any work done on performance critical

Re: [gdal-dev] Starting a discussion on style and coding guidelines

I would make some of assertions (some just restating what Even wrote) * The cost to heap allocation is a fair question (but I would suggest we defer the work until required) * Any work done on performance critical subroutines should be done carefully. * It would help to have a standard comment

Re: [gdal-dev] Starting a discussion on style and coding guidelines

Le jeudi 02 juin 2016 00:46:06, Kurt Schwehr a écrit : > https://docs.google.com/document/d/1O1B7LY13L532kXcYcB2EdO65m5LOCsqaqn5R9iJ > fSPU/pub > > The optimized stack .o is 1248 bytes and the on the heap vector is 1600 > bytes with gcc 4.8. The cost of either is pretty small. So, if there are

Re: [gdal-dev] Starting a discussion on style and coding guidelines

https://docs.google.com/document/d/1O1B7LY13L532kXcYcB2EdO65m5LOCsqaqn5R9iJfSPU/pub The optimized stack .o is 1248 bytes and the on the heap vector is 1600 bytes with gcc 4.8. The cost of either is pretty small. So, if there are 100 of these in gdal, we are talking about 30-60K of extra object

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On Mon, May 9, 2016 at 2:49 PM, Mateusz Loskot wrote: > > Point taken. > > Although the proposal looks OK, I'd suggest to check what > assembler code generates your favourite C++ toolkit, > or at least measured times for > > int anVals[256]; > memset(anVals, 0,

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 9 May 2016 at 18:02, Kurt Schwehr wrote: > Sounds like we are on the right track now. Hopefully, the proposal is > clearer after a few more changes just now. > > My concern is that you seem to taking the discuss as the proposal and not > ready the proposal as stand alone:

Re: [gdal-dev] Starting a discussion on style and coding guidelines

>http://goo.gl/vuA3D6 (Especially after > I fixed the "Status:"... which I just changed again). Looks good to me. Perhaps 256 bytes as the threshold ? (a LUT of 256 byte elements would fit) By the way, is it a threshold per array or for all arrays of a given function ? I can think of some

Re: [gdal-dev] Starting a discussion on style and coding guidelines

I intend to argue strongly against the many styles at a later date and in a separate thread. On Mon, May 9, 2016 at 9:21 AM, Mateusz Loskot wrote: > On 9 May 2016 at 16:47, Kurt Schwehr wrote: > > There are lots of implicit style things in GDAL that I

Re: [gdal-dev] Starting a discussion on style and coding guidelines

Please fork the 80 col style guide to a new thread. Yes, there are lots of issues with the coding style, but can we do one thing at a time? If you are really motivated, why not write a proposal like mine and talk through the issues of different column constraints (there are good reasons for the

Re: [gdal-dev] Starting a discussion on style and coding guidelines

All, Just to be totally obvious and not meant to squash questions, comments, concerns. I'm trying to narrow the scope of this discussion. http://goo.gl/vuA3D6 (Especially after I fixed the "Status:"... which I just changed again). My intent was to have a super narrow focus to the proposal,

Re: [gdal-dev] Starting a discussion on style and coding guidelines

I like one statement per line because it helps walking through the code with gdb; you can see the whole statement that is going to be executed. Fully agree, and my example respects that. I also share the idea that seeing a whole subroutine or a logical part at once helps understanding

Re: [gdal-dev] Starting a discussion on style and coding guidelines

I do all my programing in laptops, and yes I have a 15 inches HiRes screen but I also have my eyes, well, weakened (and 54 years old) so I make the fonts larger. Having to permanently scroll up and down is far worst than any perception purity. There is one aspect of the coding style that

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 9 May 2016 at 16:47, Kurt Schwehr wrote: > There are lots of implicit style things in GDAL that I have been > trying to bend my coding to, but I find clashing styles in the same file all > the time, so it is hard to get what I do to match. Just choose the one of the two you

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 9 May 2016 at 17:14, Joaquim Luis wrote: > Hi, > > There is one aspect of the coding style that I honestly do not understand. > Why continuing to recommend the 80 chars line width? Perhaps, paraphrasing Kevlin Henney, because not everyone falls in love with high-resolution

Re: [gdal-dev] Starting a discussion on style and coding guidelines

I like one statement per line because it helps walking through the code with gdb; you can see the whole statement that is going to be executed. I also share the idea that seeing a whole subroutine or a logical part at once helps understanding the code. Ari 09.05.2016, 18:14, Joaquim Luis

Re: [gdal-dev] Starting a discussion on style and coding guidelines

Hi, There is one aspect of the coding style that I honestly do not understand. Why continuing to recommend the 80 chars line width? I don't by the readability argument, well on the contrary, if because of it the result is an excess 'verticalization' of the code it becomes much harder to

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 9 May 2016 at 09:15, Ari Jolma wrote: > 05.05.2016, 01:30, Kurt Schwehr kirjoitti: > > Hi all, > > If you've been watching the timeline on trac, you have probably seen a large > number of cleanup CLs from me. It's definitely past time to get some > discussion going on

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 8 May 2016 at 07:01, Kurt Schwehr wrote: > > Are meaning to say that my proposal is vague? Yes, I called that on the course of the discussion, it has become less and less clear to me: what is the actual goal? - make the stack/heap usage more configurable - use new C++

Re: [gdal-dev] Starting a discussion on style and coding guidelines

05.05.2016, 01:30, Kurt Schwehr kirjoitti: Hi all, If you've been watching the timeline on trac, you have probably seen a large number of cleanup CLs from me. It's definitely past time to get some discussion going on these changes. If the community likes these, we can add them to

Re: [gdal-dev] Starting a discussion on style and coding guidelines

Mateusz, Thanks for calling out the confusion! Are meaning to say that my proposal is vague? I rephrased the status to be more clear that the C++11/14 focus is the GDAL community (AKA the majority of this

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On Fri, May 6, 2016 at 2:47 PM, Kurt Schwehr wrote: > For stack ranking, see the "alternatives" section of this (and I did not > include my preferred std::vector solution in the list): That seems like a reasonable solution. The function/method call interface is where I would

Re: [gdal-dev] Starting a discussion on style and coding guidelines

http://www.keittlab.org/ On Fri, May 6, 2016 at 2:47 PM, Mateusz Loskot wrote: > On 6 May 2016 at 21:55, Kurt Schwehr wrote: > > My belief is that for this particular proposal, we should not have the > > C++11/14 discussion unless the best overall

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 6 May 2016 at 21:55, Kurt Schwehr wrote: > My belief is that for this particular proposal, we should not have the > C++11/14 discussion unless the best overall solution requires a newer > version of C++. The solution I propose to be the best works in C++03 and > newer.

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On Fri, May 6, 2016 at 3:55 PM, Kurt Schwehr wrote: > I was not intending for C++11 to be a big part of the discussion as it is > a much more complicated topic, but I do appreciate the discussion. I > picked the stack + memset -> std::vector(nSize, initialValue) to do first >

Re: [gdal-dev] Starting a discussion on style and coding guidelines

For stack ranking, see the "alternatives" section of this (and I did not include my preferred std::vector solution in the list): https://docs.google.com/document/d/1Y9flzxj3Uz1vTEPCBmlswgi470m8i-oepGutVkbowfc/pub BTW, Someone pointed out that I originally listed autoptr (which just won't work)

Re: [gdal-dev] Starting a discussion on style and coding guidelines

http://www.keittlab.org/ On Fri, May 6, 2016 at 1:55 PM, Kurt Schwehr wrote: > I was not intending for C++11 to be a big part of the discussion as it is > a much more complicated topic, but I do appreciate the discussion. I > picked the stack + memset -> std::vector(nSize,

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 2016-05-06 11:38 AM, Mateusz Loskot wrote: On 6 May 2016 at 16:20, Joaquim Luis wrote: On Fri, 06 May 2016 15:00:07 +0100, Even Rouault wrote: - ECW SDK 5.2.1: available for VS2010, VS2012, VS2013 I got information that the next SDK 5.3

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 6 May 2016 at 16:20, Joaquim Luis wrote: > On Fri, 06 May 2016 15:00:07 +0100, Even Rouault > wrote: > >>> - ECW SDK 5.2.1: available for VS2010, VS2012, VS2013 >> >> >> I got information that the next SDK 5.3 should support VS2012, 2013 and >> 2015

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On Fri, 06 May 2016 15:00:07 +0100, Even Rouault wrote: - ECW SDK 5.2.1: available for VS2010, VS2012, VS2013 I got information that the next SDK 5.3 should support VS2012, 2013 and 2015 (so no more 2010) + GCC 5 And one can also build SDK 3.3 with all of

Re: [gdal-dev] Starting a discussion on style and coding guidelines

> - ECW SDK 5.2.1: available for VS2010, VS2012, VS2013 I got information that the next SDK 5.3 should support VS2012, 2013 and 2015 (so no more 2010) + GCC 5 -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev

Re: [gdal-dev] Starting a discussion on style and coding guidelines

> 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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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 > wrote: [...] That would be interesting if you (or anyone) could list which C++11

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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 >

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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:

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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 > >

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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.

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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 > >

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

Le jeudi 05 mai 2016 00:51:28, Mateusz Loskot a écrit : > On 4 May 2016 at 23:30, Kurt Schwehr wrote: > > To start off the conversation, I wrote up a doc on changing large C > > arrays on the stack to std::vectors to get this data off of the stack > > and to simplify

Re: [gdal-dev] Starting a discussion on style and coding guidelines

On 4 May 2016 at 23:30, Kurt Schwehr wrote: > > To start off the conversation, I wrote up a doc on changing large C arrays > on the stack to std::vectors to get this data off of the stack and to > simplify initialization. > Since many, if not most, of the ideas rely on

[gdal-dev] Starting a discussion on style and coding guidelines

Hi all, If you've been watching the timeline on trac, you have probably seen a large number of cleanup CLs from me. It's definitely past time to get some discussion going on these changes. If the community likes these, we can add them to rfc8_devguide