- Boost - lists.preview.boost.org

Re: [boost] [1.55.0] Release candidate 2 available
by Sergey Cheban 05 Nov '13

05 Nov '13

On 04.11.2013 4:00, Jeff Flinn wrote: > 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 see the same problem: ...failed compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_oprimitive.obj... compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_iprimitive.obj basic_text_iprimitive.cpp C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std' C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(134) : while compiling class template member function 'void boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<CharType>>,CharType>,8,6,CharType>::fill(void)' ...failed compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_woprimitive.obj... compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_wiprimitive.obj basic_text_wiprimitive.cpp C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std' C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(134) : while compiling class template member function 'void boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<CharType>>,CharType>,8,6,CharType>::fill(void)' basic_text_oprimitive.cpp .\boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std' .\boost/archive/iterators/transform_width.hpp(134) : while compiling class template member function 'void boost::archive::iterators::transform_width<const char *,6,8,char>::fill(void)' ...failed updating 8 targets... ...skipped 8 targets... ...updated 1080 targets... -- Sergey Cheban

1 0

[modularization] Improving/splitting up detail
by John Maddock 05 Nov '13

05 Nov '13

Lets say we wanted boost/detail to depend on nothing but config, here's what it would take: boost/detail/algorithm.hpp Used by graph lib only, suggest it's moved there. boost/detail/allocator_utilities.hpp Used by multi index, statechart and flyweight, suggest move to new "common" module. boost/detail/atomic_count.hpp Depends on smart_ptr's details only, suggest those details are moved to "detail" module. boost/detail/binary_search.hpp Used by python and test, move to "common". boost/detail/bitmask.hpp Only external dependency is boost/cstdint.hpp, either move to "common", or else move cstdint.hpp to "config". boost/detail/call_traits.hpp Move to call_traits (should be there already). boost/detail/catch_exceptions.hpp Only external dependency is boost/cstdint.hpp, suggest latter is moved to config. boost/detail/compressed_pair.hpp Move to compressed pair (should be there already). boost/detail/endian.hpp Move to "predef" boost/detail/has_default_constructor.hpp File appears to be unused, and not very useful, suggest we remove it. boost/detail/identifier.hpp File appears to be unused, suggest we remove it. boost/detail/indirect_traits.hpp Used by iterator and python, move to "common" boost/detail/is_incrementable.hpp Move to common, or better modify the libraies using this to use the newer type_traits equivalents. boost/detail/is_sorted.hpp Used by graph and range, move to "common" boost/detail/is_xxx.hpp Used by parameter and python, move to "common" boost/detail/iterator.hpp I suspect this may be obsolete now compiler requirements have been bumped, but whatever it's still used by multiple libs: move to "common" boost/detail/lcast_precision.hpp Only used by lexical_cast, move it there. boost/detail/lightweight_mutex.hpp Only extern dependency is smart_ptr's details, suggest move those to detail. boost/detail/named_template_params.hpp Appears to be unused, suggest we remove. boost/detail/numeric_traits.hpp Used by graph and iterator, move to "common" boost/detail/ob_compressed_pair.hpp Move to compressed pair, might also be obsolete by now. boost/detail/quick_allocator.hpp Only external dependency is smart_ptr's details, suggest those are moved here. Or since only serialization uses this, move this file there... boost/detail/reference_content.hpp Used by optional and variant, move to "common". boost/detail/winapi/* Depends on boost/cstdint.hpp only, suggest that belongs to config. Everything else in detail has no dependencies other than config. Thoughts? John.

11 22

Re: [boost] [Trac] Catch-22: Captcha Errors on legitimate submissions (fwd)
by DongInn Kim 04 Nov '13

04 Nov '13

Hi, I have looked into the trac admin page to see if there is anything useful for this issue and I found that the current Jim Bell’s tickets and comments were filtered out as a spam. http://www.crest.iu.edu/~dikim/spamfilter.png The spamfilter on trac is not perfect. It just filters out anything if they meet some criteria that the filter setup. I have not setup the filter criteria (Yes, I have installed the spam filter as you guys requested). It seems that it needs to train the spam filter with some admin’s interaction on the filtered tickets as a spam or ham. I just tried to make four Jim Bell’s ticket/comments selected as a ham. I hope the spam filter does a little better job on Jim Bell’s ticket next time. The following users are the admin of the boost trac system and I hope that they need to train the spam filter from time to time in case this kind of incidents happen. az_sw_dude admin bemandawes admin dave admin dgregor admin eric_niebler admin grafik admin johnmaddock admin marshall admin -PS- I do not follow this mailing list. If someone forwards an email to me like this, I can see what happens. Regards, -- - DongInn On Nov 1, 2013, at 9:35 PM, Jeremiah Willcock <jewillco(a)crest.iu.edu> wrote: > > > ---------- Forwarded message ---------- > From: Jim Bell <Jim(a)JC-Bell.com> > To: boost(a)lists.boost.org > Date: Fri, 01 Nov 2013 18:25:01 -0500 > Subject: [boost] [Trac] Catch-22: Captcha Errors on legitimate submissions > Reply-To: boost(a)lists.boost.org > X-perlmx-spam: Gauge=X, Probability=10%, Report=' > TO_IN_SUBJECT 0.5, REPLYTO_FROM_DIFF_ADDY 0.1, HTML_00_01 0.05, > HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, > BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, > BODY_SIZE_700_799 0, DATE_TZ_NA 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, > __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_LIST_HEADER 0, > __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, > __HAS_MSGID 0, __HAS_REPLYTO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, > __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __SANE_MSGID 0, > __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, > __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' > > I had a ticket attachment and comment both rejected from a "captcha error," so I decided to open a Trac ticket on the captcha mechanism itself. But guess what? THAT ticket was also rejected by the captcha error. Catch-22! > > So I'm posting it here. > > I get: > -------------------------------- > Captcha Error > Submission rejected as potential spam (StopForumSpam says this is spam (username)) > > Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following. > -------------------------------- > > But there's nothing following to which to provide a response. Is it mis-configured? > > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 4

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

04 Nov '13

On 3 Nov 2013 at 9:08, Robert Ramey wrote: > I don't think it's a great idea for a library author to make the > requirements for using his library more stringent than is absolutely > necessary. I generally agree. With the exception of features specified to be part of the C++ language standard. Those any C++ codebase has the right to assume are always available. > The way BOOST_EXCEPTION used to be was correct - Implemented as a throw if > the platform supported it, and calling some defined function if the > platform doesn't support them. This actually works well when exceptions > are not used as part of the code logic but only to handle "error > conditions". This practice is generally recommended and many follow it. > In this context, there's not reason not couple one's library to the > existence of RTTI or an related compiler feature. I think my personal difficulty here is that lack of RTTI can be worked around (e.g. Boost.TypeIndex), whereas presence or lack of exceptions means completely different design of a C++ codebase, with a non-exception safe design being utterly and more importantly permanently defective when used in the presence of exceptions - a rather important distinction. I can certainly see that by ruling out exception safety during design that one can get code to market quicker - assuming that one does not save significant implementation time by making use of libraries which assume exceptions work (e.g. the C++11 STL), because as soon as you mix in exception assuming code with non-exception capable code you have interop problems. > "it was/is an interesting choice by a large, modern, non-embedded C++ > use case." > > I think that boost should provide more support for embedded systems - not > less. I agree in the sense that hard realtime use cases for Boost where there is guaranteed worst case execution times is incredibly important, and indeed for those cases where Boost.TypeIndex can replace RTTI it will eliminate RTTI's unbounded execution times. That makes exception throwing the only unbounded worst case execution time scenario remaining. There is nothing about an embedded system that implies exceptions ought to be disabled though, especially with any semi-recent compiler and that your codebase isn't regularly throwing exceptions while it runs. You do tend to lose a register and use more stack space in code generation, but a reasonably modern bottom end embedded CPU is fairly tolerant of that nowadays thanks to having at least a L1 cache which hides a lot of the consequences of extra but unused stack usage. It's not like on 6502 with its three registers incapable of even burst read/writes to RAM for sure, or even an ARM v2 where stack writes across RAM page line boundaries stalled the CPU. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

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

04 Nov '13

Hi, I would like to merge if possible this fix https://svn.boost.org/trac/boost/changeset/86547 for this bug https://svn.boost.org/trac/boost/ticket/9337 . The bug was introduced on [75920] <https://svn.boost.org/trac/boost/changeset/75920>, so long time ago :( Please let me know. Vicente

3 4

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

[Trac] Catch-22: Captcha Errors on legitimate submissions
by Jim Bell 01 Nov '13

01 Nov '13

I had a ticket attachment and comment both rejected from a "captcha error," so I decided to open a Trac ticket on the captcha mechanism itself. But guess what? THAT ticket was also rejected by the captcha error. Catch-22! So I'm posting it here. I get: -------------------------------- Captcha Error Submission rejected as potential spam (StopForumSpam says this is spam (username)) Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following. -------------------------------- But there's nothing following to which to provide a response. Is it mis-configured?

1 0

[modularization] Dependency to Boost.Exception unavoidable?
by Daniel Pfeifer 01 Nov '13

01 Nov '13

2013/11/1 Peter Dimov <lists(a)pdimov.com>: > > ->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

4 9

[git] open an "admin" link doesn't works
by Vicente J. Botet Escriba 01 Nov '13

01 Nov '13

Hi, I tried to gain write access to a particular Boost library but the link *open an "admin"* issue <https://github.com/boostorg/admin/issues> in https://svn.boost.org/trac/boost/wiki/ModAdmin . doesn't works for me. Could someone help me? Vicente

8 10

Re: [boost] [Boost-users] [1.55.0] Release candidates available
by Tom Kent 01 Nov '13

01 Nov '13

On Fri, Nov 1, 2013 at 2:12 AM, Craig Henderson <hello(a)craighenderson.co.uk>wrote: > > > On 1 Nov 2013, at 00:29, Lars Viklund <zao(a)acc.umu.se> wrote: > > > >> On Thu, Oct 31, 2013 at 10:38:22PM +0000, Craig Henderson wrote: > >> Compiling x64 with vc12 (MSVS2012) using the command below, I get 33 > failed > >> targets. I reran the build to get a reduced log, which is attached. > >> > >> b2 --build-dir=bin.x64 stage --build-type=complete variant=release,debug > >> address-model=64 link=shared,static runtime-link=shared,static > >> threading=multi > >> > >> All the errors seems to be with transform_width.hpp: > >> .\boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min' > : > >> is not a member of 'std' > > > > This took months to fix on trunk, where it's fixed, but the author has > > yet to bother/get-around merging it to release. > > > > The trunk has other build problems, but this one seems fixed, yes. > MSVS2013 is an important compiler to support. > So, is there going to be an _rc2 for this and the bcp problem? Tom

1 0

[config] including typeinfo in dinkumware.hpp when RTTI is disabled
by Edward Diener 01 Nov '13

01 Nov '13

Evidently the only way to currently compile clang on Windows using the VC++ RTL is to compile without RTTI and exception handling in its VC++ emulation ( options -D_HAS_EXCEPTIONS=0 /GR- ). This may be totally unrealistic for Boost. Nonetheless with these compiler options, when the dinkumware.hpp is being used by Boost config, it is including typeinfo and this is causing a problem: c:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\typeinfo(156,10) : error: unknown class name 'exception'; did you mean '_exception'? : public exception Is it realistic in dinkumware.hpp to not include typeinfo if RTTI is not enabled ? Or is it just more realistic to say that compiling Boost libraries with RTTI disabled is not going to work ?

4 9

[git help] Cloning the boost git repository recursively seems to have issues.
by Cox, Michael 01 Nov '13

01 Nov '13

On Wed, Oct 30, 2013 at 11:16 PM, <boost-request(a)lists.boost.org> wrote: > Date: Wed, 30 Oct 2013 23:31:25 +0100 > From: Daniel Pfeifer <daniel(a)pfeifer-mail.de> > To: Boost Developers List <boost(a)lists.boost.org> > Cc: Mike <mhcox(a)bluezoosoftware.com> > Subject: [boost] [git help] Cloning the boost git repository > recursively seems to have issues. > Message-ID: > <CANZMcXrkLdL7-ax9CUnaySwJB4-=fSt3n627n3bdj_LF0Yp-KA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Mike, > > Thanks for reporting that issue. > Migration if Boost to modularized Git has been decoupled from Ryppl. > I forward your message to the Boost Developers List. > > -- Daniel > > ---------- Forwarded message ---------- > From: Mike <mhcox(a)bluezoosoftware.com> > Date: 2013/10/29 > Subject: [ryppl-dev] Cloning the boost git repository recursively > seems to have issues. > To: ryppl-dev(a)googlegroups.com > > > I ran the following git command to retrieve the latest modularized > boost code in github.com/boostorg: > > $ git clone --recursive https://github.com/boostorg/boost > > The boost repository and all its submodules were recursively cloned as > expected, but bootstrap.bat in the boost repository and some library > submodules were marked as modified. Not what I expected. I ran the > following command to get a list of the modified files in the > submodules: > $ git submodule foreach --recursive 'git status --short' > > I got the following output: > Entering 'libs/accumulators' > Entering 'libs/algorithm' > Entering 'libs/any' > ... > Entering 'libs/geometry' > M example/ml02_distance_strategy.cpp > Entering 'libs/gil' > ... > Entering 'libs/interprocess' > M proj/vc7ide/doc_managed_grow.vcproj > M proj/vc7ide/managed_shared_memory.vcproj > M proj/vc7ide/offset_ptr_test.vcproj > Entering 'libs/intrusive' > M proj/vc7ide/avl_multiset/avl_multiset.vcproj > M proj/vc7ide/avl_set/avl_set.vcproj > M proj/vc7ide/sg_multiset/sg_multiset.vcproj > M proj/vc7ide/sg_set/sg_set.vcproj > M proj/vc7ide/splay_multiset/splay_multiset.vcproj > M proj/vc7ide/splay_set/splay_set.vcproj > Entering 'libs/io' > ... > Entering 'libs/math' > M doc/equations/gamm1.svg > M doc/equations/gamm2.svg > M doc/equations/gamm3.svg > M doc/equations/gamm4.svg > M doc/equations/gamm5.svg > M doc/equations/gamma_dist_ref1.svg > M doc/equations/gamma_dist_ref2.svg > M doc/equations/gamma_ratio0.svg > M doc/equations/gamma_ratio1.svg > M doc/equations/hankel1.svg > M doc/equations/hankel2.svg > M doc/equations/hankel3.svg > M doc/equations/hankel4.svg > M doc/equations/hankel5.svg > M doc/equations/hazard.svg > M doc/equations/hermite_0.svg > M doc/equations/hermite_1.svg > M doc/equations/hypergeometric1.svg > M doc/equations/hypergeometric2.svg > M doc/equations/hypergeometric3.svg > M doc/equations/hypergeometric4.svg > M doc/equations/hypergeometric5.svg > M doc/equations/hypergeometric6.svg > M doc/equations/hypot.svg > M doc/equations/hypot2.svg > M doc/equations/ibeta1.svg > M doc/equations/ibeta10.svg > M doc/equations/ibeta11.svg > M doc/equations/ibeta12.svg > M doc/equations/ibeta2.svg > M doc/equations/ibeta3.svg > M doc/equations/ibeta4.svg > M doc/equations/ibeta5.svg > M doc/equations/ibeta6.svg > M doc/equations/ibeta7.svg > M doc/equations/ibeta8.svg > M doc/equations/ibeta9.svg > M doc/equations/ibeta_inv1.svg > M doc/equations/ibeta_inv2.svg > M doc/equations/ibeta_inv3.svg > M doc/equations/ibeta_inv4.svg > M doc/equations/ibeta_inv5.svg > M doc/equations/ibeta_inv6.svg > M doc/equations/ibeta_inv7.svg > M doc/equations/ibeta_inv8.svg > M doc/equations/igamma1.svg > M doc/equations/igamma10.svg > M doc/equations/igamma11.svg > M doc/equations/igamma11b.svg > M doc/equations/igamma12.svg > M doc/equations/igamma13.svg > M doc/equations/igamma16.svg > M doc/equations/igamma17.svg > M doc/equations/igamma18.svg > M doc/equations/igamma19.svg > M doc/equations/igamma1f.svg > M doc/equations/igamma2.svg > M doc/equations/igamma2f.svg > M doc/equations/igamma3.svg > M doc/equations/igamma4.svg > M doc/equations/igamma5.svg > M doc/equations/igamma6.svg > M doc/equations/igamma7.svg > M doc/equations/igamma8.svg > M doc/equations/igamma9.svg > M doc/equations/jacobi1.svg > M doc/equations/jacobi2.svg > M doc/equations/jacobi3.svg > M doc/equations/jacobi4.svg > M doc/equations/laguerre_0.svg > M doc/equations/laguerre_1.svg > M doc/equations/laguerre_2.svg > M doc/equations/laguerre_3.svg > M doc/equations/lanczos0.svg > M doc/equations/lanczos0a.svg > M doc/equations/lanczos0b.svg > M doc/equations/lanczos1.svg > M doc/equations/lanczos2.svg > M doc/equations/lanczos3.svg > M doc/equations/lanczos4.svg > M doc/equations/lanczos5.svg > M doc/equations/lanczos6.svg > M doc/equations/lanczos7.svg > M doc/equations/laplace_pdf.svg > M doc/equations/legendre_0.svg > M doc/equations/legendre_1.svg > M doc/equations/legendre_1b.svg > M doc/equations/legendre_2.svg > M doc/equations/legendre_3.svg > M doc/equations/legendre_4.svg > M doc/equations/legendre_5.svg > M doc/equations/lgamm1.svg > M doc/equations/lgamm2.svg > M doc/equations/lgamm3.svg > M doc/equations/lgamm4.svg > M doc/equations/lgamm5.svg > M doc/equations/lgamm6.svg > M doc/equations/log1pseries.svg > M doc/equations/lognormal_ref.svg > M doc/equations/mbessel1.svg > M doc/equations/mbessel10.svg > M doc/equations/mbessel11.svg > M doc/equations/mbessel12.svg > M doc/equations/mbessel13.svg > M doc/equations/mbessel14.svg > M doc/equations/mbessel15.svg > M doc/equations/mbessel16.svg > M doc/equations/mbessel17.svg > M doc/equations/mbessel2.svg > M doc/equations/mbessel3.svg > M doc/equations/mbessel4.svg > M doc/equations/mbessel5.svg > M doc/equations/mbessel6.svg > M doc/equations/mbessel7.svg > M doc/equations/mbessel8.svg > M doc/equations/mbessel9.svg > M doc/equations/nc_beta_ref1.svg > M doc/equations/nc_beta_ref2.svg > M doc/equations/nc_beta_ref3.svg > M doc/equations/nc_beta_ref4.svg > M doc/equations/nc_chi_squ_ref1.svg > M doc/equations/nc_chi_squ_ref2.svg > M doc/equations/nc_chi_squ_ref3.svg > M doc/equations/nc_chi_squ_ref4.svg > M doc/equations/nc_chi_squ_ref5.svg > M doc/equations/nc_chi_squ_ref6.svg > M doc/equations/nc_chi_squ_ref7.svg > M doc/equations/nc_f_ref1.svg > M doc/equations/nc_f_ref2.svg > M doc/equations/nc_t_ref1.svg > M doc/equations/nc_t_ref2.svg > M doc/equations/nc_t_ref3.svg > M doc/equations/nc_t_ref4.svg > M doc/equations/nc_t_ref5.svg > M doc/equations/neg_binomial_ref.svg > M doc/equations/normal_ref1.svg > M doc/equations/poisson_ref1.svg > M doc/equations/roots1.svg > M doc/equations/roots2.svg > M doc/equations/roots3.svg > M doc/equations/roots4.svg > M doc/equations/sbessel1.svg > M doc/equations/sbessel2.svg > M doc/equations/sbessel3.svg > M doc/equations/sbessel4.svg > M doc/equations/sbessel5.svg > M doc/equations/special_functions_blurb1.svg > M doc/equations/special_functions_blurb15.svg > M doc/equations/special_functions_blurb17.svg > M doc/equations/special_functions_blurb18.svg > M doc/equations/special_functions_blurb20.svg > M doc/equations/special_functions_blurb22.svg > M doc/equations/special_functions_blurb5.svg > M doc/equations/special_functions_blurb6.svg > M doc/equations/special_functions_blurb7.svg > M doc/equations/spherical_0.svg > M doc/equations/spherical_1.svg > M doc/equations/spherical_2.svg > M doc/equations/spherical_3.svg > M doc/equations/students_t_dist.svg > M doc/equations/students_t_ref1.svg > M doc/equations/zeta1.svg > M doc/equations/zeta2.svg > M doc/equations/zeta3.svg > M doc/equations/zeta4.svg > M doc/equations/zeta5.svg > M doc/equations/zeta6.svg > M doc/graphs/acosh.svg > M doc/graphs/airy_ai.svg > M doc/graphs/airy_aip.svg > M doc/graphs/airy_bi.svg > M doc/graphs/airy_bip.svg > M doc/graphs/asinh.svg > M doc/graphs/atanh.svg > M doc/graphs/bernoulli_cdf.svg > M doc/graphs/bernoulli_pdf.svg > M doc/graphs/beta.svg > M doc/graphs/beta_pdf.svg > M doc/graphs/binomial_pdf_1.svg > M doc/graphs/binomial_pdf_2.svg > M doc/graphs/cauchy_pdf1.svg > M doc/graphs/cauchy_pdf2.svg > M doc/graphs/cbrt.svg > M doc/graphs/chi_squared_pdf.svg > M doc/graphs/cyl_bessel_i.svg > M doc/graphs/cyl_bessel_j.svg > M doc/graphs/cyl_bessel_k.svg > M doc/graphs/cyl_neumann.svg > M doc/graphs/digamma.svg > M doc/graphs/ellint_1.svg > M doc/graphs/ellint_2.svg > M doc/graphs/ellint_3.svg > M doc/graphs/ellint_carlson.svg > M doc/graphs/erf.svg > M doc/graphs/erf_inv.svg > M doc/graphs/erfc.svg > M doc/graphs/erfc_inv.svg > M doc/graphs/expint2.svg > M doc/graphs/expint_i.svg > M doc/graphs/expm1.svg > M doc/graphs/exponential_pdf.svg > M doc/graphs/extreme_value_pdf1.svg > M doc/graphs/extreme_value_pdf2.svg > M doc/graphs/fisher_f_pdf.svg > M doc/graphs/gamma1_pdf.svg > M doc/graphs/gamma2_pdf.svg > M doc/graphs/gamma_p.svg > M doc/graphs/gamma_q.svg > M doc/graphs/hermite.svg > M doc/graphs/hypergeometric_pdf_1.svg > M doc/graphs/hypergeometric_pdf_2.svg > M doc/graphs/ibeta.svg > M doc/graphs/jacobi_cd.svg > M doc/graphs/jacobi_cn.svg > M doc/graphs/jacobi_cs.svg > M doc/graphs/jacobi_dc.svg > M doc/graphs/jacobi_dn.svg > M doc/graphs/jacobi_ds.svg > M doc/graphs/jacobi_nc.svg > M doc/graphs/jacobi_nd.svg > M doc/graphs/jacobi_ns.svg > M doc/graphs/jacobi_sc.svg > M doc/graphs/jacobi_sd.svg > M doc/graphs/jacobi_sn.svg > M doc/graphs/laguerre.svg > M doc/graphs/laplace_pdf.svg > M doc/graphs/legendre_p.svg > M doc/graphs/legendre_q.svg > M doc/graphs/lgamma.svg > M doc/graphs/log1p.svg > M doc/graphs/logistic_pdf.svg > M doc/graphs/lognormal_pdf1.svg > M doc/graphs/lognormal_pdf2.svg > M doc/graphs/nc_beta_pdf.svg > M doc/graphs/nc_f_pdf.svg > M doc/graphs/nc_t_pdf.svg > M doc/graphs/nccs_pdf.svg > M doc/graphs/negative_binomial_pdf_1.svg > M doc/graphs/negative_binomial_pdf_2.svg > M doc/graphs/normal_pdf.svg > M doc/graphs/pareto_pdf1.svg > M doc/graphs/pareto_pdf2.svg > M doc/graphs/poisson_pdf_1.svg > M doc/graphs/powm1.svg > M doc/graphs/rayleigh_cdf.svg > M doc/graphs/rayleigh_pdf.svg > M doc/graphs/sinc_pi.svg > M doc/graphs/sinhc_pi.svg > M doc/graphs/sph_bessel.svg > M doc/graphs/sph_neumann.svg > M doc/graphs/sqrt1pm1.svg > M doc/graphs/students_t_pdf.svg > M doc/graphs/tgamma.svg > M doc/graphs/tgamma_delta_ratio.svg > M doc/graphs/triangular_cdf.svg > M doc/graphs/triangular_pdf.svg > M doc/graphs/uniform_cdf.svg > M doc/graphs/uniform_pdf.svg > M doc/graphs/weibull_pdf1.svg > M doc/graphs/weibull_pdf2.svg > M doc/graphs/zeta1.svg > M doc/graphs/zeta2.svg > Entering 'libs/move' > ... > Entering 'libs/multiprecision' > M doc/floating_point_eg1.svg > M doc/floating_point_eg2.svg > M doc/floating_point_eg3.svg > Entering 'libs/numeric/conversion' > ... > Entering 'libs/pool' > M doc/images/mb1.svg > M doc/images/mb2.svg > M doc/images/mb3.svg > M doc/images/mb4.svg > M doc/images/pc1.svg > M doc/images/pc2.svg > M doc/images/pc3.svg > M doc/images/pc4.svg > M doc/images/pc5.svg > Entering 'libs/predef' > ... > Entering 'tools/inspect' > Entering 'tools/litre' > Entering 'tools/quickbook' > > All the "modified" files appear to be .bat, .vcproj, and .svg files > (although there was one file, example/ml02_distance_strategy.cpp in > libs/geometry). I thought it might be a problem with .gitattributes > files. When I looked at them, I noticed an unfamiliar attribute, > svneol=native. I expected to find eol=crlf for the .bat and .vcproj > files. I don't have autocrlf or safecrlf set in my ~.gitconfig file > (should I?). What is the svneol attribute? What am I missing? > > -- Some more info that I should have included: - Fedora 20 - git version 1.8.3.1 Mike

3 5

[1.55.0] Release candidates available
by Marshall Clow 01 Nov '13

01 Nov '13

Release candidate 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: ba1ae723b8b4d1edeca684bb14b3213b *boost_1_55_0_rc1.tar.gz 66e01be2f328c556835c42be7b6d17d5 *boost_1_55_0_rc1.tar.bz2 925bb6c96082033687e5742b4e77af7b *boost_1_55_0_rc1.zip 830d61075ecf7d5ebf7c0843033393bf *boost_1_55_0_rc1.7z Thanks! -- The release managers

8 9

[Serialization] - [1.55] vs2013 compiler error - tickets #9279/#8750
by Jeff Flinn 01 Nov '13

01 Nov '13

Robert can this be merged to release? This is ticket #9279/#8750. Just checking that this gets into the release. Is that the case? Thanks, Jeff

1 0

Re: [boost] [git help] GitHub boostorg library authentication
by Cox, Michael 31 Oct '13

31 Oct '13

On Wed, Oct 30, 2013 at 12:00 AM, <boost-request(a)lists.boost.org> wrote: > > Date: Tue, 29 Oct 2013 21:03:01 -0700 > From: Dave Abrahams <dave(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [git help] GitHub boostorg library authentication > Message-ID: <m27gcv76dm.fsf(a)papi.luannocracy.com> > Content-Type: text/plain > > Daniel Pfeifer <daniel(a)pfeifer-mail.de> writes: > > > 2013/10/29 Daniel James <daniel(a)calamity.org.uk>: > >> On 29 October 2013 04:36, Dave Abrahams <dave(a)boostpro.com> wrote: > >>> > >>>> The super-project can't use github's git urls as they don't > >>>> allow anonymous access. I believe the super-project should be using > >>>> https for submodules, rather than http. > >>> > >>> Why is that? Because it's possible to commit through https? > >> > >> Yes. > >> > >>> But won't someone complain that they can't access https behind their > >>> corporate firewall? It always seems like there's no right answer in > >>> this territory. > >> > >> Oh right, I hadn't thought of that. Making it easy to check out > >> probably should be the priority. > > > > I am behind a corporate firewall and I cannot access git repositories > > through ssh. > > https works in both directions (pull and push). > > Yes, different corporate firewalls block different protocols. But I'm > happy to change to https if everyone believes that will work better > overall. In the .gitmodules file you can use relative urls, e.g. [submodule "smart_ptr"] path = libs/smart_ptr url = ../smart_ptr # url = http://github.com/boostorg/smart_ptr.git fetchRecurseSubmodules = on-demand The protocol used to access the super-project boost is what will be used to retrieve the submodule projects. This might help with issues accessing the repositories, although the super-project will have to accessed via http/https (or whatever ports are open through the firewall). This also makes the whole repository structure relocatable, e.g. a development team using boost can clone all the repositories to their local development server without having to modify the .gitmodules file in the boost super-project. Unfortunately, there's no good way I'm aware of to clone all the repositories as bare repositories. Maybe the latest changes in how git submodules are stored (i.e. under .git/modules) will help. Michael

2 1

Fwd: [Boost-users] [test] floating point comparison
by Matthijs Möhlmann 31 Oct '13

31 Oct '13

Hello all, I already posted this to the boost users list, because I thought it was a problem in my code, but I think its a bug in boost test (unit tests) Versions: Boost: 1.54 GCC: 4.8.1 Does someone have an answer to this? -------- Original Message -------- Subject: [Boost-users] [test] floating point comparison Date: Wed, 30 Oct 2013 14:40:07 +0100 From: Matthijs Möhlmann <matthijs(a)cacholong.nl> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org Hello all, I've the following test program: #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #define BOOST_TEST_MODULE Master test suite #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(TestCase) { BOOST_REQUIRE_CLOSE_FRACTION(45.00f, 45.17f, 0.004f); } When I compile it with the following line: g++ -o main.o -c -Werror -Wall -std=c++11 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_SPIRIT_USE_PHOENIX_V3 -DUTEST -g main.cpp g++ -o main main.o -lboost_unit_test_framework I get the following output: Running 1 test case... *** No errors detected If I lower the tolerance to 0.0004f then I'll get the following: Running 1 test case... main.cpp(8): fatal error in "TestCase": difference{0.00376352} between 45.00f{45} and 45.17f{45.1699982} exceeds 0.00039999999 *** 1 failure detected in test suite "Master test suite" Why does it say that the difference is 0.00376352 and not 0.17....... ? Regards, Matthijs Möhlmann _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2