November 2013 - Boost - lists.preview.boost.org

Re: [boost] [modularization] Improving/splitting up detail
by Ahmed Charles 04 Nov '13

04 Nov '13

Then call them modules, tell users that libraries are made of modules and that's it. The fact that most libraries have a module called core or detail that is shared with most other libraries is utterly irrelevant to users. The fact that this allows them to use libraries while downloading and installing less other libraries is useful. ________________________________ From: Daniel Pfeifer Sent: 11/2/2013 12:23 AM To: Boost Developers List Subject: Re: [boost] [modularization] Improving/splitting up detail 2013/11/2 Ahmed Charles <acharles(a)outlook.com>: > > >> Date: Fri, 1 Nov 2013 22:34:07 +0000 >> From: daniel(a)calamity.org.uk >> To: boost(a)lists.boost.org >> Subject: Re: [boost] [modularization] Improving/splitting up detail >> >> On 1 November 2013 22:10, Daniel Pfeifer <daniel(a)pfeifer-mail.de> wrote: >> >> >> >> boost/detail/xxx.hpp >> >> >> >> Used by YYY and ZZZ, move to "common" >> > >> > Isn't there already a dependency from YYY to ZZZ? Could we put xxx.hpp >> > to ZZZ instead? Maybe a "common" is not even needed. >> >> We should be careful about making changes just because they fit the >> current dependencies. Dependencies are not constant, we don't want to >> be in a situation where the dependency graph falls apart because of a >> future change to one of these headers. Also, if a header is in detail >> it should be potentially useful for future libraries which wouldn't >> want to depend on ZZZ (if it isn't, then it shouldn't have been put in >> detail in the first place). > > The goal is to create two 'modules' or libraries: We had that originally. They were called "detail" and "core". How do we describe those libraries to users? Those might be the Frequently Questioned Answers: A: It is a Boost library that you should not use. Q: If it is not useful, why does it exist? A: It is used internally by several Boost libraries. Q: If it is so useful, why should I not use it too? I prefer to have no such "detail" libraries at all. Everything that is useful to a broader audience should be in utility. Everything else should be an implementation detail of one library. When one library depends on the implementation detail of another library (ie. includes a 'detail' header from it), that is a smell, OK. But at least it is hidden from users. -- Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[config] clang deleted functions bugged
by Vicente J. Botet Escriba 04 Nov '13

04 Nov '13

Hi, Clang has a bug with deleted functions (see http://stackoverflow.com/questions/7754564/clang-error-message-when-using-c…) Please, could we comment these two lines until clang fixes the bug //#if !__has_feature(cxx_deleted_functions) # define BOOST_NO_CXX11_DELETED_FUNCTIONS //#endif Thanks, Vicente

3 8

Re: [boost] [Boost-users] [1.55.0] Release candidate 2 available
by Tom Kent 04 Nov '13

04 Nov '13

On Sun, Nov 3, 2013 at 6:00 PM, Jeff Flinn <Jeffrey.Flinn(a)gmail.com> wrote: > On 11/3/2013 6:05 PM, Marshall Clow wrote: > >> >> On Nov 3, 2013, at 2:25 PM, Tom Kent <lists(a)teeks99.com >> <mailto:lists@teeks99.com>> wrote: >> >> On Sun, Nov 3, 2013 at 3:15 PM, Marshall Clow <mclow.lists(a)gmail.com >>> <mailto:mclow.lists@gmail.com>> wrote: >>> >>> RC2 files for 1.55.0 are available at >>> http://boost.cowic.de/rc/ >>> >>> 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. >>> >>> This helps ensure the candidates build OK before we push them out >>> to SourceForge. >>> >>> The files (and associated md5s) are: >>> 93780777cfbf999a600f62883bd54b17 >>> *boost_1_55_0_rc2.tar.gz >>> d6eef4b4cacb2183f2bf265a5a03a354 >>> *boost_1_55_0_rc2.tar.bz2 >>> 8aca361a4713a1f491b0a5e33fee0f1f >>> *boost_1_55_0_rc2.zip >>> 4e5bbc15fc8c80df8be428f8a5b5a823 *boost_1_55_0_rc2.7z >>> >>> >>> Thanks! >>> >>> -- The release managers >>> >>> >>> When is the release expected? (How long do we have to try building?) >>> >> >> We try to ship an RC on Wednesday, then release on Monday. >> If there are no problems found in this RC, I expect we'll release on >> Friday or Saturday. >> > > Serialization still fails to build on VS2013. This is due to tickets > #9279/#8750 not being merged to release from trunk. Robert sent me a direct > email saying "See my previous post on this thread to see why we're stuck > here." but I've not been able to figure out to what he's referring. > > Jeff I'm also seeing the serialization failures with msvc-12.0. Tom

2 1

Re: [boost] [Boost-users] [1.55.0] Release candidate 2 available
by Marshall Clow 04 Nov '13

04 Nov '13

On Nov 3, 2013, at 4:00 PM, Jeff Flinn <jeffrey.flinn(a)gmail.com> wrote: > On 11/3/2013 6:05 PM, Marshall Clow wrote: >> >> On Nov 3, 2013, at 2:25 PM, Tom Kent <lists(a)teeks99.com >> <mailto:lists@teeks99.com>> wrote: >> >>> On Sun, Nov 3, 2013 at 3:15 PM, Marshall Clow <mclow.lists(a)gmail.com >>> <mailto:mclow.lists@gmail.com>> wrote: >>> >>> RC2 files for 1.55.0 are available at >>> http://boost.cowic.de/rc/ >>> >>> 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. >>> >>> This helps ensure the candidates build OK before we push them out >>> to SourceForge. >>> >>> The files (and associated md5s) are: >>> 93780777cfbf999a600f62883bd54b17 >>> *boost_1_55_0_rc2.tar.gz >>> d6eef4b4cacb2183f2bf265a5a03a354 >>> *boost_1_55_0_rc2.tar.bz2 >>> 8aca361a4713a1f491b0a5e33fee0f1f *boost_1_55_0_rc2.zip >>> 4e5bbc15fc8c80df8be428f8a5b5a823 *boost_1_55_0_rc2.7z >>> >>> >>> Thanks! >>> >>> -- The release managers >>> >>> >>> When is the release expected? (How long do we have to try building?) >> >> We try to ship an RC on Wednesday, then release on Monday. >> If there are no problems found in this RC, I expect we'll release on >> Friday or Saturday. > > Serialization still fails to build on VS2013. This is due to tickets #9279/#8750 not being merged to release from trunk. Robert sent me a direct email saying "See my previous post on this thread to see why we're stuck here." but I've not been able to figure out to what he's referring. I think he was referring to this email: On Oct 31, 2013, at 9:44 AM, Robert Ramey <robertmacleranramey(a)gmail.com> wrote: > I've been trying to get these changes in. I grouped a number of the changes into one batch. I group them because it takes me a long time to test any changes. The fixes seemed simple, but to no one's surprise, they turned out to have some unexpected wrinkles. Right now I'm pending an answer to my recent question on the mailing list regarding TYPE_TRAIT deprecation. Once that gets done I would be ready to merge the trunk into the release. I don't think things are going to fall into place before 1.55 release though. It doesn't sound to me like he's ready to put those changes out into a release at this time. -- Marshall

1 0

[endian] status?
by Michael Marcin 04 Nov '13

04 Nov '13

I need to read/write some structs as binary data over an asio tcp socket and convert host<->network byte order. IIRC the endian library was supposed to clean this process up substantially but I can't find it. I thought it passed review years ago but I could be misremembering.

2 2

Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable?
by Emil Dotchevski 03 Nov '13

03 Nov '13

On Sat, Nov 2, 2013 at 5:19 PM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > On 1 Nov 2013 at 16:01, Emil Dotchevski wrote: > >> 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. > > I wonder how useful supporting exceptions disabled is in recent years? I agree that many Boost libraries are impractical with exception handling disabled, but there is no harm done in supporting BOOST_NO_EXCEPTIONS via boost::throw_exception, since its specification does not allow it to return. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[1.55] Request for permission to merge
by Vicente J. Botet Escriba 03 Nov '13

03 Nov '13

Hi, I would like to merge if it is possible this fix https://svn.boost.org/trac/boost/changeset/86540 for this bug https://svn.boost.org/trac/boost/ticket/9319. Please let me know. Vicente

4 5

Re: [boost] [modularization] Improving/splitting up detail
by Cox, Michael 03 Nov '13

03 Nov '13

On Sat, Nov 2, 2013 at 6:20 AM, <boost-request(a)lists.boost.org> wrote: > Date: Sat, 2 Nov 2013 08:20:02 -0400 > From: Rob Stewart <robertstewart(a)comcast.net> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] [modularization] Improving/splitting up detail > Message-ID: <57B4CEB2-A04B-4341-A613-39FB1A9D6AE3(a)comcast.net> > Content-Type: text/plain; charset=us-ascii > > On Nov 2, 2013, at 4:35 AM, "John Maddock" <john(a)johnmaddock.co.uk> wrote: > >>>> The goal is to create two 'modules' or libraries: >>> >>> We had that originally. They were called "detail" and "core". > [snip] >>> >>> I prefer to have no such "detail" libraries at all. Everything that is useful to a broader audience should be in utility. >> >> Funnily enough I was about to suggest just that: lets do away with detail and have: >> >> core: >> everything in: >> boost/detail/ >> boost/pending/ >> boost/utility/ >> That has no dependencies. What about config, or should that also go in core? >> >> Utility: >> As above, but with dependencies (mostly to mpl/pp/type_traits). >> >> throw_exception.hpp and dependencies should go in core too, as would a few headers under boost/ such as cstdint.hpp etc. > > That seems like a good idea provided that everything now in namespace detail remains in that namespace. > > > ___ > Rob > > (Sent from my portable computation engine) >

2 1

Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable?
by Niall Douglas 03 Nov '13

03 Nov '13

On 1 Nov 2013 at 16:01, Emil Dotchevski wrote: > 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. I wonder how useful supporting exceptions disabled is in recent years? Most recent C++ code assumes throwing exceptions works, and even games consoles which traditionally were very anti exceptions are beginning to weaken on this [1]. I also note that the C++ 11 standard library does a lot more exception throwing than the C++ 03 standard library, so it would surely be harder use C++ 11 with exceptions disabled. All this said, LLVM used to not use exceptions nor RTTI, and could be compiled with both disabled. No idea if this is still the case. Either way it was/is an interesting choice by a large, modern, non-embedded C++ use case. [1]: http://www.gamedev.net/topic/639123-portable-use-and-disabling-of-exceptions Niall

1 0

Concatenating int value to string ..??
by Rahul Mathur 02 Nov '13

02 Nov '13

All, I wish to have string (combination of string value and int value) which increments until 100. The code is as below - --- #include <iostream> #include <cstdlib> #include <string> #include <boost/lexical_cast.hpp> using namespace std; int main() { std::string TID = "Apple"; int TagID = 01, Value = 000 /* 100 IDs*/; std::string TagName, TagInitial, TagUId; TagName = TID + boost::lexical_cast<std::string>(TagID); // Should be as -> Apple01 TagInitial = TagName + boost::lexical_cast<std::string>(Value); // Should be as -> Apple01000 int i = boost::lexical_cast<int>(TagInitial) + 1; // Should be as -> Apple01001 TagUId = boost::lexical_cast<std::string>(i); std::cout << "Tag ID .." << TagUId << endl; } I get below error message - -- terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >' what(): bad lexical cast: source type value could not be interpreted as target Aborted (core dumped) -- Any clue? ~ Thanks!!

4 8