<div dir="ltr">Kyle to a large extent it's historical. Twenty years ago many things were brittle including compilers, STL, and wrapping. This led to a desire to keep things clean and simple. For example the wrapping process choked for a long time on fancy STL stuff. I also am of the opinion that the API to STL is, shall we say, poor plus it affects compilation time. We wanted to hide some of the nastiness from the wrapping process, from users, and encourage passing data through simpler exchange mechanisms. The PIMPL approach also hides the underlying implementation which provides more freedom if you want to change things up at a later time. I'm sure I'm forgetting a couple of other reasons, but Bill is in Santa Cruz for the month so I doubt he'll chip in ;-)<div>
<br>W</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 5:01 PM, Kyle Lutz <span dir="ltr"><<a href="mailto:kyle.lutz@kitware.com" target="_blank">kyle.lutz@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Mar 14, 2013 at 4:56 PM, Marcus D. Hanwell<br>
<div><div class="h5"><<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
> On Thu, Mar 14, 2013 at 4:36 PM, Kyle Lutz <<a href="mailto:kyle.lutz@kitware.com">kyle.lutz@kitware.com</a>> wrote:<br>
>> On Thu, Mar 14, 2013 at 11:36 AM, Marcus D. Hanwell<br>
>> <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
>>> Hi,<br>
>>><br>
>>> As we were linking to it from the commit guidelines page, I have also<br>
>>> taken the opportunity to update the coding standards page for VTK,<br>
>>><br>
>>> <a href="http://vtk.org/Wiki/VTK_Coding_Standards" target="_blank">http://vtk.org/Wiki/VTK_Coding_Standards</a><br>
>>><br>
>>> This is in line with my understanding of recent discussions, such as<br>
>>> improvements to wrapping allowing default arguments, using STL in API<br>
>>> outside of vtkCommon* modules being acceptable, moving toward using<br>
>>> std::string in API rather that vtkStdString. Comments welcome, or feel<br>
>>> free to edit/raise concerns here.<br>
>><br>
>> Is there any wiki page or public document explaining the rational<br>
>> behind these conventions?<br>
>><br>
>> To be more specific, I don't understand why we insist upon the following:<br>
>><br>
>> * "[the STL] should be used sparingly"<br>
>> * "STL use should use the PIMPL idiom"<br>
>> * "When using anything declared in iostream, do not use std::"<br>
>><br>
> On second look, two are the new bits but you really didn't give me<br>
> enough context... VTK has a lot of containers that are wrapped in<br>
> Python, Tcl, Java, API returning std::vector etc is not wrappable<br>
> hence the encouragement to use VTK containers where possible. When not<br>
> exposed in the API/useful for inheritance then sticking with the PIMPL<br>
> idiom makes sense as has always been the policy, the iostream bringing<br>
> cout etc into the global namespace has been there since for a very<br>
> long time (since before the STL implementations were stable and is not<br>
> a new policy.<br>
><br>
> As I said before it would be better to debate these in specific<br>
> threads, along with your reasoning as to why the point you are<br>
> questioning should be changed. VTK has traditionally kept virtually<br>
> all STL out of its API, used object factories globally, only allows<br>
> heap allocation, ...<br>
><br>
> I would raise these for discussion in separate threads if you want to<br>
> push for some of these things to be changed. Allowing use of STL in<br>
> API at all is new, and has not been exposed in many places yet. I<br>
> promised to do it in a few of the charts classes to make inheritance<br>
> and modification easier for example but haven't gotten to it yet.<br>
<br>
</div></div>I think you may have misinterpreted my post. I have no desire to<br>
change any of the VTK coding standards. I was merely curious as to the<br>
"why" behind some of them.<br>
<span class="HOEnZb"><font color="#888888"><br>
-kyle<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">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" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>William J. Schroeder, PhD<br>Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
<a href="http://www.kitware.com">http://www.kitware.com</a><br>(518) 881-4902
</div>