[vtk-developers] Removing the vtkstd headers from VTK master - using STL directly

Marcus D. Hanwell marcus.hanwell at kitware.com
Tue Dec 13 17:21:53 EST 2011


On Tue, Dec 13, 2011 at 4:21 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Tue, Dec 13, 2011 at 4:15 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> On Tue, Dec 13, 2011 at 2:11 PM, Sean McBride <sean at rogue-research.com>
>> wrote:
>>>
>>> On Tue, 13 Dec 2011 11:49:12 -0500, Marcus D. Hanwell said:
>>>
>>> >I just pushed a topic to reviewtest that removes vtkstd from VTK. For
>>> >testing purposes I removed the generation of vtkstd altogether, but
>>> >that could be modified.
>>> >
>>> >http://reviewtest.source.kitware.com:81/#/t/31/
>>> >
>>> >This seems to compile for me, and was done largely using a Python
>>> >script and a little regex. Are there objections to me merging this
>>> >topic in? Should the vtkstd headers be generated for legacy purposes,
>>> >I know at least ParaView (which I can fix) is using vtkstd in some
>>> >places.
>>>
>>> "vtkstd::" appears 105 times in our code.  Personally, I'm happy to change
>>> them all when we upgrade VTK, but it might be helpful, as Bill argues, to
>>> have some compatibility route.
>>>
>>> Was the motivation for this change just cleaning up old cruft?
>
> They have not been needed for quite some time, since we do not support
> compilers lacking an STL implementation any longer. I am cleaning up
> some of the old cruft that has built up, but will keep the option
> around for a version or so for those who need to make changes in their
> code.
>>>
>> I'll just add... if we do go with compatibility, then the "vtkstd::string"
>> lines in vtkWrapPython.c and vtkParseExtras.c must remain as-is, i.e. no
>> modifications should be done to either file.
>>
> Good point, so I will be leaving the headers there, but if you turn on
> the CMake variable VTK_LEGACY_REMOVE they will never be generated.
> They will go away for good in VTK 6. I will add code to remove this
> with the VTK legacy remove macro in the same way as the namespace
> then.
>
> Thanks for the feedback David.
>
I pushed an update to the topic, using the deprecation mechanism I
mentioned and the fixes to the wrappers. I would appreciate feedback,
turning on VTK_LEGACY_REMOVE will cause these things to disappear from
a new tree, and to not get compiled into the wrapper generators etc.

Marcus



More information about the vtk-developers mailing list