<div>Hi Marcus,</div><div><br></div><div>The two lines where "vtkstd::" appears as a strcmp argument should be removed,</div><div>rather than converted to "std::".</div><div><br></div><div>vtkParseExtras.c line 686, vtkWrapPython.c line 369</div>

<div><br></div><div>If vtkstd is no longer in any VTK headers, the wrappers don't need to look vtkstd::string.</div><div>Fortunately the wrappers already look for std:string.</div><div><br></div><div> - David</div><div>

<br></div><br>On Tue, Dec 13, 2011 at 1:43 PM, Marcus D. Hanwell <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>> Hi David,<br>><br>> The commit in question is included below for your convenience. We<br>

> should be upgrading the main Gerrit soon, but I could post it there<br>> too if it makes things easier. I also pushed the topic as it is to the<br>> stage if you would rather take a look at it there.<br>><br>

> Marcus<br>><br>> commit f0432501b6e820b75aed8618fbfe4ce20f51680cAuthor: Marcus D.<br>> Hanwell <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>>Date:   Tue Dec 13 11:40:39 2011<br>

> -0500<br>>     ENH: Removed vtkstd:: from the wrapper generators        It isn't<br>> clear, but I suspect these lines could be removed entirely.    There<br>> is another wrapper file with some references that should likely<br>

> also be fixed.        Change-Id:<br>> Ibaaa36648f55da0d7c229d4cfd47f8705fb9e7a6<br>> diff --git a/Wrapping/vtkParseExtras.c<br>> b/Wrapping/vtkParseExtras.cindex 8223f25..e4b5603 100644---<br>> a/Wrapping/vtkParseExtras.c+++ b/Wrapping/vtkParseExtras.c@@ -683,7<br>

> +683,7 @@ size_t vtkParse_BasicTypeFromString(         m = 0;<br>> if (strncmp(cp, "::", 2) == 0) { m = 2; }         else if (strncmp(cp,<br>> "std::", 5) == 0) { m = 5; }-        else if (strncmp(cp, "vtkstd::",<br>

> 8) == 0) { m = 8; }+        else if (strncmp(cp, "std::", 8) == 0) { m<br>> = 8; }          /* advance past the namespace */         tmpcp = cp +<br>> m;diff --git a/Wrapping/vtkWrapPython.c<br>> b/Wrapping/vtkWrapPython.cindex 8d3f2c9..0eb6c2c 100644---<br>

> a/Wrapping/vtkWrapPython.c+++ b/Wrapping/vtkWrapPython.c@@ -366,7<br>> +366,7 @@ static size_t vtkWrapPython_PyTemplateName(const char *name,<br>> char *pname)   /* look for VTK types that become common python types<br>

> */   if ((n == 12 && strncmp(name, "vtkStdString", n) == 0) ||<br>> (n == 11 && strncmp(name, "std::string", n) == 0) ||-      (n == 14 &&<br>> strncmp(name, "vtkstd::string", n) == 0))+      (n == 14 &&<br>

> strncmp(name, "std::string", n) == 0))     {     strcpy(pname, "str");<br>>     return n;diff --git a/Wrapping/vtkWrapTcl.c<br>> b/Wrapping/vtkWrapTcl.cindex c5e80f1..e27efa0 100644---<br>> a/Wrapping/vtkWrapTcl.c+++ b/Wrapping/vtkWrapTcl.c@@ -1059,7 +1059,7<br>

> @@ void vtkParseOutput(FILE *fp, FileInfo *file_info)<br>> fprintf(fp,"#include \"%s.h\"\n\n",data->Name);   fprintf(fp,"#include<br>> \"vtkTclUtil.h\"\n");   fprintf(fp,"#include \"vtkStdString.h\"\n");-<br>

> fprintf(fp,"#include <vtkstd/stdexcept>\n");+  fprintf(fp,"#include<br>> <stdexcept>\n");   fprintf(fp,"#include <vtksys/ios/sstream>\n");   if<br>> (!data->IsAbstract)     {@@ -1452,7 +1452,7 @@ void<br>

> vtkParseOutput(FILE *fp, FileInfo *file_info)     }    fprintf(fp,"<br>> }\n");-  fprintf(fp,"  catch (vtkstd::exception &e)\n");+<br>> fprintf(fp,"  catch (std::exception &e)\n");   fprintf(fp,"    {\n");<br>

>  fprintf(fp,"    Tcl_AppendResult(interp, \"Uncaught exception: \",<br>> e.what(), \"\\n\", NULL);\n");   fprintf(fp,"    return<br>> TCL_ERROR;\n");<br>> On Tue, Dec 13, 2011 at 3:36 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>

>> Hi Marcus,<br>>><br>>> I'll take a look when I get home... port 81 is blocked by the firewall at work.<br>>><br>>>  - David<br>>><br>>><br>>> On Tue, Dec 13, 2011 at 10:04 AM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>

>>> They are part of the public API.<br>>>><br>>>> I noticed that Slicer4 uses them, but only in two file. Likewise the<br>>>> WikiExamples, but only in a couple of examples. In each case I'll<br>

>>> remove the vtkstd.<br>>>><br>>>> Your "remove legacy" approach with complete removal in VTK6 sounds good to me.<br>>>><br>>>><br>>>> On Tue, Dec 13, 2011 at 11:58 AM, Marcus D. Hanwell<br>

>>> <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>>>>> Yes, I thought I would need to do that, but not generate them at all<br>>>>> if remove legacy is on, and then perhaps remove them in for the 6.0<br>

>>>> release. I can make that change, please let me know if you see any<br>>>>> other problems.<br>>>>><br>>>>> It isn't clear if they are part of our public API, but as we installed<br>

>>>> them I guess they were.<br>>>>><br>>>>> Marcus<br>>>>><br>>>>> On Tue, Dec 13, 2011 at 11:55 AM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>

>>>>> I think you should keep the old headers around for backward<br>>>>>> compatibility. You could stick warning pragmas in the headers.<br>>>>>><br>>>>>> On Tue, Dec 13, 2011 at 11:49 AM, Marcus D. Hanwell<br>

>>>>> <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>>>>>>> Hi,<br>>>>>>><br>>>>>>> I just pushed a topic to reviewtest that removes vtkstd from VTK. For<br>

>>>>>> testing purposes I removed the generation of vtkstd altogether, but<br>>>>>>> that could be modified.<br>>>>>>><br>>>>>>> <a href="http://reviewtest.source.kitware.com:81/#/t/31/">http://reviewtest.source.kitware.com:81/#/t/31/</a><br>

>>>>>><br>>>>>>> This seems to compile for me, and was done largely using a Python<br>>>>>>> script and a little regex. Are there objections to me merging this<br>>>>>>> topic in? Should the vtkstd headers be generated for legacy purposes,<br>

>>>>>> I know at least ParaView (which I can fix) is using vtkstd in some<br>>>>>>> places.<br>>>>>>><br>>>>>>> I could also use some pointers from David Gobbi, as I suspect what I<br>

>>>>>> did to the wrapper code was not quite right.<br>>>>>>><br>>>>>>> Thanks,<br>>>>>>><br>>>>>>> Marcus<br>>>>>>> _______________________________________________<br>

>>>>>> Powered by <a href="http://www.kitware.com">www.kitware.com</a><br>>>>>>><br>>>>>>> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><br>

>>>>>><br>>>>>>> Follow this link to subscribe/unsubscribe:<br>>>>>>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>

>>>>>><br>>>>>><br>>>>>><br>>>>>><br>>>>>> --<br>>>>>> Unpaid intern in BillsBasement at noware dot com<br>>>><br>>>><br>

>>><br>>>> --<br>>>> Unpaid intern in BillsBasement at noware dot com<br>>>> _______________________________________________<br>>>> Powered by <a href="http://www.kitware.com">www.kitware.com</a><br>

>>><br>>>> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><br>>>><br>>>> Follow this link to subscribe/unsubscribe:<br>

>>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>>>><br>>> _______________________________________________<br>>> Powered by <a href="http://www.kitware.com">www.kitware.com</a><br>

>><br>>> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><br>>><br>>> Follow this link to subscribe/unsubscribe:<br>

>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>>><br><br>