[vtk-developers] vtkStdString vs std::string

Bill Lorensen bill.lorensen at gmail.com
Fri Feb 22 14:24:45 EST 2013


I agree with Marcus. I would not underestimate how much time this would
take and what impact it might have on customers.

On Fri, Feb 22, 2013 at 1:15 PM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

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



-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130222/4be7a078/attachment.html>


More information about the vtk-developers mailing list