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 subroutines should be done

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 t

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 f

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, 256*sizeof(int)); > Are "we" doing

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: http://goo.gl/vuA3D6

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 have been > > trying to bend my coding to,

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 m

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

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 the

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 I

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 like more. > On Mo

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 screens and not ever

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 kir

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 rea

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

I was trying to give people an overall sense of my goals for GDAL. I'm sorry I added the context to the proposal that got the discussion off the track I intended. I am more interested in mechanics of the discussion before hitting huge topics. I love the discussion, but I feel like I totally fail

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 these changes. If the co

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++ features to introduce wid

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 rfc8_devgu

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 threa

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

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 solution requires a newer > > version of C++.

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. Simply, the initial pro

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 > because I thought i

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

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, initialValue) to do f

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

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 because I thought it was a simpler issue than most and we could use it to figure

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 should support VS2012, 2013 and 2015 (so no more

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 >> (so no more 2010) + GCC 5 > > > And one c

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 those compilers (I did). _

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 mailin

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 subje

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 that explains why th

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 mailto:even.roua...@spatialys.com>> wrote: [...] That would be interesting if you (or anyone) could list which C++11 features would be killer features

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 > as I raised in other emails,

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 w

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: > >> >> To start off the conversation,

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 VS201

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 seems a little silly. At > som

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 > > (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html),

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 overhead and bookkeeping that has

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 people use the same GCC versi

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 comp

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

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

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 suppo

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. http://gmt.soest.hawaii.ed

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 tha

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 mostly(completely?) built with Visual Studio 2010. And from >>

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 > > https://msdn.microsoft.com/en-us/library/hh56736

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 partial in VS 2010 VS2013 i

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 as

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 faced

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 initialization. > > Since man

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 availability of the C++11

[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