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

[Kyle Lutz]

On Thu, Mar 14, 2013 at 4:56 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> 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.

I think you may have misinterpreted my post. I have no desire to
change any of the VTK coding standards. I was merely curious as to the
"why" behind some of them.

-kyle