Re: [boost] [ptr_container] Semicolons after macros

From: Oliver Kullmann (O.Kullmann_at_[hidden])
Date: 2005-11-11 11:40:02

On Fri, Nov 11, 2005 at 08:59:56AM -0700, Dave Steffen wrote:
> Boris Burger writes:
>  > Hello,
>  > the issue with extra semicolons at namespace or class scope is
>  > surely nothing new and has been discussed extensively.
> 
>  Yes, I was one of the instigators...
> 
>  > Still, I am not able to handle its incarnation in ptr_container 
>  > sources, with G++ 3.4.5 (-ansi -pedantic). It goes like this:
>  > 
>  > In ptr_map_adapter.hpp (and elsewhere), definition of class template 
>  > ptr_map_adapter_base contains:
>  > 
>  >         BOOST_PTR_CONTAINER_DEFINE_CONSTRUCTORS(
>  >                 ptr_map_adapter_base, base_type );
>  > 
>  > at class scope. G++ 3.4.5 reports the extra semicolon as
>  > an error (-ansi -pedantic warning level is rather strict here).
> 
>  ... because I was porting our code to GCC 3.4.  (More accurately, I
>  was porting our code to 3.4 with the errors and warnings turned all
>  the way up.)
> 
>  > Due to our company's policy lowering the warning levels is not an
>  > option. Patching the ptr_container classes would do the trick
>  > but that would require rather painful process of going through 
>  > the Boost sources with each new version and removing extra
>  > semicolons. 
> 
>  In fact, I don't think there's a way to lower warning levels to
>  _just_ get rid of the semicolon complaints; you'd also be turning off
>  warnings you want.  The only solution I found was to either
> 
> 	  A) remove the semicolon, or
> 	  B) to use a macro definition
> 
>  A) is easiest, but may make people's editors unhappy.
>

Hi,

I was following the first investigations some time ago not very closely,
but I didn't realise (until lately) that removing the semicolon at namespace
scope is actually required by the language definition. So I think there is
no way out: If there is a conflict between text editor and language definition,
then the text editor must retreat.

As I said, it was only recently that I got aware of this, and I just cleaned up
my library, and that's it. I use XEmacs, and the little problem here is, that
on the next line the automatic indentation does not work correctly, but one has
just for this one line to fix the indentation, and then it works again, so I think
this is really a minor issue.

On the other hand, having erroneous code in a library doesn't seem an option to me,
even if most compilers ignore it.

Oliver