<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>