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

[Marcus D. Hanwell]

On Thu, Mar 14, 2013 at 5:01 PM, Kyle Lutz <kyle.lutz at kitware.com> wrote:
> 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.
>
Ah, then I would say they are historical, I am not aware of a page
explaining the rationale behind them and would defer to Bill Lorensen,
Ken Martin and Will Schroeder ;-) I know the iostream stuff was
because some of the original implementations were not in a namespace,
VTK would replace the STL implementation if it was buggy (we only just
got rid of vtkstd and the checks for bool). Maybe one of them will
chime in.

Marcus