Proposal: Boost.Core

Peter Dimov

31 May 2014 31 May '14

2:21 p.m.

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities. The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert). Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful". Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers. The following utilities are immediate candidates for migration into the new module: - addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp In addition, the following can be duplicated inside to reduce dependencies: - mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv and so on.

Show replies by date

Beman Dawes

31 May 31 May

2:35 p.m.

On Sat, May 31, 2014 at 10:21 AM, Peter Dimov wrote: I propose the creation of a new module, Boost.Core, a repository of Boost

...

core utilities.

The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert).

...

Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful".

...

Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers.

...

The following utilities are immediate candidates for migration into the new module:

- addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp

...

In addition, the following can be duplicated inside to reduce dependencies:

- mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv

and so on.

Thanks, Peter! --Beman

Daniel James

2:36 p.m.

On 31 May 2014 15:21, Peter Dimov wrote:

...

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities.

All sounds fine to me.

...

The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert).

It might also need to depend on Predef.

Peter Dimov

2:48 p.m.

Daniel James wrote:

...

On 31 May 2014 15:21, Peter Dimov wrote:

...
The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert).

It might also need to depend on Predef.

Perhaps; we'll cross that bridge when we come to it. At the moment - as far as I can see - it's only boost/detail/endian.hpp that needs Predef, and this header is actually misplaced; it needs to be in Predef instead of Detail.

Daniel James

3:27 p.m.

On 31 May 2014 15:48, Peter Dimov wrote:

...

Daniel James wrote:

...
On 31 May 2014 15:21, Peter Dimov wrote:

...
The criteria for inclusion into this module would be that the utility > component is (a) simple, (b) used by other Boost libraries, (c) does not > depend on any headers outside of Core and Config (and perhaps Assert).

It might also need to depend on Predef.

Perhaps; we'll cross that bridge when we come to it. At the moment - as far as I can see - it's only boost/detail/endian.hpp that needs Predef, and this header is actually misplaced; it needs to be in Predef instead of Detail.

I think the plan is to deprecate that header, rather than move it. I was thinking more about things like this: http://boost.2283326.n4.nabble.com/config-predef-Is-it-OK-for-boost-config-t...

Glen Fernandes

2:59 p.m.

On Sat, May 31, 2014 at 7:21 AM, Peter Dimov wrote:

...

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities.

The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert).

Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful".

Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers.

Sounds good to me. Glen

Andrey Semashev

4:30 p.m.

On Saturday 31 May 2014 17:21:42 Peter Dimov wrote:

...

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities.

The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert).

Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful".

Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers.

The following utilities are immediate candidates for migration into the new module:

- addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp

In addition, the following can be duplicated inside to reduce dependencies:

- mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv

and so on.

I like the general idea but I'm worried about needing to duplicate things. The list is short now, but I'm sure it will get bigger. Maybe that's a sign that something that needs these components do not fit into Boost.Core. OTOH, MPL and TypeTraits stuff you mentioned is commonly used, so I suspect if we limit ourselves to avoid them then Boost.Core will be almost empty. Maybe we should decompose MPL and TypeTraits first and then use the smaller bits in Core?

Peter Dimov

5:14 p.m.

Andrey Semashev wrote:

...

...
In addition, the following can be duplicated inside to reduce dependencies:

- mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv

and so on.

I like the general idea but I'm worried about needing to duplicate things. The list is short now, but I'm sure it will get bigger. Maybe that's a sign that something that needs these components do not fit into Boost.Core.

This duplication is necessary because many of the candidates for Core that I inspected #include those things. The list cannot get much bigger on its own; it's based on what is in the headers now. Those headers are old and are a relic of a pre-modular world, when you didn't need write permissions to Detail to add something ostensibly useful there. To reiterate, I'm not suggesting that we duplicate for the fun of it; I'm only suggesting duplication when it's a necessary prerequisite of moving an existing header into the new library. We will, of course, evaluate every such addition on a case by case basis. Robert Ramey wrote:

...

Duplication is going to start creating it's own set of problems when the copies (inevitably) diverge.

This is not likely to happen. Most of these utilities haven't been touched at all for a long time, and many, such as if_, eval_if, remove_cv are trivial and their specification is very clear. There's not much room for divergence.

Peter Dimov

5:35 p.m.

Andrey Semashev wrote:

...

Maybe we should decompose MPL and TypeTraits first and then use the smaller bits in Core?

That is theoretically possible and perhaps even the Right Way Forward, but realistically, I don't see it happening. :-) I remember looking at MPL and Type Traits in the past with a "how hard could that be" initial attitude, but I also remember that I got discouraged pretty quickly.

...

OTOH, MPL and TypeTraits stuff you mentioned is commonly used, so I suspect if we limit ourselves to avoid them then Boost.Core will be almost empty.

It will fill up, trust me. The reason we're going nowhere at present is that we have no good and practical way of severing an unwanted dependency. In many such cases, moving one carefully chosen header to Core would be all it takes. We will, of course, run out of low-hanging fruits at some point, but so what? We'll have accomplished much in the meantime. Or, we could continue spilling ink here. :-)

Andrey Semashev

5:42 p.m.

On Saturday 31 May 2014 20:35:29 Peter Dimov wrote:

...

Andrey Semashev wrote:

...
Maybe we should decompose MPL and TypeTraits first and then use the smaller bits in Core?

That is theoretically possible and perhaps even the Right Way Forward, but realistically, I don't see it happening. :-)

I remember looking at MPL and Type Traits in the past with a "how hard could that be" initial attitude, but I also remember that I got discouraged pretty quickly.

...
OTOH, MPL and TypeTraits stuff you mentioned is commonly used, so I suspect if we limit ourselves to avoid them then Boost.Core will be almost empty.

It will fill up, trust me. The reason we're going nowhere at present is that we have no good and practical way of severing an unwanted dependency. In many such cases, moving one carefully chosen header to Core would be all it takes.

We will, of course, run out of low-hanging fruits at some point, but so what? We'll have accomplished much in the meantime.

Or, we could continue spilling ink here. :-)

Ok, let's give it a try and see what happens. :) First, we need a new submodule...

Peter Dimov

1 Jun 1 Jun

1:54 a.m.

Andrey Semashev wrote:

...

Ok, let's give it a try and see what happens. :) First, we need a new submodule...

We have it, in develop. I've seeded it with a few headers from utility that met the criteria: - boost/utility/addressof.hpp - boost/checked_delete.hpp - boost/utility/enable_if.hpp - boost/noncopyable.hpp - boost/ref.hpp. Of these, noncopyable.hpp may be a bit controversial, being arguably an end-user header and not a core utility. It is, however, used by the Type Traits library: http://www.pdimov.com/tmp/report/type_traits.html#utility along with enable_if.hpp and declval.hpp. enable_if is now in core, declval.hpp both uses and is used by Type Traits and will migrate there earlier or later, so moving noncopyable into core allows us to cut the link between Type Traits and Utility. Next obvious targets: boost/iterator.hpp, boost/detail/iterator.hpp, boost/detail/lightweight_test.hpp, boost/cstdint.hpp (if it doesn't go into Config). Then we probably need to look at http://www.pdimov.com/tmp/report/mpl.html#detail and http://www.pdimov.com/tmp/report/mpl.html#utility That last dependency, on value_init.hpp, I had missed. Oh well.

Andrey Semashev

7:07 a.m.

On Sunday 01 June 2014 04:54:04 Peter Dimov wrote:

...

Andrey Semashev wrote:

...
Ok, let's give it a try and see what happens. :) First, we need a new submodule...

We have it, in develop.

How about moving: - utility/empty_deleter.hpp - utility/explicit_operator_bool.hpp - utility/swap.hpp cstdint.hpp, I think, should go into Boost.Config.

Peter Dimov

3:34 p.m.

Andrey Semashev wrote:

...

How about moving:

- utility/empty_deleter.hpp - utility/explicit_operator_bool.hpp - utility/swap.hpp

I was going where dependencies took me, and didn't stumble upon these three. Of them, explicit_operator_bool is a no-brainer for inclusion per all criteria. The other two are more in the gray. empty_deleter is only used by log; swap is more widely used, but avoiding it as a dependency is trivial, one just writes using std::swap; std::swap( x, y ) instead of boost::swap( x, y ). Still, they all probably do belong in Core. I'd be much happier if empty_deleter is called null_deleter though. empty_deleter always makes me think of empty deleter optimizations, and null_deleter, while not necessarily a better name, does have an established meaning. (Also, op() needs to be templated on T*, because it doesn't support shared_ptr now.)

...

cstdint.hpp, I think, should go into Boost.Config.

Either way is fine with me. I would personally have put it into Core because I think that there's been much pressure recently to fit all kinds of things into Config just because it was the only core library until now. But cstdint.hpp _is_ a workaround header. So... whichever. Let's just decide quickly and move it somewhere. :-) Our next target should be the so-called Detail library. Most "detail" headers probably belong someplace else.

Peter Dimov

3:54 p.m.

...

Our next target should be the so-called Detail library. Most "detail" headers probably belong someplace else.

In particular, it seems to me that the 'winapi' subdirectory (plus interlocked.hpp) should be its own library.

Andrey Semashev

4:14 p.m.

On Sunday 01 June 2014 18:54:05 Peter Dimov wrote:

...

...
Our next target should be the so-called Detail library. Most "detail" headers probably belong someplace else.

In particular, it seems to me that the 'winapi' subdirectory (plus interlocked.hpp) should be its own library.

I was thinking about Boost.Config as one of its purpose is to define a Boost- wide interface for setting the supported Windows version. Although I admit that many of the winapi/* headers may be updated as Boost libraries are developed (namely, Boost.Sync).

Peter Dimov

4:44 p.m.

Andrey Semashev wrote: On Sunday 01 June 2014 18:54:05 Peter Dimov wrote:

...

...
In particular, it seems to me that the 'winapi' subdirectory (plus interlocked.hpp) should be its own library.

I was thinking about Boost.Config as one of its purpose is to define a Boost-wide interface for setting the supported Windows version. Although I admit that many of the winapi/* headers may be updated as Boost libraries are developed (namely, Boost.Sync).

Doesn't look very Config to me, and is certainly likely to see active development. It's a legitimate library, in my opinion. Plus, if it's intended to be used by other libraries except Sync, it needs to have some minimal documentation, if only to list what Windows API is provided, and by which header.

Andrey Semashev

7:15 p.m.

On Sunday 01 June 2014 19:44:48 Peter Dimov wrote:

...

Andrey Semashev wrote:

On Sunday 01 June 2014 18:54:05 Peter Dimov wrote:

...
...
In particular, it seems to me that the 'winapi' subdirectory (plus interlocked.hpp) should be its own library.

I was thinking about Boost.Config as one of its purpose is to define a Boost-wide interface for setting the supported Windows version. Although I admit that many of the winapi/* headers may be updated as Boost libraries are developed (namely, Boost.Sync).

Doesn't look very Config to me, and is certainly likely to see active development.

winapi/config.hpp contains the configuration part, this header is quite stable. Except if we decide to target NT6 by default the default version has to be updated.

...

It's a legitimate library, in my opinion. Plus, if it's intended to be used by other libraries except Sync, it needs to have some minimal documentation, if only to list what Windows API is provided, and by which header.

It is used by Chrono and Vicente was planning to port Thread as well. As most of our implementation details, it is not documented, true. Not sure if there's a need to add official docs, this tool is for Boost developers only and the headers pretty much reflect parts of windows.h. MSDN documents these APIs rather well.

Peter Dimov

7:55 p.m.

Andrey Semashev wrote:

...

Not sure if there's a need to add official docs, this tool is for Boost developers only and the headers pretty much reflect parts of windows.h. MSDN documents these APIs rather well.

No, you misunderstand; I was not suggesting to duplicate the MSDN documentation for every function and type, just list the function and types and what header defines them. And perhaps say a few words about BOOST_USE_WINDOWS_H, which is a legitimate user macro. BOOST_USE_WINAPI_VERSION is also a user macro, I suppose?

Andrey Semashev

10:19 p.m.

On Sunday 01 June 2014 22:55:31 Peter Dimov wrote:

...

Andrey Semashev wrote:

...
Not sure if there's a need to add official docs, this tool is for Boost developers only and the headers pretty much reflect parts of windows.h. MSDN documents these APIs rather well.

No, you misunderstand; I was not suggesting to duplicate the MSDN documentation for every function and type, just list the function and types and what header defines them. And perhaps say a few words about BOOST_USE_WINDOWS_H, which is a legitimate user macro. BOOST_USE_WINAPI_VERSION is also a user macro, I suppose?

Yes, it is. I don't mind documenting. The problem is where that documentation should live. I don't want to expose documentation on implementation details to Boost users, encouraging them to use these tools.

Peter Dimov

2 Jun 2 Jun

3:46 p.m.

Andrey Semashev wrote:

...

I don't mind documenting. The problem is where that documentation should live. I don't want to expose documentation on implementation details to Boost users, encouraging them to use these tools.

That's a legitimate concern in principle. We'll need to decide, at some point, what happens with future components that would have previously went into Detail, but now need to be their own separate modules. But in this case, I see no harm in exposing the developer documentation of Winapi to Boost users. The Windows API is fixed. Taking away, in a subsequent release, an API function already present in Winapi also doesn't seem likely or desirable.

Andrey Semashev

1 Jun 1 Jun

4:11 p.m.

On Sunday 01 June 2014 18:34:01 Peter Dimov wrote:

...

Andrey Semashev wrote:

...
How about moving: - utility/empty_deleter.hpp - utility/explicit_operator_bool.hpp - utility/swap.hpp

I was going where dependencies took me, and didn't stumble upon these three. Of them, explicit_operator_bool is a no-brainer for inclusion per all criteria. The other two are more in the gray. empty_deleter is only used by log; swap is more widely used, but avoiding it as a dependency is trivial, one just writes using std::swap; std::swap( x, y ) instead of boost::swap( x, y ).

That actually exposes ADL bugs in some compilers (MSVC, if I'm not mistaken). So there still may be a reason to use boost::swap.

...

Still, they all probably do belong in Core. I'd be much happier if empty_deleter is called null_deleter though. empty_deleter always makes me think of empty deleter optimizations, and null_deleter, while not necessarily a better name, does have an established meaning.

Do you think we should rename it even though it is already released/documented?

...

(Also, op() needs to be templated on T*, because it doesn't support shared_ptr now.)

Hmm, I was trying to avoid a template instantiation. Probably not worth it, can be changed no problem.

...

...
cstdint.hpp, I think, should go into Boost.Config.

Either way is fine with me. I would personally have put it into Core because I think that there's been much pressure recently to fit all kinds of things into Config just because it was the only core library until now. But cstdint.hpp _is_ a workaround header. So... whichever. Let's just decide quickly and move it somewhere. :-)

I think it's decided already - John agreed and noone objected.

Peter Dimov

4:33 p.m.

Andrey Semashev wrote:

...

Do you think we should rename it even though it is already released/documented?

We can also leave it in Utility under the old name, if you like. I'm not seeing any documentation though? There is for explicit_operator_bool, but not for empty_deleter.

Andrey Semashev

7:05 p.m.

On Sunday 01 June 2014 19:33:14 Peter Dimov wrote:

...

Andrey Semashev wrote:

...
Do you think we should rename it even though it is already released/documented?

We can also leave it in Utility under the old name, if you like.

I've moved all 3 components. I've left the old header deprecated in Boost.Core.

...

I'm not seeing any documentation though? There is for explicit_operator_bool, but not for empty_deleter.

There's no dedicated docs but it's mentioned in Boost.Log docs and exampled. I'll have to update them later. I propose to move the html pages into doc subfolder. Ideally, these should be rewritten in QuickBook when the time permits.

Mostafa

4:19 p.m.

On Sun, 01 Jun 2014 08:34:01 -0700, Peter Dimov wrote:

...

I'd be much happier if empty_deleter is called null_deleter though. empty_deleter always makes me think of empty deleter optimizations, and null_deleter, while not necessarily a better name, does have an established meaning.

I suggest "noop_deleter". At first glance "null_deleter" conveys that it's a deleter for null pointers.

Glen Fernandes

4:23 p.m.

On Sun, Jun 1, 2014 at 8:34 AM, Peter Dimov wrote:

...

Either way is fine with me. I would personally have put it into Core because I think that there's been much pressure recently to fit all kinds of things into Config just because it was the only core library until now. But cstdint.hpp _is_ a workaround header. So... whichever. Let's just decide quickly and move it somewhere. :-)

It's done and ready for John to merge into Config. Glen

John Maddock

5:06 p.m.

...

...
Either way is fine with me. I would personally have put it into Core because I think that there's been much pressure recently to fit all kinds of things into Config just because it was the only core library until now. But cstdint.hpp _is_ a workaround header. So... whichever. Let's just decide quickly and move it somewhere. :-)

It's done and ready for John to merge into Config.

Done, John.

Glen Fernandes

5:24 p.m.

...

Done, John.

Thanks John. There are corresponding commits at Boost.Integer that can be merged (removal of the now-Config'd cstdint.hpp, documentation, and tests). Glen

John Maddock

5:39 p.m.

...

Thanks John. There are corresponding commits at Boost.Integer that can be merged (removal of the now-Config'd cstdint.hpp, documentation, and tests).

Ah, while I have edited some of those files in the past (who hasn't?), I don't have write access to that repo - do you know who does? John.

Glen Fernandes

6:02 p.m.

...

...
Thanks John. There are corresponding commits at Boost.Integer that can be merged (removal of the now-Config'd cstdint.hpp, documentation, and tests).

Ah, while I have edited some of those files in the past (who hasn't?), I don't have write access to that repo - do you know who does?

I can only see members of teams that I'm part of (smart_ptr, align, circular_buffer, core). I'll create an admin issue to request access to Integer. Glen

Daniel James

7:07 p.m.

On 1 June 2014 18:39, John Maddock wrote:

...

...
Thanks John. There are corresponding commits at Boost.Integer that can be merged (removal of the now-Config'd cstdint.hpp, documentation, and tests).

Ah, while I have edited some of those files in the past (who hasn't?), I don't have write access to that repo - do you know who does?

I have admin access, although I try not to abuse it too much. I'm also not keen on the way the documentation was changed, I'm going to think about how it could be done better.

Glen Fernandes

7:24 p.m.

On Sun, Jun 1, 2014 at 12:07 PM, Daniel James wrote:

...

I have admin access, although I try not to abuse it too much. I'm also not keen on the way the documentation was changed, I'm going to think about how it could be done better.

It probably can be done better. The current change should be non-breaking, at least, in that the documentation page cstdint.html in Integer docs should still work, except now it is a single sentence which links to the original documentation that is now part of Boost.Config. Glen

Adam Wulkiewicz

1:44 p.m.

Hi, 2014-06-01 3:54 GMT+02:00 Peter Dimov :

...

Andrey Semashev wrote:

...
Ok, let's give it a try and see what happens. :) First, we need a new submodule...

We have it, in develop.

This is probably a good place for ignore_unused as well. If you agree I'll prepare a pull request. Btw, we could also think about QBK docs which are more maintainable than HTML ones. Regards, Adam

Peter Dimov

8:45 p.m.

Adam Wulkiewicz wrote:

...

This is probably a good place for ignore_unused as well. If you agree I'll prepare a pull request.

Yes, I agree that Core is a good place for ignore_unused.

Adam Wulkiewicz

2 Jun 2 Jun

1:04 a.m.

Peter Dimov wrote:

...

Adam Wulkiewicz wrote:

...
This is probably a good place for ignore_unused as well. If you agree I'll prepare a pull request.

Yes, I agree that Core is a good place for ignore_unused.

What should be the namespaces and directories structures for new core functionalities? I assume that they should go into boost/core/ directory. But what about namespaces? Should they reside in namespace boost or boost::core? Regards, Adam

Glen Fernandes

1 Jun 1 Jun

8:31 p.m.

On Sat, May 31, 2014 at 6:54 PM, Peter Dimov wrote:

...

Next obvious targets: boost/iterator.hpp, boost/detail/iterator.hpp, boost/detail/lightweight_test.hpp, boost/cstdint.hpp (if it doesn't go into Config).

I've started on boost/detail/lightweight_test.hpp. One question: Do we want to document detail:: bits in Boost.Core? Glen

Peter Dimov

8:44 p.m.

Glen Fernandes wrote:

...

I've started on boost/detail/lightweight_test.hpp. One question: Do we want to document detail:: bits in Boost.Core?

It should go into boost/core/lightweight_test.hpp and be documented. I should have written the documentation for it a long time ago, in fact. Sorry. boost/utility/null_deleter.hpp should probably also be boost/core/null_deleter.hpp. New headers should go into core/, legacy headers can stay as-is unless we feel a sudden desire to make everything regular. :-)

Glen Fernandes

2 Jun 2 Jun

5:53 a.m.

On Sun, Jun 1, 2014 at 1:44 PM, Peter Dimov wrote:

...

It should go into boost/core/lightweight_test.hpp and be documented. I should have written the documentation for it a long time ago, in fact. Sorry.

I've (in the main repository): 1. Moved lightweight_test.hpp and no_exceptions_support.hpp into Core and (viewable in my fork): 2. Moved addressof.hpp, noncopyable.hpp, lightweight_test.hpp, no_exceptions_support.hpp into boost/core/ (And created redirect headers for backward compatibility) 3. Created Quickbook documentation for addressof, noncopyable, and initial documentation for lightweight_test, no_exceptions_support You can preview the documentation at: http://glenfe.github.io/core/ And view changes from #2 and #3 at: http://github.com/glenfe/core/ Glen

Beman Dawes

1:01 p.m.

On Mon, Jun 2, 2014 at 1:53 AM, Glen Fernandes wrote:

...

On Sun, Jun 1, 2014 at 1:44 PM, Peter Dimov wrote:

...
It should go into boost/core/lightweight_test.hpp and be documented. I should have written the documentation for it a long time ago, in fact. Sorry.

I've (in the main repository): 1. Moved lightweight_test.hpp and no_exceptions_support.hpp into Core and (viewable in my fork): 2. Moved addressof.hpp, noncopyable.hpp, lightweight_test.hpp, no_exceptions_support.hpp into boost/core/ (And created redirect headers for backward compatibility) 3. Created Quickbook documentation for addressof, noncopyable, and initial documentation for lightweight_test, no_exceptions_support

You can preview the documentation at: http://glenfe.github.io/core/

In the lightweight test docs, the effects come before the signature. That is confusing, since it is usually the other way around. Thanks for working on this! --Beman

Peter Dimov

7:14 p.m.

Glen Fernandes wrote:

...

I've (in the main repository): 1. Moved lightweight_test.hpp and no_exceptions_support.hpp into Core and (viewable in my fork): 2. Moved addressof.hpp, noncopyable.hpp, lightweight_test.hpp, no_exceptions_support.hpp into boost/core/ (And created redirect headers for backward compatibility) 3. Created Quickbook documentation for addressof, noncopyable, and initial documentation for lightweight_test, no_exceptions_support

You can go ahead with these changes as far as I'm concerned, except that there's no need to move empty_deleter.hpp to core. In the lightweight_test documentation, it needs to be said that the intent of report_errors() is to be returned from main(). We can add a minimal example, too. Something like #include void sqr( int x ); // should return x*x int main() { BOOST_TEST( sqr( 2 ) == 4 ); BOOST_TEST_EQ( sqr(-3), 9 ); return boost::report_errors(); } ref's documentation is currently in libs/bind/doc/ref.xml, in BoostBook (?) format (it wasn't converted by me.)

Glen Fernandes

9:24 p.m.

Update: Boost.Config: - Now owns cstdint.hpp, including tests and documentation Boost.Core - All relevant headers are available in boost/core, I can remove empty_deleter.hpp if we don't want it there - All documentation converted to QuickBook and viewable at http://boostorg.github.io/core/ - Updated documentation for lightweight_test a bit I'll get to ref() next, and then get to moving other pieces to Boost.Core. Glen

Andrey Semashev

3 Jun 3 Jun

2:53 a.m.

On Monday 02 June 2014 14:24:28 Glen Fernandes wrote:

...

- All relevant headers are available in boost/core, I can remove empty_deleter.hpp if we don't want it there

I think, there's no need for empty_deleter.hpp in core/. I left it in utility/ for backward compatibility with an according warning, intending to remove it completely in the future releases.

Julian Gonggrijp

4 Jun 4 Jun

11:59 a.m.

Glen Fernandes wrote:

...

Update:

Boost.Config: - Now owns cstdint.hpp, including tests and documentation Boost.Core - All relevant headers are available in boost/core, I can remove empty_deleter.hpp if we don't want it there - All documentation converted to QuickBook and viewable at http://boostorg.github.io/core/ - Updated documentation for lightweight_test a bit

I'll get to ref() next, and then get to moving other pieces to Boost.Core.

Just wanted to share with you folks that reading this thread has made me very happy so far. :-) Cheers, Julian

Stephen Kelly

1:31 p.m.

Julian Gonggrijp wrote:

...

Glen Fernandes wrote:

...
Update:

Boost.Config: - Now owns cstdint.hpp, including tests and documentation Boost.Core - All relevant headers are available in boost/core, I can remove empty_deleter.hpp if we don't want it there - All documentation converted to QuickBook and viewable at http://boostorg.github.io/core/ - Updated documentation for lightweight_test a bit

I'll get to ref() next, and then get to moving other pieces to Boost.Core.

Just wanted to share with you folks that reading this thread has made me very happy so far. :-)

Same from me. I'm impressed that Boost (the community) is now doing this. I'm also deliberately not involved (for now) to let you get on with it :). Thanks, Steve.

Adam Wulkiewicz

2 Jun 2 Jun

8:18 p.m.

2014-06-01 3:54 GMT+02:00 Peter Dimov :

...

Andrey Semashev wrote:

...
Ok, let's give it a try and see what happens. :) First, we need a new submodule...

We have it, in develop.

I'm considering using Core (ignore_unused) in the other library. Should I wait for things to settle down? Or do you think it's not risky? Regards, Adam

Glen Fernandes

8:25 p.m.

On Mon, Jun 2, 2014 at 1:18 PM, Adam Wulkiewicz wrote:

...

I'm considering using Core (ignore_unused) in the other library. Should I wait for things to settle down? Or do you think it's not risky?

Regards, Adam

In develop? Go for it. Glen

Adam Wulkiewicz

3 Jun 3 Jun

10:41 a.m.

2014-06-02 22:25 GMT+02:00 Glen Fernandes :

...

On Mon, Jun 2, 2014 at 1:18 PM, Adam Wulkiewicz wrote:

...
I'm considering using Core (ignore_unused) in the other library. Should I wait for things to settle down? Or do you think it's not risky?

In develop? Go for it.

Will it be released in 1.56?

Peter Dimov

10:51 a.m.

Adam Wulkiewicz wrote: ...

...

...
...
I'm considering using Core (ignore_unused) in the other library. ...

...

Will it be released in 1.56?

It's on the master branch of core, so yes, it will be.

Beman Dawes

12:04 p.m.

On Tue, Jun 3, 2014 at 6:51 AM, Peter Dimov wrote:

...

Adam Wulkiewicz wrote: ...

...
...
I'm considering using Core (ignore_unused) in the other library.

...

Will it be released in 1.56?

...
It's on the master branch of core, so yes, it will be.

A FAQ might be helpful. Likely questions: Q. Are there breaking changes for Boost libraries? Q. Are there recommended (although not breaking) changes for Boost libraries? Q. Are there breaking changes for user code? Q. Are there recommended (although not breaking) changes for user code? --Beman

Andrey Semashev

12:19 p.m.

On Tue, Jun 3, 2014 at 4:04 PM, Beman Dawes wrote:

...

A FAQ might be helpful. Likely questions:

Q. Are there breaking changes for Boost libraries?

Q. Are there recommended (although not breaking) changes for Boost libraries?

Q. Are there breaking changes for user code?

Q. Are there recommended (although not breaking) changes for user code?

Not denying the FAQ usefulness, I can answer these questions. No breaking changes have been made, all the code that previously compiled should keep compiling. boost/utility/empty_deleter.hpp has been deprecated in favor of boost/core/null_deleter.hpp. Including the deprecated header will display warnings pointing to the new header. Eventually (not in 1.56 for sure) empty_deleter.hpp will be deleted. Implementation from all headers that were moved to Boost.Core is now in boost/core. The old headers now simply forward to the new ones (without warnings). It is recommended to include the new headers directly, although the changes are not necessary. I'm not sure if we're going to deprecate the old headers, but if we will, I'd say we should add warnings first to start the deprecation period.

Peter Dimov

12:21 p.m.

Beman Dawes wrote:

...

Q. Are there breaking changes for Boost libraries? Q. Are there breaking changes for user code?

A. Not yet, despite all the enthusiasm for such expressed by some. :-)

Mostafa

1 Jun 1 Jun

5:06 p.m.

On Sat, 31 May 2014 07:21:42 -0700, Peter Dimov wrote:

...

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities.

The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert).

Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful".

Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers.

The following utilities are immediate candidates for migration into the new module:

- addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp

In addition, the following can be duplicated inside to reduce dependencies:

- mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv

and so on.

How would this affect Boost users? Would they have to include "core/addressof" instead of "utility/addressof"?

Peter Dimov

5:34 p.m.

Mostafa wrote:

...

How would this affect Boost users? Would they have to include "core/addressof" instead of "utility/addressof"?

No, the header remains utility/addressof.hpp for now, it's just been moved to the core repository. We'll probably move it to core/addressof.hpp at some point so that libraries can use the more consistent #include, but the old header will remain and forward to the new one.

3916

Age (days ago)

3920

Last active (days ago)

List overview

Download

51 comments

10 participants

participants (10)

Adam Wulkiewicz
Andrey Semashev
Beman Dawes
Daniel James
Glen Fernandes
John Maddock
Julian Gonggrijp
Mostafa
Peter Dimov
Stephen Kelly