[vtk-developers] VTK coding conventions clarification

[Berk Geveci]

Not an answer to your question but a concern. Did you verify that
public methods that use std::string are wrapped properly in all
languages that we support? If not, you will have provide public
methods that use char* in addition. Or add support for std::string to
all wrapper generators. I suspect that Python works but I don't know
about others.

On Tue, Mar 18, 2014 at 11:09 AM, David Lonie <david.lonie at kitware.com> wrote:
> 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
>
> _______________________________________________
> 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
>
>