[vtk-developers] Updates to VTK's coding standard page

[Marcus D. Hanwell]

On Thu, Mar 14, 2013 at 4:36 PM, Kyle Lutz <kyle.lutz at kitware.com> wrote:
> On Thu, Mar 14, 2013 at 11:36 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> Hi,
>>
>> As we were linking to it from the commit guidelines page, I have also
>> taken the opportunity to update the coding standards page for VTK,
>>
>> http://vtk.org/Wiki/VTK_Coding_Standards
>>
>> This is in line with my understanding of recent discussions, such as
>> improvements to wrapping allowing default arguments, using STL in API
>> outside of vtkCommon* modules being acceptable, moving toward using
>> std::string in API rather that vtkStdString. Comments welcome, or feel
>> free to edit/raise concerns here.
>
> Is there any wiki page or public document explaining the rational
> behind these conventions?
>
> To be more specific, I don't understand why we insist upon the following:
>
> * "[the STL] should be used sparingly"
> * "STL use should use the PIMPL idiom"
> * "When using anything declared in iostream, do not use std::"
>
On second look, two are the new bits but you really didn't give me
enough context... VTK has a lot of containers that are wrapped in
Python, Tcl, Java, API returning std::vector etc is not wrappable
hence the encouragement to use VTK containers where possible. When not
exposed in the API/useful for inheritance then sticking with the PIMPL
idiom makes sense as has always been the policy, the iostream bringing
cout etc into the global namespace has been there since for a very
long time (since before the STL implementations were stable and is not
a new policy.

As I said before it would be better to debate these in specific
threads, along with your reasoning as to why the point you are
questioning should be changed. VTK has traditionally kept virtually
all STL out of its API, used object factories globally, only allows
heap allocation, ...

I would raise these for discussion in separate threads if you want to
push for some of these things to be changed. Allowing use of STL in
API at all is new, and has not been exposed in many places yet. I
promised to do it in a few of the charts classes to make inheritance
and modification easier for example but haven't gotten to it yet.

Marcus