- Boost - lists.boost.org

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Ruben Perez 11 Apr '23

11 Apr '23

On Mon, 10 Apr 2023 at 16:37, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. I have successfully built the libraries under clang-15, on Ubuntu 22.04. I can confirm that there are no problems building Boost.MySQL examples. Regards, Ruben.

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Tom Kent 10 Apr '23

10 Apr '23

On Mon, Apr 10, 2023 at 9:36 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ < > https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile > failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. > > > The SHA256 checksums are as follows: > > 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c > boost_1_82_0_rc2.tar.gz > f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 > boost_1_82_0_rc2.zip > a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 > boost_1_82_0_rc2.tar.bz2 > e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 > boost_1_82_0_rc2.7z > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release managers > Looks good for Windows/Visual Studio. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full log here: https://gist.github.com/teeks99/3ffee2d9d3b93ec996f47ad7c38f64c1 Tom

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Matt Borland 10 Apr '23

10 Apr '23

> > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release managers > > I have successfully built the libraries using Homebrew Clang 16.0.1 on an M1 Mac running macOS Ventura 13.3.1. Matt

1 0

Re: [boost] [release] Boost 1.82.0 Release Candidate 2 is available
by Marshall Clow 10 Apr '23

10 Apr '23

On Apr 10, 2023, at 7:36 AM, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The second release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> > > There is only one change from RC1 - a fix to ASIO that caused some compile failures. > Thanks to Ruben Perez for the report, and to Chris for the fix. > > > The SHA256 checksums are as follows: > > 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz > f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip > a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 > e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. I have successfully built the libraries in Mac OS 12.6.4, with "Apple clang version 14.0.0 (clang-1400.0.29.202)” and C++ 03/11/14/17/20/2b, on both x86 and ARM. — Marshall

1 0

[release] Boost 1.82.0 Release Candidate 2 is available
by Marshall Clow 10 Apr '23

10 Apr '23

The second release candidates for the 1.82.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/ <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/>> There is only one change from RC1 - a fix to ASIO that caused some compile failures. Thanks to Ruben Perez for the report, and to Chris for the fix. The SHA256 checksums are as follows: 66a469b6e608a51f8347236f4912e27dc5c60c60d7d53ae9bfe4683316c6f04c boost_1_82_0_rc2.tar.gz f7c9e28d242abcd7a2c1b962039fcdd463ca149d1883c3a950bbcc0ce6f7c6d9 boost_1_82_0_rc2.zip a6e1ab9b0860e6a2881dd7b21fe9f737a095e5f33a3a874afc6a345228597ee6 boost_1_82_0_rc2.tar.bz2 e72ff100482d4b371327b6c550dbd244d49c0186860ccc3b8c093dd621537e39 boost_1_82_0_rc2.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

1 0

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 09 Apr '23

09 Apr '23

niedz., 9 kwi 2023 o 00:28 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/7/23 18:42, Andrey Semashev wrote: > > On 4/7/23 15:55, Andrzej Krzemienski wrote: > >> czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost > >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> napisał(a): > >> > >> Thus I > >> wouldn't say scope_success/scope_fail are unimplementable - they > clearly > >> are - but that they are incompatible with coroutines. That is, these > >> scope guards will work as expected as long as you don't switch > >> coroutines within the guarded scope. > >> > >> Maybe this is just a question of the choice of words. > >> But the docs do not present the situation in this way. > >> > >> "Although it is possible to specify arbitrary condition function > >> objects, typically |scope_success > >> < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > invokes its action when the scope is left normally (i.e. not via an > exception) and |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > should typically be used to handle errors, including exceptions." > >> > >> This guarantee (when scope is exited not normally) cannot be satisfied > >> in general. One cannot use it in a coroutine: directly or indirectly. > >> One might not even know the context. > >> > >> "By default, |scope_success > >> < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > will invoke its action if it is destroyed normally, |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > - if it is destroyed due to an exception being thrown." > > > > Note the "typically". :) In this documentation I tried to describe these > > facilities in more or less simple language, describing the most typical > > use cases. For this simplicity, I had to omit some formalities and > > corner cases that would detract the reader from the main purpose and > > intended use case of the components. Perhaps, I should improve the > > wording, but I would still like the docs to be easily readable. > > > > And, as I admitted earlier, I completely forgot about coroutines. I will > > add a note about coroutenes in relation to the default failure condition > > used by scope_success/scope_fail. > > > >> (BTW, The synopsis in > >> > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > > > >> does not indicate that there is any default Cond.) > > > > Hmm, for some reason Doxygen removed the default template arguments for > > scope_success/scope_fail. I'll see if I can fix this. Thanks for > noticing. > > I have updated the docs to fix those issues and added the note re. > coroutines. I've also improved wording so that the general discussion > does not focus on exceptions as much but rather failure and non-failure > conditions. > Thanks. Well, in my experience, the scope fail/success is exclusively about exceptions, so I will still focus on exceptions. Here is a small benchmark comparing the deactivation-based mechanism of a scope_guard with uncaught_exception-based mechanism of scope_fail. The former performed like 36 times faster, as it doesn't have to perform the calls to the runtime. Regarding failure conditions other than exceptions, the problem with coroutines may still appear if a thread-local storage is used, such as errno. Regards, &rzej; > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 2

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 08 Apr '23

08 Apr '23

czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote: > > Hi Everyone, > > It is my understanding that the reason scope_fail was left to die in the > > C++ Extensions for Library Fundamentals v3 was that it is not > > implementable. > > I'm not sure what you mean in the "left to die" part. Do you mean that > these facilities are being deprecated? > There are two motivations for putting something into a TS. One is to encourage vendors to implement the feature and gather usage and deployment experience. The other is to postpone the addition of the feature or to politely say that it is not wanted in the Standard. I *believe* this is the case with the subset of scope guards. I have seen no movement towards moving scope_fail into the Standard. and not moving them into the standard in reality means abandoning them. > > > One cannot detect if the scope is being left due to an > > exception thrown from within the scope. Observing the number of uncaught > > exceptions in the constructor and in the destructor will not work, given > > that we now have coroutines that can be suspended and then resumed in > > another thread (with a different number of uncaught exceptions), or even > in > > the same thread but at some later point, when the number of uncaught > > exceptions has changed. > > > > The enclosed example illustrates how a scope_fail fails to call the > > callback when an exception is thrown from a coroutine. It uses Lewis > > Baker's CppCoro implementation of a generator. > > > > The only reliable way to call a callback when the scope is left due to an > > exception is through using the explicit call to `deactivate()` function. > It > > is more verbose, but reliable. > > I must say I have no experience with coroutines, but my understanding is > that they are basically incompatible with any mechanism that relies on > thread-specific state, including the uncaught exceptions counter. Indeed. Note that the example I provided uses just one thread. The problem is the suspension itself. > Thus I > wouldn't say scope_success/scope_fail are unimplementable - they clearly > are - but that they are incompatible with coroutines. That is, these > scope guards will work as expected as long as you don't switch > coroutines within the guarded scope. > Maybe this is just a question of the choice of words. But the docs do not present the situation in this way. "Although it is possible to specify arbitrary condition function objects, typically scope_success <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…> invokes its action when the scope is left normally (i.e. not via an exception) and scope_fail <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…> should typically be used to handle errors, including exceptions." This guarantee (when scope is exited not normally) cannot be satisfied in general. One cannot use it in a coroutine: directly or indirectly. One might not even know the context. "By default, scope_success <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…> will invoke its action if it is destroyed normally, scope_fail <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…> - if it is destroyed due to an exception being thrown." (BTW, The synopsis in https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… does not indicate that there is any default Cond.) This is not true when a scope guard is used across coroutine suspensions: by default [...] scope_fail is not destroyed due to exception being thrown. The reality is, it is destroyed based on the comparison of two measurements of the number of uncaught exceptions, potentially measured in different threads. > I admit this is a notable limitation, and I will document it. But I do > not consider this limitation fatal, as there is plenty code out there > that doesn't use coroutines - I'd even say, much more code than that does. > This is one way of looking at it: that the problem is rare. A different way is to say that if something works in 99% of the cases and fails only in 1%, we have a dangerous situation, as we are unprepared when the 1% case happens. > Also, I forgot to mention that Boost.Scope's scope_success/scope_fail > support custom failure predicates which may not rely on the exception > state at all. Can it be used to fix the coroutine case? (That is to detect that the scope is left due to an exception being thrown?) Regards, &rzej;

2 2

Re: [boost] [scope] scope_fail is unimplementable
by Andrzej Krzemienski 07 Apr '23

07 Apr '23

pt., 7 kwi 2023 o 17:43 Andrey Semashev via Boost <boost(a)lists.boost.org> napisał(a): > On 4/7/23 15:55, Andrzej Krzemienski wrote: > > > > > > czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost > > <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> napisał(a): > > > > On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote: > > > Hi Everyone, > > > It is my understanding that the reason scope_fail was left to die > > in the > > > C++ Extensions for Library Fundamentals v3 was that it is not > > > implementable. > > > > I'm not sure what you mean in the "left to die" part. Do you mean > that > > these facilities are being deprecated? > > > > There are two motivations for putting something into a TS. One is to > > encourage vendors to implement the feature and gather usage and > > deployment experience. The other is to postpone the addition of the > > feature or to politely say that it is not wanted in the Standard. I > > *believe* this is the case with the subset of scope guards. I have seen > > no movement towards moving scope_fail into the Standard. and not moving > > them into the standard in reality means abandoning them. > > My understanding is that the TS exist to gather practical usage > experience in real world with the components before including (or not > including) them into the main standard. In fact, this very thread is a > piece of this real world feedback. I see no point in including something > into a TS only to abandon it afterwards. That said, I have no close > knowledge of the standard committee processes and may be wrong. > > In any case, the problem you highlighted may well be a reason for > reluctance to include scope_success/scope_fail into the standard, at > least not with the current wording that is given in the TS. But I think > the components can be defined differently, with coroutines in mind. That > new definition would not use uncaught_exceptions() as a criteria for > detecting failure but some other, possibly "implementation-defined" or > otherwise undisclosed mechanism that allows to implement the correct > semantics wrt. coroutines. > That would be nice. > > > I must say I have no experience with coroutines, but my > understanding is > > that they are basically incompatible with any mechanism that relies > on > > thread-specific state, including the uncaught exceptions counter. > > > > Indeed. Note that the example I provided uses just one thread. The > > problem is the suspension itself. > > The problem is that the uncaught exceptions counter does not correspond > to the current coroutine, but to the current thread. > > > Thus I > > wouldn't say scope_success/scope_fail are unimplementable - they > clearly > > are - but that they are incompatible with coroutines. That is, these > > scope guards will work as expected as long as you don't switch > > coroutines within the guarded scope. > > > > Maybe this is just a question of the choice of words. > > But the docs do not present the situation in this way. > > > > "Although it is possible to specify arbitrary condition function > > objects, typically |scope_success > > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > invokes its action when the scope is left normally (i.e. not via an > exception) and |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > should typically be used to handle errors, including exceptions." > > > > This guarantee (when scope is exited not normally) cannot be satisfied > > in general. One cannot use it in a coroutine: directly or indirectly. > > One might not even know the context. > > > > "By default, |scope_success > > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_succ…>| > will invoke its action if it is destroyed normally, |scope_fail < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail…>| > - if it is destroyed due to an exception being thrown." > > Note the "typically". :) In this documentation I tried to describe these > facilities in more or less simple language, describing the most typical > use cases. For this simplicity, I had to omit some formalities and > corner cases that would detract the reader from the main purpose and > intended use case of the components. Perhaps, I should improve the > wording, but I would still like the docs to be easily readable. > > And, as I admitted earlier, I completely forgot about coroutines. I will > add a note about coroutenes in relation to the default failure condition > used by scope_success/scope_fail. > > > (BTW, The synopsis in > > > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > < > https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail… > > > > does not indicate that there is any default Cond.) > > Hmm, for some reason Doxygen removed the default template arguments for > scope_success/scope_fail. I'll see if I can fix this. Thanks for noticing. > > > This is not true when a scope guard is used across coroutine > > suspensions: by default [...] scope_fail is not destroyed due to > > exception being thrown. The reality is, it is destroyed based on the > > comparison of two measurements of the number of uncaught exceptions, > > potentially measured in different threads. > > > > I admit this is a notable limitation, and I will document it. But I > do > > not consider this limitation fatal, as there is plenty code out there > > that doesn't use coroutines - I'd even say, much more code than that > > does. > > > > This is one way of looking at it: that the problem is rare. A different > > way is to say that if something works in 99% of the cases and fails only > > in 1%, we have a dangerous situation, as we are unprepared when the 1% > > case happens. > > Well, every technology has its limits. And if a utility is not usable in > 1% of use cases, I don't see why it shouldn't exist to benefit the rest > 99%. > Let me clarify my point here a bit. We can distinguish two situations here. The first is this. A tool compiles and works fine in 99% of the cases, and in the remaining 1% it fails to compile, or signals an error. The second is this. A tool compiles and works fine in 99% of the cases, and in the remaining 1%it compiles fine, reports no error, and works against the user's expectations or the declared intent. In the first case, this is an acceptable trade-off. In the second case, it may be debatable, but I personally would find it a bad trade-off. My claim is that the situation with scope_fail is closer to the second one. Especially, given that a 100% alternative exists: just explicitly deactivate an active guard. Regards, &rzej; > > Also, I forgot to mention that Boost.Scope's scope_success/scope_fail > > support custom failure predicates which may not rely on the exception > > state at all. > > > > Can it be used to fix the coroutine case? (That is to detect that the > > scope is left due to an exception being thrown?) > > To my knowledge, not in pure C++. With current real coroutine > implementations? I don't know, probably not either. You could use this > feature with your own error reporting mechanism, like checking an error > code. > > I could imagine a mechanism that would capture the unhandled exceptions > count upon entering a coroutine. Throwing and catching exceptions from > the coroutine would then update this cached counter the same way as it > does for the thread-specific counter. Resuming the coroutine would > maintain its own counter regardless of the caller's state. Then > scope_success/scope_fail could use some internal API to use this counter > (say, co_unhandled_exceptions()) instead of unhandled_exceptions() to > detect a thrown exception. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Re: [boost] [release] Boost 1.82.0 Release Candidate 1 is available
by Matt Borland 07 Apr '23

07 Apr '23

> On Apr 6, 2023, at 4:25 PM, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The first release candidates for the 1.82.0 release are now available at: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/> > > The SHA256 checksums are as follows: > > b6bfc8adc9056bdb01083680b77ecdd7ad4a59a7425a3a42e15a1fe7f6c4f459 boost_1_82_0_rc1.7z > 891aa0d522f80d79ecf622378961ceec882025d55b8aa85f61847db602056d57 boost_1_82_0_rc1.zip > bcdf29d00ade098140ef6934849f27273ad655fcb1e172a4f25660ae0f930d33 boost_1_82_0_rc1.tar.gz > 17d717a04d81e4e23bf0b527bae894f36db72c75976224ddedea9ffddfcd1fbd boost_1_82_0_rc1.tar.bz2 > > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release managers > > I have successfully built the libraries using Homebrew Clang 16.0.1 on an M1 Mac running macOS Ventura 13.3. Matt

1 0

Re: [boost] [scope] scope_fail is unimplementable
by Andrey Semashev 07 Apr '23

07 Apr '23

On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote: > Hi Everyone, > It is my understanding that the reason scope_fail was left to die in the > C++ Extensions for Library Fundamentals v3 was that it is not > implementable. I'm not sure what you mean in the "left to die" part. Do you mean that these facilities are being deprecated? > One cannot detect if the scope is being left due to an > exception thrown from within the scope. Observing the number of uncaught > exceptions in the constructor and in the destructor will not work, given > that we now have coroutines that can be suspended and then resumed in > another thread (with a different number of uncaught exceptions), or even in > the same thread but at some later point, when the number of uncaught > exceptions has changed. > > The enclosed example illustrates how a scope_fail fails to call the > callback when an exception is thrown from a coroutine. It uses Lewis > Baker's CppCoro implementation of a generator. > > The only reliable way to call a callback when the scope is left due to an > exception is through using the explicit call to `deactivate()` function. It > is more verbose, but reliable. I must say I have no experience with coroutines, but my understanding is that they are basically incompatible with any mechanism that relies on thread-specific state, including the uncaught exceptions counter. Thus I wouldn't say scope_success/scope_fail are unimplementable - they clearly are - but that they are incompatible with coroutines. That is, these scope guards will work as expected as long as you don't switch coroutines within the guarded scope. I admit this is a notable limitation, and I will document it. But I do not consider this limitation fatal, as there is plenty code out there that doesn't use coroutines - I'd even say, much more code than that does. Thanks for pointing this out.

1 1