Le 08/10/11 22:46, Jeffrey Lee Hellrung, Jr. a écrit :

On Sat, Oct 8, 2011 at 1:34 PM, Beman Dawes<bdawes@acm.org> wrote:

...

Since Boost already has BOOST_NO_NOEXCEPT and at least one compiler (GCC) supports C++11 noexcept, I'd like to start using it in Boost code.

So how about a<boost/detail/noexcept.hpp> header with the usual boilerplate and this:

#ifndef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_IF(Predicate) #else # define BOOST_NOEXCEPT no_except # define BOOST_NOEXCEPT_IF(Predicate) no_except(Predicate) #endif

As was pointed out in a previous thread, there isn't any reliable C++03 alternative for either of these two, so nothing is attempted, and that's OK in C++03 code.

We could also define BOOST_NOEXCEPT_OPERATOR(Predicate), and have it fall back to true in C++03 code. I'm not expert enough to know if that is reliable or even useful, so am not proposing it.

Comments?

No substantive comments at the moment, I just want to check spelling: "noexcept" or "no_except"? I had thought it was the former; your macro definitions suggest the latter.

Good idea. I would prefer if these macros are added to Boost.Config, documented and in file boost/config/suffix.hpp. Yes, the macros should be # define BOOST_NOEXCEPT noexcept # define BOOST_NOEXCEPT_IF(Predicate) noexcept(Predicate) Could you provide a patch? Best, Vicente

On Sun, Oct 9, 2011 at 4:09 AM, John Maddock <boost.regex@virgin.net> wrote:

...

Good idea. I would prefer if these macros are added to Boost.Config, documented and in file boost/config/suffix.hpp.

That would be my idea too: add them to config/suffix.hpp and document them as part of Boost.Config's "Helper macros".

Done. See trunk/libs/config/doc/html/boost_config/boost_macro_reference.html I took the liberty of starting a new section: "Macros that allow use of C++11 features with C++03 compilers" --Beman

On Mon, Oct 10, 2011 at 11:42 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:

...

See trunk/libs/config/doc/html/boost_config/boost_macro_reference.html

I took the liberty of starting a new section: "Macros that allow use of C++11 features with C++03 compilers"

Hi,

Please, don't forget to move the BOOST_CONSTEXPR, ..., BOOST_STATIC_CONSTEXPR macros to this new section, if not already done.

Yes, that did get done. --Beman

On Mon, Oct 10, 2011 at 5:46 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:

Then maybe at one go add BOOST_OVERRIDE and BOOST_FINAL? (note that MSVC supports them since VS 2005 but uses sealed rather than final, making the macros even more desirable for better portability).

Care to submit patches? --Beman

On Mon, Oct 10, 2011 at 11:59 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:

...

...

Then maybe at one go add BOOST_OVERRIDE and BOOST_FINAL? (note that MSVC supports them since VS 2005 but uses sealed rather than final, making

From: Beman Dawes the

...

macros even more desirable for better portability).

Care to submit patches?

OK, but one thing is unclear to me. Along with BOOST_OVERRIDE and BOOST_FINAL, the corresponding BOOST_NO_<feature> macro(s) should be provided. There are several possibilities: - provide BOOST_NO_VIRT_SPECIFIERS, - provide BOOST_NO_OVERRIDE_FINAL (or BOOST_NO_OVERRIDE_FINAL_VIRT_SPECIFIERS), - provide BOOST_NO_OVERRIDE and BOOST_NO_FINAL (or BOOST_NO_OVERRIDE_VIRT_SPECIFIER and BOOST_NO_FINAL_VIRT_SPECIFIER).

BOOST_NO_VIRT_SPECIFIERS has the problem that if a future C++ revision adds more specifiers (i.e., explicit/new) then the meaning will become ambiguous. BOOST_NO_OVERRIDE_FINAL is better in this respect, but it has another problem that applies to BOOST_NO_VIRT_SPECIFIERS as well: currently there are compilers (MSVC >= 8.0) supporting override but not final (they use sealed keyword instead). On the other hand, BOOST_NO_OVERRIDE and BOOST_NO_FINAL may be a bit too fine-grained. What do you and the others think?

There is another issue I should have mentioned earlier: Do these features actually impact any Boost code? We don't want to waste people's time working on config support that isn't going to be used. To answer your question, BOOST_NO_OVERRIDE and BOOST_NO_FINAL may be fine grained, but they make life easier if some compiler implements one but not the other. --Beman

on Wed Oct 12 2011, Robert Kawulak <robert.kawulak-AT-gmail.com> wrote:

...

From: Beman Dawes There is another issue I should have mentioned earlier: Do these features actually impact any Boost code? We don't want to waste people's time working on config support that isn't going to be used.

I don't know if I know the answer in general. I believe it does not apply to any current Boost code, but it's a generally useful feature, so it may benefit Boost code as well as users' code. And as I said, it not only provides portability between C++11 and C++03 compilers, but also between C++11 and MSVC. If others find it useful, I may make all the needed changes.

We're not talking about BOOST_NOEXCEPT anymore, though, right? Because I believe that does/could easily apply to current Boost code. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On Sat, Oct 8, 2011 at 9:20 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:

Good idea. I would prefer if these macros are added to Boost.Config, documented and in file boost/config/suffix.hpp.

Will do.

...

Could you provide a patch?

Committed to trunk. Thanks, --Beman

On Sat, Oct 8, 2011 at 9:11 PM, Dave Abrahams <dave@boostpro.com> wrote:

...

We could also define BOOST_NOEXCEPT_OPERATOR(Predicate), and have it fall back to true in C++03 code. I'm not expert enough to know if that is reliable or even useful, so am not proposing it.

I think it had better default to false; that would be the conservative answer.

Grrr... Double negative confusion strikes again. My mistake. It should be false. Fixed.

And the parameter is "Expression," I think.

Yes, that would be better.

I suggest BOOST_IS_NOEXCEPT(Expression)

I settled on BOOST_NOEXCEPT_EXPR(Expression). Thanks, --Beman

On Mon, Oct 10, 2011 at 4:52 AM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:

Didn't find that thread so I apologize if it was already discussed

See http://lists.boost.org/Archives/boost/2011/02/177284.php and replies.

couldn't you add compiler specific versions [e.g. __declspec( nothrow ), __attribute(( nothrow ))...] for the non predicate/expression version?

That thread discussed the possibility of the C++03 version using throw() for MSVC and __attribute__((nothrow)) for GCC. The uses I'm making of it are for cases where there is nothing in the current code, and the docs say "Throws: Nothing". I guess we could provide yet another form that handled the BOOST_NOEXCEPT_OR_EMPTY_THROWS case, but I'm not greatly interested in working that one out. If someone else wants to take that on, fine. Hopefully a shorter name could be found. Maybe BOOST_NEVER_THROWS. --Beman

On Tue, Oct 11, 2011 at 5:42 AM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:

On 10.10.2011. 17:55, Beman Dawes wrote:

...

On Mon, Oct 10, 2011 at 4:52 AM, Domagoj Saric <domagoj.saric@littleendian.com>  wrote:

...

Didn't find that thread so I apologize if it was already discussed

See http://lists.boost.org/Archives/boost/2011/02/177284.php and replies.

...

couldn't you add compiler specific versions [e.g. __declspec( nothrow ), __attribute(( nothrow ))...] for the non predicate/expression version?

That thread discussed the possibility of the C++03 version using throw() for MSVC and __attribute__((nothrow)) for GCC.

The uses I'm making of it are for cases where there is nothing in the current code, and the docs say "Throws: Nothing".

I guess we could provide yet another form that handled the BOOST_NOEXCEPT_OR_EMPTY_THROWS case, but I'm not greatly interested in working that one out. If someone else wants to take that on, fine. Hopefully a shorter name could be found. Maybe BOOST_NEVER_THROWS.

I found that thread but it didn't actually mention/discuss any problems with the compiler specific replacements so I thought you meant some other thread...

Here is the brief exchange I was referring too:

Alexander Fokin: I believe it's not that simple.

As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)).

Correct me if I'm wrong.

Dave Abrahams:

You're right. In general, throw() has runtime semantics and can produce runtime overhead in the form of increased executable size and occasionally reduced speed. ...

Continuing my reply to Domagoj,

I must I don't understand why would using the mentioned compiler specifics require a different macro? AFAICT these are just different keywords that say the same thing to the compiler and the user (unless someone is actually worried by the fact that MSVC will not call std::unexpected/terminate in case you violate the promise you made about the function in question?)

Good question. There are two cases: (1) For C++03 compilers, the macro user wants the mentioned compiler specifics. That's the case an additional macro is needed for. (2) For C++03 compilers, the macro user wants nothing inserted. That's the case covered by the macros I've added to trunk. This case arises because a lot of existing code isn't decorated with either throw() or a compiler specific attribute, and the user doesn't want to add that now. In applying noexcept to the standard library, this was by far the most common situation encountered - there was no existing exception specification. Note that cases (1) and (2) may be interleaved in the same translation unit, so using a config macro to specify the behavior won't work well, and isn't a preferred approach anyhow. --Beman

On 11.10.2011. 13:54, Beman Dawes wrote:

On Tue, Oct 11, 2011 at 5:42 AM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:

...

I must I don't understand why would using the mentioned compiler specifics require a different macro? AFAICT these are just different keywords that say the same thing to the compiler and the user (unless someone is actually worried by the fact that MSVC will not call std::unexpected/terminate in case you violate the promise you made about the function in question?)

Good question. There are two cases:

(1) For C++03 compilers, the macro user wants the mentioned compiler specifics. That's the case an additional macro is needed for.

(2) For C++03 compilers, the macro user wants nothing inserted. That's the case covered by the macros I've added to trunk. This case arises because a lot of existing code isn't decorated with either throw() or a compiler specific attribute, and the user doesn't want to add that now. In applying noexcept to the standard library, this was by far the most common situation encountered - there was no existing exception specification.

Note that cases (1) and (2) may be interleaved in the same translation unit, so using a config macro to specify the behavior won't work well, and isn't a preferred approach anyhow.

I must say I still don't see why (1) would require an additional macro because I don't see why (2) would be required/wanted at all..? IOW why would someone want noexcept but not __attribute__(( nothrow ))? ps. except, as said previously, if there is a real world person/problem that depends on the defined std::unexpected/std::terminate behaviour of noexcept as opposed to undefined or implementation defined behaviour of a compiler specific in case "someone violates a promise given about the particular function"... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

On 19.10.2011. 17:47, Stewart, Robert wrote:

Using (1) on existing code could change behavior.

Again, how could it change behaviour? Unless, again,: "...there is a real world person/problem that depends on the defined std::unexpected/std::terminate behaviour of noexcept as opposed to undefined or implementation defined behaviour of a compiler specific in case "someone violates a promise given about the particular function"..." -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

Den 20-10-2011 15:15, Stewart, Robert skrev:

Domagoj Saric wrote:

...

On 19.10.2011. 17:47, Stewart, Robert wrote:

...

Using (1) on existing code could change behavior.

Again, how could it change behaviour? Unless, again,: "...there is a real world person/problem that depends on the defined std::unexpected/std::terminate behaviour of noexcept as opposed to undefined or implementation defined behaviour of a compiler specific in case "someone violates a promise given about the particular function"..."

State it however you might like, but telling a compiler that a function no longer emits any exceptions can mean changes in optimization, insertion of validation logic, etc., which can *change behavior*.

If the question is: "If a function in boost is documented and guaranteed to throw no exception, can adding an attribute that is (a) non-detectable by the programmer and (b) which does not affect the signature of the function or a pointer to the function change the /observed behavior/ of the program? then would the answer not always be "no" -Thorsten

Domagoj Saricj wrote:

On 20.10.2011. 15:15, Stewart, Robert wrote:

...

Domagoj Saric wrote:

...

On 19.10.2011. 17:47, Stewart, Robert wrote:

...

Using (1) on existing code could change behavior.

Again, how could it change behaviour? Unless, again,: "...there is a real world person/problem that depends on the defined std::unexpected/std::terminate behaviour of noexcept as opposed to undefined or implementation defined behaviour of a compiler specific in case "someone violates a promise given about the particular function"..."

State it however you might like, but telling a compiler that a function no longer emits any exceptions can mean changes in optimization, insertion of validation logic, etc., which can *change behavior*.

AFAIK optimization is not allowed to manifest any change in behaviour, and the addition of noexcept already by itself changes/inserts "validation logic" so I still don't see what difference does that make?

Let me try it this way. With (1), we get the following before and after for C++03: before: void f(); after: void f() compiler-specific-nothrow; For C++11, (1) inserts noexcept, which was the reason for introducing it. Because the addition of the compiler-specific-nothrow decoration implies lost optimization opportunities and the addition of validation logic, it can affect client code in undesirable ways. The better option makes no change in C++03 code, which means no chance for undesirable changes. It may well be useful to have a macro which inserts the compiler-specific-nothrow decoration for C++03 code and noexcept for C++11 code, but that's another macro. (You might argue the naming, if both are available, of course.) _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Dave Abrahams wrote:

on Fri Oct 28 2011, "Stewart, Robert" <Robert.Stewart-AT- sig.com> wrote:

...

Because the addition of the compiler-specific-nothrow decoration implies lost optimization opportunities and the addition of validation logic, it can affect client code in undesirable ways.

Rob, I don't know what you mean by "lost optimization opportunities and the addition of validation logic." The only compiler-specific behaviors I know of do the exact opposite: they add optimization opportunities and remove validation logic.

Code that is known not to throw exceptions can enable optimizations, but marking a function as non-throwing implies the need to call std::unexpected() which, in turn, implies the need for a function try block (or equivalent). That's the "validation logic" to which I referred. That extra validation logic can reduce optimization opportunities, unless I'm much mistaken. For example, such a function cannot be inlined, or at least is much less likely to be inlined, because of the try block. (The function try block could be changed into a normal try block around the inlined function body.) Try blocks can reduce chances for optimization.

Code can use the noexcept operator to detect noexcept-ness of expressions at compile-time and do something semantically different... but it shouldn't. Normally, noexcept should only be used for optimization.

Do note that we're discussing the effects on C++03 code in this context. The change is from no exception specification to throw() or its compiler-specific equivalent. What have I misunderstood? _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Peter Dimov wrote:

Stewart, Robert wrote:

...

Do note that we're discussing the effects on C++03 code in this context. The change is from no exception specification to throw() or its compiler-specific equivalent.

What have I misunderstood?

Compiler-specific nothrow decorations don't call std::unexpected and don't insert try blocks.

Well that's an important difference. In that case, it does seem reasonable that BOOST_NOEXCEPT could insert the compiler-specific decorations without adverse effect on existing C++03 code. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.