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

Marcus D. Hanwell marcus.hanwell at kitware.com
Thu Mar 14 17:04:26 EDT 2013


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



More information about the vtk-developers mailing list