[Insight-developers] ITK namespace delimiter discussion

[Lorensen, William E (CRD)]

I prefer not to redefine the C++ language if at all possible. Either 1 or 2 if fine with me.

Bill

-----Original Message-----
From: Will Schroeder [mailto:will.schroeder at kitware.com]
Sent: Monday, August 14, 2000 1:55 PM
To: Brad King; Insight Developers
Subject: Re: [Insight-developers] ITK namespace delimiter discussion


Hi Brad-

The spaces are important because the code is naturally longer with the 
template parameters, etc. I vote for #4 or if pushed #1.

Will

At 01:48 PM 8/14/00 -0400, Brad King wrote:
>After some discussion amongst a small group of us off the list, it has
>been decided that the ITK_NAMESPACE_BEGIN and ITK_NAMESPACE_END macros may
>not be a good idea.  The alternative we propose is to go back to the
>
>namespace itk
>{
>//...
>} // namespace itk
>
>approach, but indent everything inside the namespace by two extra spaces:
>
>namespace itk
>{
>   //...
>} // namespace itk
>
>This would leave the namespace's closing "}" as the only one in the
>left-most column, thus making it obvious.  It does, however, take all
>function opening "{" and closing "}" characters out of that column, and
>indent them two spaces.  It also reduces the number of characters per line
>by two before running over the 79 character guideline.
>
>Before I make any changes related to this, I'd like the list to reach a
>consensus on which way to go.  The choices that have been proposed are:
>
>// 1
>namespace itk
>{
>// old style, don't indent inside namespace
>// requires comment at end of namespace
>} // namespace itk
>
>// 2
>namespace itk
>{
>   // new style, indent namespace by 2 characters
>} // ending comment optional, only "}" in this column.
>
>// 3  (appropriate macros defined in header)
>ITK_NAMESPACE_BEGIN
>// no need to indent, no "{" characters appear.
>ITK_NAMESPACE_END
>
>// 4  (appropriate macros defined in header)
>BEGIN_NAMESPACE (itk)
>// no need to indent, no "{" characters appear.
>END_NAMESPACE (itk)
>
>Capitalization of macros is up for debate, of course.
>
>-Brad
>
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers


_______________________________________________
Insight-developers mailing list
Insight-developers at public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers