VTK has a verbose, self documenting style (for better or worse). I'd like to stick with it if possible.<br><br><br><div class="gmail_quote">On Wed, Jan 27, 2010 at 10:56 AM, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div class="im">On Wed, Jan 27, 2010 at 8:35 AM, Jeff Baumes <span dir="ltr"><<a href="mailto:jeff.baumes@kitware.com" target="_blank">jeff.baumes@kitware.com</a>></span> wrote:<br>

</div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Jan 26, 2010 at 12:44 PM, Marcus D. Hanwell<br>
<div><div></div><div><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>> wrote:<br>
> On Friday 08 January 2010 16:46:47 David Cole wrote:<br>
>> On Fri, Jan 8, 2010 at 4:08 PM, Marcus D. Hanwell <<br>
>><br>
>> <a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>> wrote:<br>
>> > I would like to add my -1, I think needing to split lines in order to<br>
>> > declare<br>
>> > a new local variable is a little much. I came from a C++ background where<br>
>> > any<br>
>> > object could be declared on the stack though. For things like the<br>
>> > examples it<br>
>> > seems to hurt readability to me.<br>
>> ><br>
>> > Pointer:<br>
>> > vtkFloatArray *myTable = vtkFloatArray::New();<br>
>> > myTable->Delete();<br>
>> > myTable = NULL;<br>
>> ><br>
>> > Smart pointer:<br>
>> > vtkSmartPointer<vtkFloatArray> myTable =<br>
>> >     vtkSmartPointer<vtkFloatArray>::New();<br>
>> ><br>
>> > Smart pointer with macro:<br>
>> > VTK_CREATE(vtkFloatArray, myTable);<br>
>> ><br>
>> > Stack:<br>
>> > vtkFloatArray myTable;<br>
>> ><br>
>> > I would prefer to be able to use something like the first or the last. In<br>
>> > classes etc it is often a different story. It seems like there should be<br>
>> > some<br>
>> > macro or template function to generate variables with less repetition.<br>
>><br>
>> Prefer the first and last as much as you want, but we simply can't use them<br>
>> in VTK. The first leads to memory leaks because people forget the Delete<br>
>> calls. The last cannot be done with vtkObject derived classes because of<br>
>>  the nature of vtkObject reference counting...<br>
>><br>
> Wasn't suggesting either (just pointing out the shorter syntax that people<br>
> miss), although the first is still widely used in VTK.<br>
><br>
>> So we have to pick one of the middle ones...<br>
>><br>
>> It's unfortunate that we've had two +1's and two -1's... that leaves us at<br>
>>  0 for the moment. I guess that and the fact that it's Friday makes it<br>
>>  fairly easy to put off a decision until at least next week. ;-)<br>
>><br>
>> *If* we do go with a macro-based approach, I think we can all agree there<br>
>> should be one centralized macro that does this and it should be used<br>
>> *everywhere* that vtkSmartPointer::New is presently used.<br>
><br>
> What about a vtkLocalPointer<vtkClass> myLocal; where the default constructor<br>
> makes an instance on the VTK class? It would also be possible to have a<br>
> constructor take an argument (may be a little clunkier) such as<br>
> vtkSmartPointer<vtkClass> myLocal(true); if we do not want to introduce yet<br>
> another class.<br>
><br>
> Alternate options a and b...<br>
><br>
> a) vtkLocalPointer<vtkClass> myLocal;<br>
> b) vtkSmartPointer<vtkClass> myLocal(true);<br>
><br>
> Would this be preferable to a macro? It seems like a better way to go to me,<br>
> and in terms of API and conciseness seems to satisfy our requirements better<br>
> than the current approach. It would still be possible to share the pointer<br>
> too, due to the reference counting in vtkObject derived classes.<br>
<br>
</div></div>I think option b is a good option. It seems that it would be odd to<br>
have two different pointer classes, where the only difference is what<br>
they do on construction.<br>
<br>
The biggest grudge I have about the current option is that it almost<br>
always requires a split line if you constrain yourself to 80<br>
characters. If your type name is more than about 15 characters (which<br>
many VTK types are), you have to split your line:<br>
<br>
vtkSmartPointer<type> name = vtkSmartPointer<type>::New();<br>
16 + t + 2 + n + 19 + t + 9 = 46 + 2*t + n<br>
<br>
Option b, even though not the most concise, would make it easy to stay<br>
within that limit, about halving the number of characters:<br>
<br>
vtkSmartPointer<type> name(true);<br>
16 + t + 2 + n + 7 = 25 + t + n<br>
<font color="#888888"><br>
Jeff<br>
</font></blockquote></div></div></div><div><br></div><br><div>Another solution worth considering is simply making a typedef called "vtkRendererSP" that is a typedef for "vtkSmartPointer<vtkRenderer>" -- that would allow you to:</div>


<div><br></div><div>vtkRendererSP renderer = vtkRendererSP::New();</div><div><br></div><div>It gives you the shorter names you're all longing for, without changing anything else already in VTK...</div><div><br></div>

<div>
<br></div><div>David C.</div><div><br></div>
<br>_______________________________________________<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>
<br></blockquote></div><br><br clear="all"><br>-- <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<br>
<input id="gwProxy" type="hidden"><input onclick="jsCall();" id="jsProxy" type="hidden"><div id="refHTML"></div>