[vtk-developers] warning for extra semicolon with vtkTypeMacro

[Andy Bauer]

My vote would be to do what Ken mentioned. I'm in favor of having the
semicolon required at the end of the macro statement but this will cause
compilation problems though for other projects that use the vtkTypeMacro
and did it the "proper" way before.


On Tue, May 6, 2014 at 3:08 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Tue, May 06, 2014 at 14:38:26 -0400, Utkarsh Ayachit wrote:
> > > Do we want
> > > vtkStandardNewMacro(vtkChartLegend);
> > > or
> > > vtkStandardNewMacro(vtkChartLegend)
> > > To me, the latter makes more sense...
>
> I prefer the former in general (so the macro looks like a regular call;
> but I also use all-upper for my macros when they're public so that
> there's some indication funky things are going on), but for
> block-generating code, leaving it out is sensible since blocks don't
> always end with semicolons.
>
> > I have always heard people prefer the latter, not entirely sure I know
> > why. The only problem I have with the latter is that it messes up with
> > my VIM indentation :). Does anyone know how to overcome that? I doubt
> > VIM can ever know that it's a macro and hence the missing ";" is not
> > really missing.
>
> If you're willing to live with constantly updating ctags and having them
> loaded all the time (I've found it's usually quite a problem for large
> projects :( ), it can know it's a macro. Personally, I have backspace
> dedent for me when Vim gets it wrong (which is often enough since the
> CMake indentation rules in Vim are far from ideal).
>
> --Ben
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140507/55035512/attachment-0002.html>