[vtk-developers] vtkStdString vs std::string

Marcus D. Hanwell marcus.hanwell at kitware.com
Fri Feb 22 13:15:50 EST 2013


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



More information about the vtk-developers mailing list