On Fri, May 30, 2014 at 2:07 AM, Andrey Semashev wrote:

On Friday 30 May 2014 10:29:02 Andrzej Krzemienski wrote:

...

Hi, I am not sure where, but I am convinced that I have read that it is recommended for Boost libraries that they not use naked throw expressions but instead call boost::throw_exception. Is that true?

Yes. In fact, most of the time it's better to use BOOST_THROW_EXCEPTION macro.

...

If so, it enforces a dependency of more than half Boost libraries on Boost.Exception. Am I right?

You're technically correct but this dependence is very lightweight: a single file (boost/exception/exception.hpp) designed specifically for that purpose. It's about 200 lines of self-contained code which doesn't include anything. This code is needed to enable the use of the rest of Boost Exception, which can not work without it. That said, the user can specify BOOST_EXCEPTION_DISABLE to disable the integration of Boost Exception into boost::throw_exception. See www.boost.org/doc/libs/release/libs/exception/doc/configuration_macros.html. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Saturday 31 May 2014 08:39:52 John Maddock wrote:

...

...

...

I am not sure where, but I am convinced that I have read that it is recommended for Boost libraries that they not use naked throw expressions but instead call boost::throw_exception. Is that true?

Yes. In fact, most of the time it's better to use BOOST_THROW_EXCEPTION macro.>>

...

If so, it enforces a dependency of more than half Boost libraries on Boost.Exception. Am I right?

You're technically correct but this dependence is very lightweight: a single file (boost/exception/exception.hpp) designed specifically for that purpose. It's about 200 lines of self-contained code which doesn't include anything. This code is needed to enable the use of the rest of Boost Exception, which can not work without it.

I'm starting to wonder if all the "workaround" headers should be moved into Config (provided they don't depend on anything else). This would be one candidate I guess?

You mean boost/exception/exception.hpp? That doesn't look like a workaround header. I would argue that boost/exception/detail/attribute_noreturn.hpp or similar header should be in Boost.Config. I needed such macro a few times and pulling it from Boost.Exception is awkward.

Possible others would be

boost/cerrno.gpp boost/cstdlib.hpp boost/cstdint.hpp

Thoughts? John.

I'm ok with these 3.

...

I'm starting to wonder if all the "workaround" headers should be moved into Config (provided they don't depend on anything else). This would be one candidate I guess?

You mean boost/exception/exception.hpp? That doesn't look like a workaround header.

The rationale is that boost/throw_exception.hpp started off at least as a workaround for compilers with exception handling turned off (and is still required for such), the fact that it pulls in one header from Boost.Exception as well is a side effect, but a not-unhappy one in that it stops endless "why do I need to depend on Boost.Exception" discussions, if that one header shift to Config. John.

On Saturday 31 May 2014 14:50:08 Peter Dimov wrote:

John Maddock wrote:

...

The rationale is that boost/throw_exception.hpp started off at least as a workaround for compilers with exception handling turned off (and is still required for such), the fact that it pulls in one header from Boost.Exception as well is a side effect, but a not-unhappy one in that it stops endless "why do I need to depend on Boost.Exception" discussions, if that one header shift to Config.

Or, we could move these two headers to a separate 'throw_exception' module, with Emil as maintainer.

Boost.ExceptionCore? Yes, I like that too.

John Maddock wrote:

...

Or, we could move these two headers to a separate 'throw_exception' module, with Emil as maintainer.

That's also fine, just seems a little strange to have a repository for 2 files.

It is a bit strange, but no stranger than Boost.Assert. These cases, when the entire Boost depends on a few headers, warrant an exception, in my opinion. A dependency on Boost.Exception isn't a big deal in practice, but it carries a heavy psychological weight ("but I don't use Boost.Exception, why am I forced to depend on it!"). A separate module comes with the guarantee that it will never grow and acquire dependencies behind your back.

Emil Dotchevski wrote:

On Sat, May 31, 2014 at 5:11 AM, John Maddock wrote:

...

...

Or, we could move these two headers to a separate 'throw_exception' module, with Emil as maintainer.

That's also fine, just seems a little strange to have a repository for 2 files. John.

I like the idea. Basically, I'll kill boost/exception/exception.hpp and move its content to boost/throw_exception.hpp. Thoughts?

That's not necessary in principle. You can keep boost/exception/exception.hpp as-is in the new module; it's not a problem that the directory doesn't belong to it, so to speak.

On Sat, May 31, 2014 at 10:47 PM, Emil Dotchevski wrote:

On Sat, May 31, 2014 at 11:41 AM, Peter Dimov wrote:

...

Emil Dotchevski wrote:

...

I like the idea. Basically, I'll kill boost/exception/exception.hpp and move its content to boost/throw_exception.hpp. Thoughts?

That's not necessary in principle. You can keep boost/exception/exception.hpp as-is in the new module; it's not a problem that the directory doesn't belong to it, so to speak.

Right, it isn't necessary, but my original motivation for the separation was to keep the stuff boost/throw_exception.hpp depends on out of boost/exception/exception.hpp, which does not include anything at all. Nobody else seems to appreciate this :) so why bother?

Technically, you can merge the files, but to keep the code structure more clear I'd still keep them separate. I.e. it isn't obvious that I would find boost::exception definition in throw_exception.hpp. Also, exception/exception.hpp is now conditionally included into throw_exception.hpp, but its contents are available unconditionally. It is now possible to disable Boost.Exception use in throw_exception() but still be able to use Boost.Exception.

On Saturday 31 May 2014 12:13:55 John Maddock wrote:

...

...

I'm starting to wonder if all the "workaround" headers should be moved into Config (provided they don't depend on anything else). This would be one candidate I guess?

You mean boost/exception/exception.hpp? That doesn't look like a workaround header.

The rationale is that boost/throw_exception.hpp started off at least as a workaround for compilers with exception handling turned off (and is still required for such), the fact that it pulls in one header from Boost.Exception as well is a side effect, but a not-unhappy one in that it stops endless "why do I need to depend on Boost.Exception" discussions, if that one header shift to Config.

I'm still missing which particular header you refer to, sorry. It seems boost::exception is a crucial part of Boost.Exception, I don't think that moving boost/exception/exception.hpp would be a good idea. Boost.Exception should be maintainable, having its fundamental part somewhere else precludes this. Move boost/throw_exception.hpp and add a dependency on Boost.Exception to Boost.Config? No, I don't think that is a good idea either. Move boost/throw_exception.hpp and remove support for Boost.Exception (and hence the dependency)? Possible, but that also reduces user experience with Boost. I very much like the additional information Boost.Exception provides for exceptions. Add a new macro, say BOOST_THROW, to Boost.Config that will only deal with the configurability aspect of BOOST_THROW_EXCEPTION? Then make BOOST_THROW_EXCEPTION use BOOST_THROW internally. Leave all current headers in their places. This sounds like the most sensible plan to me. Although I'm a little worried that people will start ignoring BOOST_THROW_EXCEPTION and hence we'll lose the additional information in exceptions we have now. Personally, I see no problem with dependency on Boost.Exception, so I would have left everything as is. But if I have to choose, I'd prefer the last solution of the above.

On 31 May 2014 12:39, Peter Dimov wrote:

There is also boost/detail/iterator.hpp, in Detail. It's also a workaround header. It conditionally includes type traits and MPL headers though. But I think that it only does that on MSVC 6, which we no longer support (the #ifdef is on BOOST_MSVC_STD_ITERATOR).

It should be safe to deprecate that macro, and remove the workarounds. According to the 1.35.0 test results, Visual C++ 7.1 had _CPPLIB_VER = 313, so I think it's safe to remove workarounds for _CPPLIB_VER < 306.

Stephan T. Lavavej wrote:

You should really look at _MSC_VER instead of _CPPLIB_VER which is undocumented and unsupported. (The story is that _CPPLIB_VER is a Dinkumware macro, and Microsoft doesn't promise that we'll always keep it, or remember to update it for each major version. _MSC_VER is the compiler major version macro, which for customers outside Microsoft always corresponds 1:1 to the STL implementation.)

I'm not sure that this is true when using the Intel compiler.

...

According to the 1.35.0 test results, Visual C++ 7.1 had _CPPLIB_VER = 313, so I think it's safe to remove workarounds for _CPPLIB_VER < 306.

You should really look at _MSC_VER instead of _CPPLIB_VER which is undocumented and unsupported. (The story is that _CPPLIB_VER is a Dinkumware macro, and Microsoft doesn't promise that we'll always keep it, or remember to update it for each major version. _MSC_VER is the compiler major version macro, which for customers outside Microsoft always corresponds 1:1 to the STL implementation.)

From memory, there were some folks using MSVC with updated Dinkumware libraries, in which case Boost.Config broke if we checked _MSC_VER. John.