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

[Mateusz Loskot]

On 5 May 2016 at 16:31, Even Rouault <even.rouault at spatialys.com> 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 to be done (but
>> often the compiler can probably optimize away most of that). TODO:
>> References that explain this? Resizing the array could break anything that
>> was using a C style array pointer to the vector’s data
>>
>>  Drawbacks one and three can be eliminated by deriving a class from vector
>> that hides resize, so there really is only the single drawback of storage
>> overhead and bookkeeping, which are often minor.
>
> I'd not find it very attractive to create our own class just to prevent
> resizing for such a simple thing as an array of integers... "std::vector<int>
> oVals(256, 0)" is very readable. If it must not be resized for some reason, a
> comment should do.

An assertion, you mean :)

> One thing to keep in mind however is the potential impact of heap allocation
> in performance sensitive code paths.

Indeed.
I would divide Kurt's proposal to several phases, roughly:
1. Switch to C++11
2. Refactor: clean-up, clarify, simplify, make it less error prone
using C++11 idioms and features (i.e. int[256] => std::array<int,
256>)
3. Update coding guidelines
4. Measure and optimise using C++11 features with potential
functional/behavioural changes (yes, switch from stack to heap
allocation drags a behavioural change, e.g. exceptions).

Although it looks like a long and boring process, points 2 and 4 are
optional, IMO.
However, mixing plain refactoring with functional and behaviour
changes is a bad idea.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net