<div dir="ltr">While we're on this topic, this info seems relevant:<div><br></div><div><div>VTK/Common/Core/vtkArrayCoordinates.h:#include <vector></div><div>VTK/Common/Core/vtkArrayExtents.h:#include <vector> // STL Header</div>

<div>VTK/Common/Core/vtkArrayExtentsList.h:#include <vtksys/stl/vector> // STL Header</div><div>VTK/Common/Core/vtkArraySort.h:#include <vector></div><div>VTK/Common/Core/vtkIOStream.h:#include <iostream>  // Include real ansi istream and ostream.<br>

</div><div>VTK/Common/Core/vtkIOStream.h:#include <fstream>   // Include real ansi ifstream and ofstream.</div><div>VTK/Common/Core/vtkIOStream.h:#include <iomanip>   // Include real ansi io manipulators.</div>

<div>VTK/Common/Core/vtkIOStreamFwd.h:#include <iosfwd></div><div>VTK/Common/Core/vtkStdString.h:#include <string>       // For the superclass.<br></div><div>VTK/Common/Core/vtkTypeTemplate.h:#include <string><br>

</div><div>VTK/Common/Core/vtkTypeTemplate.h:#include <typeinfo></div><div>VTK/Common/Core/vtkTypedDataArrayIterator.h:#include <iterator> // For iterator traits</div><div>VTK/Common/Core/vtkUnicodeString.h:#include <string><br>

</div><div>VTK/Common/Core/vtkUnicodeString.h:#include <vector></div><div><br></div></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 11:38 AM, David Lonie <span dir="ltr"><<a href="mailto:david.lonie@kitware.com" target="_blank">david.lonie@kitware.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Tue, Mar 18, 2014 at 11:33 AM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not an answer to your question but a concern. Did you verify that<br>
public methods that use std::string are wrapped properly in all<br>
languages that we support? If not, you will have provide public<br>
methods that use char* in addition. Or add support for std::string to<br>
all wrapper generators. I suspect that Python works but I don't know<br>
about others.</blockquote><div><br></div></div><div>I have not, I assumed that the rule in the guidelines implies that they are supported. I can test this out if we decide to keep std::strings around in our API.</div><div>

<br>
</div><div>Does anyone who works on the wrappings know off the top of their heads?</div><div><br></div><div>Dave</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>
On Tue, Mar 18, 2014 at 11:09 AM, David Lonie <<a href="mailto:david.lonie@kitware.com" target="_blank">david.lonie@kitware.com</a>> wrote:<br>
</div><div><div>> Hi list,<br>
><br>
> Referring to the document here:<br>
><br>
> <a href="http://public.kitware.com/Wiki/VTK_Coding_Standards" target="_blank">http://public.kitware.com/Wiki/VTK_Coding_Standards</a><br>
><br>
> there are two conventions that appear to be in conflict:<br>
><br>
> 27. STL usage is disallowed in the Common modules' public API, and should<br>
> only be used in implementation files there. The other modules may use STL,<br>
> but should do so only when necessary if there is not an appropriate VTK<br>
> class. Care should be taken when using the STL in public API, especially in<br>
> the context of what can be wrapped.<br>
><br>
> Rationale: limits header inclusion bloat, wrappers are not capable of<br>
> handling many non-vtkObject derived classes.<br>
><br>
><br>
> and<br>
><br>
> 36. Do not use vtkStdString in new API; prefer std::string.<br>
><br>
> Rationale: vtkStdString was introduced as a workaround for compilers that<br>
> couldn't handle the long symbol name for the expanded std::string type. It<br>
> is no longer needed on modern platforms.<br>
><br>
><br>
> I've added some new API that uses std::string to set some character string<br>
> attributes, but vtkSetMacro and friends all try to pass the value to the<br>
> debug stream, which uses the vtkOStreamWrapper from Common/Core. Since<br>
> compilers and standard library implementation have matured since many of<br>
> these rules were put in place, I wonder if it may be time to relax some of<br>
> these restrictions?<br>
><br>
> To specifically address my issue of having new API using std::string that<br>
> can't be used with the VTK macros, I see a few different solutions:<br>
><br>
> 1) Don't use the macros. This doesn't really address the issue, but will let<br>
> us avoid it for a while.<br>
><br>
> 2) Use the vtkSetStringMacro etc that operate char* member variables. The<br>
> explicit memory handling of this approach is annoying, and it's nice to be<br>
> able to use non-C-array string representations that clean up after<br>
> themselves, copy/compare as objects, etc.<br>
><br>
> 3) Remove rule #27 and allow STL containers everywhere, or at least make an<br>
> exception for std::string if it is to be our preferred string class.<br>
><br>
> 4) Remove rule #36 and make vtkStdString the defacto string class for the<br>
> VTK library.<br>
><br>
> Any insight would be appreciated :-)<br>
><br>
> Dave<br>
><br>
</div></div><div><div>> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>