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

[Will Schroeder]

Kyle to a large extent it's historical. Twenty years ago many things were
brittle including compilers, STL, and wrapping. This led to a desire to
keep things clean and simple. For example the wrapping process choked for a
long time on fancy STL stuff. I also am of the opinion that the API to STL
is, shall we say, poor plus it affects compilation time. We wanted to hide
some of the nastiness from the wrapping process, from users, and encourage
passing data through simpler exchange mechanisms. The PIMPL approach also
hides the underlying implementation which provides more freedom if you want
to change things up at a later time. I'm sure I'm forgetting a couple of
other reasons, but Bill is in Santa Cruz for the month so I doubt he'll
chip in ;-)

W


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.
>
> -kyle
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130314/dd29e6b1/attachment.html>