[vtk-developers] VTK coding conventions clarification

David Lonie david.lonie at kitware.com
Tue Mar 18 11:09:53 EDT 2014


Hi list,

Referring to the document here:

http://public.kitware.com/Wiki/VTK_Coding_Standards

there are two conventions that appear to be in conflict:

27. STL usage is disallowed in the Common modules' public API, and should
only be used in implementation files there. The other modules may use STL,
but should do so only when necessary if there is not an appropriate VTK
class. Care should be taken when using the STL in public API, especially in
the context of what can be wrapped.

Rationale: limits header inclusion bloat, wrappers are not capable of
handling many non-vtkObject derived classes.


and

36. Do not use vtkStdString in new API; prefer std::string.

Rationale: vtkStdString was introduced as a workaround for compilers that
couldn't handle the long symbol name for the expanded std::string type. It
is no longer needed on modern platforms.


I've added some new API that uses std::string to set some character string
attributes, but vtkSetMacro and friends all try to pass the value to the
debug stream, which uses the vtkOStreamWrapper from Common/Core. Since
compilers and standard library implementation have matured since many of
these rules were put in place, I wonder if it may be time to relax some of
these restrictions?

To specifically address my issue of having new API using std::string that
can't be used with the VTK macros, I see a few different solutions:

1) Don't use the macros. This doesn't really address the issue, but will
let us avoid it for a while.

2) Use the vtkSetStringMacro etc that operate char* member variables. The
explicit memory handling of this approach is annoying, and it's nice to be
able to use non-C-array string representations that clean up after
themselves, copy/compare as objects, etc.

3) Remove rule #27 and allow STL containers everywhere, or at least make an
exception for std::string if it is to be our preferred string class.

4) Remove rule #36 and make vtkStdString the defacto string class for the
VTK library.

Any insight would be appreciated :-)

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtk-developers/attachments/20140318/17511a04/attachment.html>


More information about the vtk-developers mailing list