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

[Kurt Schwehr]

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 file size
for all the cases in GDAL.

For stack usage, start thinking about tons of threads spread out over lots
of cores and think about how systems are built...  Google Compute Engine
has 32 core machines.  If you want to get the most out your machines at
scale, you want a small stack.

int anVals[256] = {};  Does initialize everything to the default value
(zeros), but doesn't solve the stack issue.

Making a little class is yet another thing for people to learn when vector
looks to me to work quite well.

On Mon, May 9, 2016 at 1:37 PM, Andrew Bell <andrew.bell.ia at gmail.com>
wrote:

> On Mon, May 9, 2016 at 2:49 PM, Mateusz Loskot <mateusz at loskot.net> 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 memset anymore in these cases?
>
> int anVals[256] = {};
>
> seems preferable
>
>
>> vs
>>
>> std::vector<int> oVals(256, 0);
>>
>> and compare with:
>>
>> std::vector<char> oVals(256, 0);
>>
>
> Think vector is a bad solution for something that's fixed.  Just write
> something.  But I already suggested that and wrote something... :)
>
> Do you know why they are wedded to a 16K stack?
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160601/819028a5/attachment.html>