But, it could segfault for have valgrind defects...  It is a form of testing to check for memory access and leaks.<br><br><div class="gmail_quote">On Thu, Sep 20, 2012 at 11:13 AM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This sounds reasonable to me, I would like to point out that being<br>
able to selectively pull symbols into the current namespace is a<br>
feature of namespaces, using std::cout to bring in a symbol you will<br>
use a lot is pretty common.<br>
<br>
We should be careful to use the new C++ headers consistently, and if<br>
we are going to relax this language then I still think that changing<br>
all occurrences to your preferred style should be discouraged in<br>
existing code (this will add noise to changes, and confuse functional<br>
changes over style changes), instead preferring the style currently<br>
used in that file.<br>
<br>
Even if the style is not applied everywhere we should still have an up<br>
to date style guide, and aim to stick with it automated tools or not.<br>
As a new contributor to a project that is one of the things I look<br>
for, or simply try to stick to the existing style in a given source<br>
file.<br>
<br>
My major objection to the patch that started all this was that whilst<br>
it increased coverage it did not actually verify any of the results<br>
and would always pass whether the output was correct or not (assuming<br>
it didn't segfault). I want to increase coverage, but would like to<br>
ensure that the tests will fail if someone breaks the code, and that<br>
is also why I am not sure I see the value in outputting lots of data<br>
(it appears I misunderstood duplicate CDash data, and that is far less<br>
of an issue than I thought it was).<br>
<span class="HOEnZb"><font color="#888888"><br>
Marcus<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Sep 19, 2012 at 5:44 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
> The only reason that VTK didn't use std:: historically was so that it<br>
> could support pre-standard or broken compilers.  The last badly broken<br>
> compiler we had to support was MSVC 2002.  But we don't support it<br>
> anymore, do we?<br>
><br>
> Therefore there is no longer any reason to avoid std::cout, and the<br>
> style guidelines should be amended.<br>
><br>
> So vtkstd:: has become std:: as of VTK 6<br>
> likewise std::cout should be preferred over cout<br>
> and std::string over vtkStdString.<br>
><br>
> I don't like to see style guidelines being broken (even in tests) so<br>
> the sooner the guidelines can be amended, the better.  Just remove the<br>
> sentence that insists on using "cout".  And please do not add a line<br>
> that insists on "std::cout".<br>
><br>
>  - David<br>
><br>
><br>
> On Wed, Sep 19, 2012 at 3:27 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>
>> Julien,<br>
>><br>
>> In the early days of VTK, at GE, coding style was a high priority. At that<br>
>> time we had a paid-for utility that enforced it. Later, before KWStyle, VTK<br>
>> stopped enforcing the style.<br>
>><br>
>> Someday, I hope, we can use KWStyle to bring the style back to what is used<br>
>> to be. But this will be a big effort. First to define the style via KWStyle,<br>
>> then to bring VTK into line with the style, and finally to maintain it.<br>
>><br>
>> BTW, I still feel that code coverage should be the high priority. But, every<br>
>> time we bring this up, people raise issues about process, style, output,<br>
>> etc.  I'd rather have code covered with tests that produce too much output,<br>
>> or use varying styles versus no test coverage at all.<br>
>><br>
>> Bill<br>
>><br>
>><br>
>><br>
>> On Wed, Sep 19, 2012 at 5:13 PM, Julien Finet <<a href="mailto:julien.finet@kitware.com">julien.finet@kitware.com</a>><br>
>> wrote:<br>
>>><br>
>>> Actually, the coding style should have been defined before (aka is the top<br>
>>> priority) the first unit test was written. And the latter should have been<br>
>>> written before the first code was written :-P<br>
>>> Defining/changing/applying coding style might be a good thing to do in VTK<br>
>>> 6.0 (higher priority) as it might change the API. Code coverage (and fixing<br>
>>> bugs) can always be done in succeeding minor versions.<br>
>>><br>
>>> Concerning your 2nd question (in your first email), if it comes to a vote,<br>
>>> I would vote in favor of always prefixing with the namespace of the external<br>
>>> library (here std::), as long as it is the standard namespace name (std::<br>
>>> and not vtkstd::). It can't hurt to be specific.<br>
>>><br>
>>> Julien.<br>
>>><br>
>>> On Wed, Sep 19, 2012 at 4:56 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> David,<br>
>>>><br>
>>>> There is not style checknig in VTK, nor is there an consistent style in<br>
>>>> VTK. Years ago we had a style and enforced through a third party package.<br>
>>>><br>
>>>> ITK enforces style with KWStyle and we have nightly tests that check the<br>
>>>> style.<br>
>>>><br>
>>>> To be honest, style is pretty low in priority versus code coverage and<br>
>>>> valgrind.<br>
>>>><br>
>>>> Bill<br>
>>>><br>
>>>><br>
>>>> On Wed, Sep 19, 2012 at 4:52 PM, David Thompson<br>
>>>> <<a href="mailto:david.thompson@kitware.com">david.thompson@kitware.com</a>> wrote:<br>
>>>>><br>
>>>>> I don't want to be so strict about formatting that we start using<br>
>>>>><br>
>>>>>   <a href="http://uncrustify.sourceforge.net/" target="_blank">http://uncrustify.sourceforge.net/</a><br>
>>>>><br>
>>>>> as another pass before commits can be pushed to Gerrit, but it would be<br>
>>>>> nice to have a "style file" for uncrustify (or a similar tool) that embodies<br>
>>>>> the VTK code style so less code review time is spent on formatting and more<br>
>>>>> on the logic, documentation, tests, and organization.<br>
>>>>><br>
>>>>>         David<br>
>>>>><br>
>>>>> On Sep 19, 2012, at 4:40 PM, "Marcus D. Hanwell"<br>
>>>>> <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
>>>>><br>
>>>>> > On Wed, Sep 19, 2012 at 4:06 PM, Bill Lorensen<br>
>>>>> > <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>
>>>>> >> Folks,<br>
>>>>> >><br>
>>>>> >> There has been some recent turmoil regarding the use of std::cout in<br>
>>>>> >> tests<br>
>>>>> >> versus cout. The current style guidelines recommend the latter.<br>
>>>>> >> First, why is this even an issue. Second, can we amend the style to<br>
>>>>> >> allow<br>
>>>>> >> std::cout? Much c++ code I see uses std::cout.<br>
>>>>> >><br>
>>>>> >> I'd much rather spend time improving VTK'sl ow coverage that argue<br>
>>>>> >> over what<br>
>>>>> >> seems to be a non-issue.<br>
>>>>> >><br>
>>>>> > I guess I was the source of the aforementioned turmoil. I think it is<br>
>>>>> > important to stick to a common style, and actively changing test code<br>
>>>>> > to not match the style seems bad to me. I don't see the point in fully<br>
>>>>> > specifying std::cout when we have brought it into the global<br>
>>>>> > namespace, but if there is a strong feeling we should then my point<br>
>>>>> > was simply that we should specify that is the preferred style from<br>
>>>>> > this point forward (or that either is acceptable).<br>
>>>>> ><br>
>>>>> > If we all start modifying the VTK coding standards then our code will<br>
>>>>> > be far less consistent, and harder to understand due to using several<br>
>>>>> > styles. If there is general agreement on relaxing some parts of the<br>
>>>>> > style I really don't feel very strongly, but I think it should be done<br>
>>>>> > deliberately rather than on an ad-hoc basis.<br>
>>>>> ><br>
>>>>> > Where would you draw the line if this should be relaxed? Could<br>
>>>>> > standard indentation be used instead of the special VTK indentation in<br>
>>>>> > classes I author? I am sure we don't want to allow that, but it does<br>
>>>>> > require some definition on what is strictly required and what is<br>
>>>>> > advised/optional.<br>
>>>>> ><br>
>>>>> > Marcus<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<br>
>>>>> > <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>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Unpaid intern in BillsBasement at noware dot com<br>
>>>><br>
>>>><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<br>
>>>> <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>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Unpaid intern in BillsBasement at noware dot com<br>
>><br>
>><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<br>
>> <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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Unpaid intern in BillsBasement at noware dot com<br><br>