# Proposal: Should we replace vtkStdString with std::string

**URL:** https://discourse.vtk.org/t/proposal-should-we-replace-vtkstdstring-with-std-string/796
**Category:** Development
**Created:** [April 19, 2019, 7:56pm UTC](https://discourse.vtk.org/t/proposal-should-we-replace-vtkstdstring-with-std-string/796 "2019-04-19T19:56:07Z")
**Posts on this page:** 1
**Showing post:** 14

<div class="post-metadata">

### Author: ![lassoan](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lassoan/32/50_2.png) [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [April 25, 2019, 2:53am UTC](https://discourse.vtk.org/t/proposal-should-we-replace-vtkstdstring-with-std-string/796/14 "2019-04-25T02:53:09Z")

</div>

> [@toddy](#):
>
> I also wonder how many downstream users would balk at such a breaking change.

It is a significant problem that VTK cannot robustly read/write files that have special characters in their names or may generate invalid files if you change the locale. Probably majority of application developers would accept breaking changes to solve these issues. To make transition easier, we could make vtkString an alias of std::string or enable automatic const char\* conversion (temporarily, controlled by a CMake flag).

Thanks for all the feedbacks everyone. This discussion helped in formulating a potential design and plan that I summarized [here](https://www.slicer.org/wiki/Documentation/Labs/VTK-String). We may get back to this later, when ongoing refactoring efforts (such as oriented image data support) are completed and a driving project with appropriate funding is identified.

---

_[View the full topic](https://discourse.vtk.org/t/proposal-should-we-replace-vtkstdstring-with-std-string/796)._