[modularization] Dependency to Boost.Exception unavoidable?

newer
[Trac] Catch-22: Captcha Errors on...

older
[git] open an "admin" link doesn't...

Daniel Pfeifer

1 Nov 2013 1 Nov '13

3:45 p.m.

2013/11/1 Peter Dimov :

...

->exception is unavoidable because of throw_exception.

I think `throw_exception.hpp` belongs to Boost.Utility for two reasons: 1. That file is older than Boost.Exception. 2. It introduces a *conditional* dependency to Boost.Exception. When I provide an implementation for `throw_exception` and/or define BOOST_NO_EXCEPTIONS/BOOST_EXCEPTION_DISABLE accordingly, I would expect *not* having a dependency to Boost.Exception. -- Daniel

Show replies by date

Peter Dimov

1 Nov 1 Nov

4:02 p.m.

New subject: [modularization] Dependency to Boost.Exception unavoidable?

Daniel Pfeifer wrote:

...

2013/11/1 Peter Dimov :

...
->exception is unavoidable because of throw_exception.

I think `throw_exception.hpp` belongs to Boost.Utility for two reasons:

That'd be useless, even assuming a hypothetical Utility that doesn't depend on the world as it does now. It would make Utility depend on Exception (because throw_exception.hpp does depend on Exception), thereby not saving a dependency, but introducing one extra.

...

When I provide an implementation for `throw_exception` and/or define BOOST_NO_EXCEPTIONS/BOOST_EXCEPTION_DISABLE accordingly, I would expect *not* having a dependency to Boost.Exception.

This kind of reaction is understandable but misguided. Exception's author (Emil Dotchevski) likes dependencies much less than most people and the library is relatively self-contained (and I would expect it to become more so as we transition to the new structure). It's other modules you should be afraid of, not Exception.

Emil Dotchevski

7:08 p.m.

New subject: [modularization] Dependency to Boost.Exception unavoidable?

On Fri, Nov 1, 2013 at 8:45 AM, Daniel Pfeifer wrote:

...

2013/11/1 Peter Dimov :

...
->exception is unavoidable because of throw_exception.

I think `throw_exception.hpp` belongs to Boost.Utility for two reasons:

1. That file is older than Boost.Exception.

How old a header is orthogonal to correct design.

...

2. It introduces a *conditional* dependency to Boost.Exception.

It is misleading to treat this as dependency on a library, because the only Boost Exception header boost/throw_exception.hpp depends on is boost/exception/exception.hpp, which does not include *any* headers. If people are bothered by the exception/exception.hpp dependency, I am not against moving that code in throw_exception.hpp. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Daniel Pfeifer

9:33 p.m.

New subject: [modularization] Dependency to Boost.Exception unavoidable?

2013/11/1 Emil Dotchevski :

...

On Fri, Nov 1, 2013 at 8:45 AM, Daniel Pfeifer wrote:

...
2013/11/1 Peter Dimov :

...
->exception is unavoidable because of throw_exception.

I think `throw_exception.hpp` belongs to Boost.Utility for two reasons:

1. That file is older than Boost.Exception.

How old a header is orthogonal to correct design.

That is true.

...

...
2. It introduces a *conditional* dependency to Boost.Exception.

It is misleading to treat this as dependency on a library, because the only Boost Exception header boost/throw_exception.hpp depends on is boost/exception/exception.hpp, which does not include *any* headers.

If people are bothered by the exception/exception.hpp dependency, I am not against moving that code in throw_exception.hpp.

After the transition to Git, Boost.Exception will live in its own repository. People might be bothered to have this repository as a dependency, even though they have exceptions disabled. So we are really talking about library dependencies, not include dependencies. Moving throw_exception.hpp out of this repository eliminates that dependency. Also, that header should not include any headers from Boost.Exception when BOOST_NO_EXCEPTIONS or BOOST_EXCEPTION_DISABLE is defined. -- Daniel

Peter Dimov

9:41 p.m.

New subject: [modularization] Dependency to Boost.Exceptionunavoidable?

Daniel Pfeifer wrote:

...

Moving throw_exception.hpp out of this repository eliminates that dependency.

I really don't see how. Before, you have my_module -> exception. After, you have my_module -> utility -> exception. Not only do you still depend on Exception, you now depend on Utility as well.

...

Also, that header should not include any headers from Boost.Exception when BOOST_NO_EXCEPTIONS or BOOST_EXCEPTION_DISABLE is defined.

Are you talking about #include here?

Andrey Semashev

9:54 p.m.

New subject: [modularization] Dependency to Boost.Exceptionunavoidable?

On Friday 01 November 2013 23:41:09 Peter Dimov wrote:

...

Are you talking about

#include

here?

...which should probably be moved to Boost.Config, BTW?

Peter Dimov

9:58 p.m.

New subject: [modularization] Dependency toBoost.Exceptionunavoidable?

Andrey Semashev wrote:

...

On Friday 01 November 2013 23:41:09 Peter Dimov wrote:

...
Are you talking about

#include

here?

...which should probably be moved to Boost.Config, BTW?

Very much so.

Daniel Pfeifer

10:27 p.m.

New subject: [modularization] Dependency to Boost.Exceptionunavoidable?

2013/11/1 Peter Dimov :

...

Daniel Pfeifer wrote:

...
Moving throw_exception.hpp out of this repository eliminates that dependency.

I really don't see how.

Before, you have my_module -> exception. After, you have my_module -> utility -> exception. Not only do you still depend on Exception, you now depend on Utility as well.

When I want to use exceptions and also Boost.Exception, I have my_app -> exception in addition to my_app -> your_library -> utility -> exception. The dependency to exception does not bother me. I have that anyway. When I don't want to use Boost.Exception (BOOST_EXCEPTION_DISABLE), or don't want to use exceptions at all (BOOST_NO_EXCEPTIONS), I have my_app -> your_library -> utility. It should stop there.

...

...
Also, that header should not include any headers from Boost.Exception when BOOST_NO_EXCEPTIONS or BOOST_EXCEPTION_DISABLE is defined.

Are you talking about

#include

here?

I was referring to . This should not be needed when BOOST_NO_EXCEPTIONS is defined, as throw_exception takes std::exception, not boost::exception. -- Daniel

Peter Dimov

10:42 p.m.

New subject: [modularization] Dependency toBoost.Exceptionunavoidable?

Daniel Pfeifer wrote:

...

When I don't want to use Boost.Exception (BOOST_EXCEPTION_DISABLE), or don't want to use exceptions at all (BOOST_NO_EXCEPTIONS), I have my_app -> your_library -> utility. It should stop there.

Ah, I see. I was thinking in terms of automatic dependency resolution, so that fetching Utility will end up fetching Exception anyway because it has no idea what your macro definitions are going to be. But if you're just fetching modules manually one by one, then yes. Whether the end result will be in your favor is another story - Utility may well be a larger repo than Exception.

...

I was referring to . This should not be needed when BOOST_NO_EXCEPTIONS is defined, as throw_exception takes std::exception, not boost::exception.

It's not, as far as I can see.

Emil Dotchevski

11:01 p.m.

New subject: [modularization] Dependency to Boost.Exceptionunavoidable?

On Fri, Nov 1, 2013 at 3:27 PM, Daniel Pfeifer wrote:

...

I was referring to . This should not be needed when BOOST_NO_EXCEPTIONS is defined, as throw_exception takes std::exception, not boost::exception.

That is not necessarily true. These two defines have the following semantics: 1. If BOOST_NO_EXCEPTIONS is defined, libraries should not throw. One option to implement that behavior is to pass exception objects (of the usual documented library-defined types) to boost::throw_exception. This imposes a requirement that the exception types must derive from std::exception, but does NOT mean that they can't use the Boost Exception library. 2. If BOOST_EXCEPTION_DISABLE is defined, then boost::throw_exception does not inject the boost::exception class as a base. This prevents boost/exception/exception.hpp from being included. However that header does not include *any* headers, so the benefits in terms of dependencies are mostly theoretical. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4192

Age (days ago)

4192

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Andrey Semashev
Daniel Pfeifer
Emil Dotchevski
Peter Dimov