<div dir="ltr"><div class="gmail_extra"><div>Thanks all for your comments!  I will try to write up a similar proposal for C++11 based on what people have written.<br></div><div><br></div><div>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 change"<br></div><div><br></div><div>This local stack storage change is for a real need, so it's probably good that I add a use case that explains why this change is important.  And I >>believe<< (but am not 100% sure) that using std::vector is the strongest solution for the majority of instances of large buffers on the stack in gdal.</div><div><br></div><div>Use case:  (note that I can only share generals)<br></div><div><br></div><div>At Google, we have jobs that use GDAL running with thousands of cores and >20 threads per process that run for days.  The overhead of having to allow for bumping the stack size adds substantial overhead to all those jobs.  GDAL is the only thing driving the requirement for the larger stack.  For people using GDAL on a desktop machine, the larger stack is unlikely to be a real issue.  For anyone running large multithreaded jobs in the cloud, the large stack is a real cost issue.  The overhead of vector and heap allocation in all these cases I've looked at in GDAL so far is far smaller than the cost from the stack size overhead.</div>
</div></div>