<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 19, 2014 at 9:10 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Sounds like removing the restriction on std::string in Core has the most support. Any objections? </div>
</blockquote><div><br></div><div>+1 </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
I'll add std::string support to vtkOStreamWrapper and update the conventions document later this week if I don't hear any reasons why this shouldn't be done.</div></blockquote><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>

<br></div><div>Thanks!</div><div>Dave</div></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 11:56 AM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">No worries about the wrappers, they have all supported std::string<br>

just fine ever since VTK 5.8.  And std::string should definitely be<br>
preferred over vtkStdString as an interface type.<br>
<br>
  David<br>
<div><br>
<br>
On Tue, Mar 18, 2014 at 9:46 AM, Sebastien Jourdain<br>
<<a href="mailto:sebastien.jourdain@kitware.com" target="_blank">sebastien.jourdain@kitware.com</a>> wrote:<br>
> I'm not sure for Java. When vtkStdString was used, we were getting a<br>
> vtkStdString object and not a regular Java String object.<br>
</div>> But don't know for std::string...<br>
<div><div>><br>
> Seb<br>
><br>
><br>
> On Tue, Mar 18, 2014 at 9:38 AM, David Lonie <<a href="mailto:david.lonie@kitware.com" target="_blank">david.lonie@kitware.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, Mar 18, 2014 at 11:33 AM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>><br>
>> wrote:<br>
>>><br>
>>> 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.<br>
>><br>
>><br>
>> I have not, I assumed that the rule in the guidelines implies that they<br>
>> are supported. I can test this out if we decide to keep std::strings around<br>
>> in our API.<br>
>><br>
>> Does anyone who works on the wrappings know off the top of their heads?<br>
>><br>
>> Dave<br>
>><br>
>>><br>
>>> 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>><br>
>>> wrote:<br>
>>> > 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<br>
>>> > should<br>
>>> > only be used in implementation files there. The other modules may use<br>
>>> > 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,<br>
>>> > 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<br>
>>> > that<br>
>>> > couldn't handle the long symbol name for the expanded std::string type.<br>
>>> > 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<br>
>>> > string<br>
>>> > attributes, but vtkSetMacro and friends all try to pass the value to<br>
>>> > the<br>
>>> > debug stream, which uses the vtkOStreamWrapper from Common/Core. Since<br>
>>> > compilers and standard library implementation have matured since many<br>
>>> > of<br>
>>> > these rules were put in place, I wonder if it may be time to relax some<br>
>>> > of<br>
>>> > these restrictions?<br>
>>> ><br>
>>> > To specifically address my issue of having new API using std::string<br>
>>> > 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<br>
>>> > will let<br>
>>> > us avoid it for a while.<br>
>>> ><br>
>>> > 2) Use the vtkSetStringMacro etc that operate char* member variables.<br>
>>> > The<br>
>>> > explicit memory handling of this approach is annoying, and it's nice to<br>
>>> > 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<br>
>>> > 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<br>
>>> > the<br>
>>> > VTK library.<br>
>>> ><br>
>>> > Any insight would be appreciated :-)<br>
>>> ><br>
>>> > Dave<br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <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></blockquote></div><br><br clear="all"><div><br></div>-- <br>| Aashish Chaudhary <br>| R&D Engineer         <br>| Kitware Inc.            <br>| <a href="http://www.kitware.com">www.kitware.com</a>    
</div></div>