Hello, the issue with extra semicolons at namespace or class scope is surely nothing new and has been discussed extensively. 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). 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. What is your opinion on this, please? Regards, Boris
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. B) involves something that is either clever, or a bletcherous hack, or both. I've found that things like: namespace empty_namespace_for_semicolons { void allow_semicolon(); } #define ALLOW_SEMICOLON1 \ typedef int semicolon_allowed_after_this_typedef #define ALLOW_SEMICOLON2 \ namespace only_for_semicolon=empty_namespace_for_semicolons #define ALLOW_SEMICOLON3 \ using empty_namespace_for_semicolons::allow_semicolon do the trick; these were suggested by people on this list. You'd then do something like #define PTR_CONTAINER_DEFINE_CONSTRUCTORS(a,b) \ BOOST_PTR_CONTAINER_DEFINE_CONSTRUCTORS( a,b ) ALLOW_SEMICOLON1 And, finally, write your code like this: PTR_CONTAINER_DEFINE_CONSTRUCTORS( ptr_map_adapter_base, base_type ); Clever? Or bletcherous hack? I think both. :-) ------------------------------------------------------------------------ Dave Steffen, Ph.D. On a paper submitted by a physicist colleague: Software Engineer IV Numerica Corporation "This isn't right. This isn't even wrong." ph (970) 419-8343 x27 fax (970) 223-6797 -- Wolfgang Pauli dgsteffen@numerica.us ______________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
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
Oliver Kullmann writes:
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... [...] 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.
Right, that's the whole point of the discussion. This isn't GCC being too picky or anything like that. GCC 3.4 is correct; that semicolon _really_ isn't allowed there. Seriously. No kidding. We mean it. :-)
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.
Well, we've had that discussion. Until some emacs lisp experts get involved, a lot of people will have issues. :-) What I've done - and this was the solution I posted earlier - was come up with a (clever, ugly) hack that allows the semicolon. That is, you put something clever at the end of the macro definition that requires a following semicolon but doesn't do anything else. Then you can A) put semicolons after macros where you (and your text editor) want them, and B) adhere to the standard and keep GCC happy. No emacs hacking needed. ------------------------------------------------------------------------ Dave Steffen, Ph.D. On a paper submitted by a physicist colleague: Software Engineer IV Numerica Corporation "This isn't right. This isn't even wrong." ph (970) 419-8343 x27 fax (970) 223-6797 -- Wolfgang Pauli dgsteffen@numerica.us ______________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
Hello,
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.
[SNIP]
On the other hand, having erroneous code in a library doesn't seem an option to me, even if most compilers ignore it.
Unfortunately there is no clear solution to the issue that would satisfy everyone. Though I completely agree with your opinion that the libraries should favor the language definition conformance over user comfort in text editors. IOW, broken syntax coloring or source parsing in editor is a less serious issue compared to the inability to use the library in strict compiling environment. Note that I understand the problems semicolons are causing with text editors and code formatters. The editors we use at work suffer the same. But still, we are more than willing to sacrifice a little bit of that comfort in favor of being able to use e.g. ptr_containers without patching its sources with every new Boost release. But this is just an user opinion, it all depends on how the responsible people regard this issue. Boris
Oliver Kullmann writes:
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... [...] 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.
Right, that's the whole point of the discussion. This isn't GCC being too picky or anything like that. GCC 3.4 is correct; that semicolon _really_ isn't allowed there. Seriously. No kidding. We mean it. :-)
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.
Well, we've had that discussion. Until some emacs lisp experts get involved, a lot of people will have issues. :-) What I've done - and this was the solution I posted earlier - was come up with a (clever, ugly) hack that allows the semicolon. That is, you put something clever at the end of the macro definition that requires a following semicolon but doesn't do anything else. Then you can A) put semicolons after macros where you (and your text editor) want them, and B) adhere to the standard and keep GCC happy. No emacs hacking needed. ------------------------------------------------------------------------ Dave Steffen, Ph.D. On a paper submitted by a physicist colleague: Software Engineer IV Numerica Corporation "This isn't right. This isn't even wrong." ph (970) 419-8343 x27 fax (970) 223-6797 -- Wolfgang Pauli dgsteffen@numerica.us ______________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.
participants (1)
-
Boris Burger -
Dave Steffen -
Oliver Kullmann -
Thorsten Ottosen