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.
On Sat, May 31, 2014 at 10:21 AM, Peter Dimov <lists@pdimov.com> 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).
+1
Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful".
+1
Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers.
+1
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
+1
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
On 31 May 2014 15:21, Peter Dimov <lists@pdimov.com> 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.
Daniel James wrote:
On 31 May 2014 15:21, Peter Dimov <lists@pdimov.com> 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.
On 31 May 2014 15:48, Peter Dimov <lists@pdimov.com> wrote:
Daniel James wrote:
On 31 May 2014 15:21, Peter Dimov <lists@pdimov.com> 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...
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
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?
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.
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. :-)
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...
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.
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.
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<void(), null_deleter> 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.
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).
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.
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.
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?
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.
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.
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<void(), null_deleter> 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.
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.
On Sun, 01 Jun 2014 08:34:01 -0700, Peter Dimov <lists@pdimov.com> 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.
On Sun, Jun 1, 2014 at 8:34 AM, Peter Dimov <lists@pdimov.com> 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
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.
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.
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
On 1 June 2014 18:39, John Maddock <boost.regex@virgin.net> 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.
On Sun, Jun 1, 2014 at 12:07 PM, Daniel James <dnljms@gmail.com> 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
Hi, 2014-06-01 3:54 GMT+02:00 Peter Dimov <lists@pdimov.com>:
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 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
On Sat, May 31, 2014 at 6:54 PM, Peter Dimov <lists@pdimov.com> 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
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. :-)
On Sun, Jun 1, 2014 at 1:44 PM, Peter Dimov <lists@pdimov.com> 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
On Mon, Jun 2, 2014 at 1:53 AM, Glen Fernandes <glen.fernandes@gmail.com> wrote:
On Sun, Jun 1, 2014 at 1:44 PM, Peter Dimov <lists@pdimov.com> 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
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 <boost/core/lightweight_test.hpp> 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.)
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
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.
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
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.
2014-06-01 3:54 GMT+02:00 Peter Dimov <lists@pdimov.com>:
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
2014-06-02 22:25 GMT+02:00 Glen Fernandes <glen.fernandes@gmail.com>:
On Mon, Jun 2, 2014 at 1:18 PM, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> 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?
On Tue, Jun 3, 2014 at 6:51 AM, Peter Dimov <lists@pdimov.com> 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
On Tue, Jun 3, 2014 at 4:04 PM, Beman Dawes <bdawes@acm.org> 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.
On Sat, 31 May 2014 07:21:42 -0700, Peter Dimov <lists@pdimov.com> 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"?
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.
participants (10)
-
Adam Wulkiewicz -
Andrey Semashev -
Beman Dawes -
Daniel James -
Glen Fernandes -
John Maddock -
Julian Gonggrijp -
Mostafa -
Peter Dimov -
Stephen Kelly