<div dir="ltr"><div>Hi list,</div><div><br></div><div>Referring to the document here:</div><div><br></div><a href="http://public.kitware.com/Wiki/VTK_Coding_Standards">http://public.kitware.com/Wiki/VTK_Coding_Standards</a><br>

<div><br></div><div>there are two conventions that appear to be in conflict:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font face="courier new, monospace">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.</font></div>

</div><div><div><font face="courier new, monospace"><br></font></div></div><div><div><font face="courier new, monospace">Rationale: limits header inclusion bloat, wrappers are not capable of handling many non-vtkObject derived classes.</font></div>

</div></blockquote><br><div>and</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font face="courier new, monospace">36. Do not use vtkStdString in new API; prefer std::string.</font></div>

<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">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.</font></div>

</div></blockquote><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="monospace">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?</font></div>

<div><font face="monospace"><br></font></div><div><font face="monospace">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:</font></div>

<div><font face="monospace"><br></font></div><div><font face="monospace">1) Don't use the macros. This doesn't really address the issue, but will let us avoid it for a while.</font></div><div><font face="monospace"><br>

</font></div><div><font face="monospace">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.</font></div>

<div><font face="monospace"><br></font></div><div><font face="monospace">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.</font></div>

<div><font face="monospace"><br></font></div><div><font face="monospace">4) Remove rule #36 and make vtkStdString the defacto string class for the VTK library.</font></div><div><br></div><div><font face="monospace">Any insight would be appreciated :-)</font></div>

<div><font face="monospace"><br></font></div><div><font face="monospace">Dave</font></div></div>