I agree with Marcus. I would not underestimate how much time this would take and what impact it might have on customers.<br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 1:15 PM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@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 class="im">On Thu, Feb 21, 2013 at 10:12 AM, Aashish Chaudhary<br>
<<a href="mailto:aashish.chaudhary@kitware.com">aashish.chaudhary@kitware.com</a>> wrote:<br>
> On Thu, Feb 21, 2013 at 9:59 AM, Marcus D. Hanwell<br>
> <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
>> It does exist in some public API, and some functions return it too. We<br>
>> also have vtkStringArray - should that be changed to use std::string<br>
>> instead of vtkStdString? We also have some code to support<br>
>> vtkUnicodeString in public API, although not very much.<br>
>><br>
>> I am totally in favor of moving to std::string - although I don't know<br>
>> if we want to do a mass renaming - are we talking changing<br>
>> recommendation here, or trying to go through VTK and entirely remove<br>
>> vtkStdString? Berk expressed support for using std::string last year<br>
>> along with limited use of other STL types in headers outside of<br>
>> Common, although we never found the time to do much.<br>
><br>
> I am in favor of removing vtkStdString altogether, unless there is a<br>
> technical issue (seems none now), for the sake of clarity and<br>
> consistency (time permitting).<br>
><br>
</div>There are still technical issues, the worst that I encountered is that<br>
vtkStdString implicitly casts to const char *<br>
<br>
operator const char *() { return this->c_str(); }<br>
<br>
This has led to VTK being littered with code that should have simply<br>
called c_str() but instead relies on this implicit cast that has been<br>
in place for many years. It isn't a problem for changing argument<br>
types, but for return types it would be a source incompatible change<br>
(for example in vtkStringArray). The change is pretty simple when<br>
fixing, but it could take quite a bit of time beyond a simple sed of<br>
the source tree and break client code.<br>
<br>
There is also the question of who would have the time to take care of<br>
this, and checking for any other possible backwards incompatible API<br>
changes that might be introduced (I am not aware of anything else).<br>
<span class="HOEnZb"><font color="#888888"><br>
Marcus<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Unpaid intern in BillsBasement at noware dot com<br>