- Boost - lists.preview.boost.org

Boost.Application new version available.
by Renato Forti 14 Nov '13

14 Nov '13

Hi All, Last version (0.4.1) of Boost.Application are available. Documentation: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html Code: <https://github.com/retf/Boost.Application> https://github.com/retf/Boost.Application News in this release: * Now we have a self-pipe aspect ready to use for POSIX platform. The documentation of usage: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applic ation/posix_specifics.html#boost_application.posix_specifics.self_pipe_> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/posix_specifics.html#boost_application.posix_specifics.self_pipe_ The sample usage of aspect: <https://github.com/retf/Boost.Application/blob/master/libs/application/exam ple/selfpipe/selfpipe.cpp> https://github.com/retf/Boost.Application/blob/master/libs/application/examp le/selfpipe/selfpipe.cpp * Some fixes on code and docs. Please send your comments!

2 1

[1.55] PDF Documentation build available.
by John Maddock 14 Nov '13

14 Nov '13

The final PDF documentation build for Boost-1.55 is now available at https://sourceforge.net/projects/boost/files/boost-docs/1.55.0/ As ever this only contains documentation for the subset of Boost libraries that use quickbook/boostbook/docbook based documentation. Enjoy! John.

1 0

Is there any interest in a library which provides Application Environment using Aspect Based Design?
by Renato Forti 13 Nov '13

13 Nov '13

Hello everyone, I already asked that question, but how the library has changed a lot since the last inquiry. "Is there any interest in a library which provides Application Environment using Aspect Based Design?" Docs: <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html Code: https://github.com/retf/Boost.Application Please expose your interest!

2 1

[range] fat iterators?
by Eric Niebler 13 Nov '13

13 Nov '13

I wrote an article describing the "fat" std::istream_iterator and how it can be slimmed down by giving it an owning istream_range[1]. I see there already is an istream_range in Boost.Range, but it suffers from the fat-iterator problem I describe there. Is there a compelling reason why the implementation of boost::istream_range shouldn't be changed to be more like the one I describe? Also, as a commented pointed out, the same problem exists for the filtered range and the transformed range, too. The trick, of course, will be keeping intermediate temporary ranges alive long enough to avoid lifetime issues when we chain adaptors and assign the result to a local variable. I think a range library that's sensitive to the value category of range objects and makes copies of rvalue ranges would solve this problem. Thoughts? Is it time for Boost.Range 3.0? [1]: http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges -- Eric Niebler Boost.org http://www.boost.org

11 27

Re: [boost] [Functional/Factory] Value factory not accepts rvalues?
by THOMAS JORDAN 13 Nov '13

13 Nov '13

Lin, Yi-Li wrote: > I found that boost::value_factory did not accept rvalues > in some case. > In my case, temporary value is produced and passed to > value factory directly. The documentation for Boost Functional/Factory states: 'For technical reasons the arguments to the function objects have to be LValues. A factory that also accepts RValues can be composed using the boost::forward_adapter or boost::bind.' Your suggestion of using const lvalue (passing in non-const reference wrappers where needed) seems to be the workaround for the C++03 perfect forwarding problem that was employed by Boost smart_ptr::make_shared, not sure why Functional/Factory took a different approach? Tom.

1 0

forget delete detail/limits.hpp ?
by Akira Takahashi 13 Nov '13

13 Nov '13

Hi, I found boost/detail/limits.hpp file in Boost 1.55.0. However, already deleted from trunk. forget delete the file? -- >>======================== Akira Takahashi mailto:faithandbrave@gmail.com site: https://sites.google.com/site/faithandbrave/about/en

1 0

compile thread(boost1.55) fail on vc7.1
by shada 13 Nov '13

13 Nov '13

*bjam toolset=msvc-7.1 link=static threading=multi runtime-link=static --with-thread --with-chrono --with-date_time --includedir=hpp stage*>err.txt Component configuration: - atomic : not building - chrono : building - context : not building - coroutine : not building - date_time : building - exception : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - locale : not building - log : not building - math : not building - mpi : not building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : building - timer : not building - wave : not building ...patience... ...patience... ...found 1497 targets... ...updating 6 targets... compile-c-c++ bin.v2\libs\thread\build\msvc-7.1\debug\link-static\runtime-link-static\threading-multi\win32\thread.obj thread.cpp boost\functional\hash\hash.hpp(32) : warning C4616: #pragma warning : 警告编号“6295”超出范围，必须在“4001”和“4999“之间 boost\thread\future.hpp(1488) : error C2039: “make_future_async_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1638) : 参见对正在编译的类模板实例化“boost::unique_future<R>”的引用 boost\thread\future.hpp(1492) : error C2039: “make_future_deferred_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1683) : error C2039: “make_future_async_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1807) : 参见对正在编译的类模板实例化“boost::unique_future<boost::unique_future<R2>>”的引用 boost\thread\future.hpp(1687) : error C2039: “make_future_deferred_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1490) : error C2951: 模板声明只能在全局或者命名空间范围内使用 boost\thread\future.hpp(3695) : 参见对正在编译的类模板实例化“boost::unique_future<R>”的引用 with [ R=void ] boost\thread\future.hpp(1497) : error C2955: “boost::unique_future” : 使用类模板需要模板参数列表 boost\thread\future.hpp(1638) : 参见“boost::unique_future”的声明 boost\thread\future.hpp(1497) : error C2955: “boost::unique_future” : 使用类模板需要模板参数列表 boost\thread\future.hpp(1638) : 参见“boost::unique_future”的声明 boost\thread\future.hpp(1497) : error C2146: 语法错误 : 缺少“)”(在标识符“a_future”的前面) boost\thread\future.hpp(1497) : error C2146: 语法错误 : 缺少“;”(在标识符“a_future”的前面) boost\thread\future.hpp(1497) : error C2377: “boost::unique_future<R>::future_ptr” : 重定义；typedef 不能由任何其他符号重载 with [ R=void ] boost\thread\future.hpp(1454) : 参见“boost::unique_future<R>::future_ptr”的声明 with [ R=void ] boost\thread\future.hpp(1497) : error C2059: 语法错误 : “)” boost\thread\future.hpp(1498) : error C2065: “a_future” : 未声明的标识符 boost\thread\future.hpp(1499) : fatal error C1903: 无法从以前的错误中恢复；正在停止编译 call "C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\vc7\bin\vcvars32.bat" >nul cl /Zm800 -nologo @"bin.v2\libs\thread\build\msvc-7.1\debug\link-static\runtime-link-static\threading-multi\win32\thread.obj.rsp" ...failed compile-c-c++ bin.v2\libs\thread\build\msvc-7.1\debug\link-static\runtime-link-static\threading-multi\win32\thread.obj... ...skipped <pbin.v2\libs\thread\build\msvc-7.1\debug\link-static\runtime-link-static\threading-multi>libboost_thread-vc71-mt-sgd-1_55.lib for lack of <pbin.v2\libs\thread\build\msvc-7.1\debug\link-static\runtime-link-static\threading-multi>win32\thread.obj... ...skipped <pstage\lib>libboost_thread-vc71-mt-sgd-1_55.lib for lack of <pbin.v2\libs\thread\build\msvc-7.1\debug\link-static\runtime-link-static\threading-multi>libboost_thread-vc71-mt-sgd-1_55.lib... compile-c-c++ bin.v2\libs\thread\build\msvc-7.1\release\link-static\runtime-link-static\threading-multi\win32\thread.obj thread.cpp boost\functional\hash\hash.hpp(32) : warning C4616: #pragma warning : 警告编号“6295”超出范围，必须在“4001”和“4999“之间 boost\thread\future.hpp(1488) : error C2039: “make_future_async_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1638) : 参见对正在编译的类模板实例化“boost::unique_future<R>”的引用 boost\thread\future.hpp(1492) : error C2039: “make_future_deferred_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1683) : error C2039: “make_future_async_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1807) : 参见对正在编译的类模板实例化“boost::unique_future<boost::unique_future<R2>>”的引用 boost\thread\future.hpp(1687) : error C2039: “make_future_deferred_shared_state” : 不是“boost::detail”的成员 boost\thread\future.hpp(1490) : error C2951: 模板声明只能在全局或者命名空间范围内使用 boost\thread\future.hpp(3695) : 参见对正在编译的类模板实例化“boost::unique_future<R>”的引用 with [ R=void ] boost\thread\future.hpp(1497) : error C2955: “boost::unique_future” : 使用类模板需要模板参数列表 boost\thread\future.hpp(1638) : 参见“boost::unique_future”的声明 boost\thread\future.hpp(1497) : error C2955: “boost::unique_future” : 使用类模板需要模板参数列表 boost\thread\future.hpp(1638) : 参见“boost::unique_future”的声明 boost\thread\future.hpp(1497) : error C2146: 语法错误 : 缺少“)”(在标识符“a_future”的前面) boost\thread\future.hpp(1497) : error C2146: 语法错误 : 缺少“;”(在标识符“a_future”的前面) boost\thread\future.hpp(1497) : error C2377: “boost::unique_future<R>::future_ptr” : 重定义；typedef 不能由任何其他符号重载 with [ R=void ] boost\thread\future.hpp(1454) : 参见“boost::unique_future<R>::future_ptr”的声明 with [ R=void ] boost\thread\future.hpp(1497) : error C2059: 语法错误 : “)” boost\thread\future.hpp(1498) : error C2065: “a_future” : 未声明的标识符 boost\thread\future.hpp(1499) : fatal error C1903: 无法从以前的错误中恢复；正在停止编译 call "C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\vc7\bin\vcvars32.bat" >nul cl /Zm800 -nologo @"bin.v2\libs\thread\build\msvc-7.1\release\link-static\runtime-link-static\threading-multi\win32\thread.obj.rsp" ...failed compile-c-c++ bin.v2\libs\thread\build\msvc-7.1\release\link-static\runtime-link-static\threading-multi\win32\thread.obj... ...skipped <pbin.v2\libs\thread\build\msvc-7.1\release\link-static\runtime-link-static\threading-multi>libboost_thread-vc71-mt-s-1_55.lib for lack of <pbin.v2\libs\thread\build\msvc-7.1\release\link-static\runtime-link-static\threading-multi>win32\thread.obj... ...skipped <pstage\lib>libboost_thread-vc71-mt-s-1_55.lib for lack of <pbin.v2\libs\thread\build\msvc-7.1\release\link-static\runtime-link-static\threading-multi>libboost_thread-vc71-mt-s-1_55.lib... ...failed updating 2 targets... ...skipped 4 targets...

7 8

Patch in Ticket #9212 (Broken links to C++ standard papers)
by Michel Morin 13 Nov '13

13 Nov '13

Jonathan Wakely pointed out "Broken links to C++ standard papers" issue and attached a patch in #9212. ( https://svn.boost.org/trac/boost/ticket/9212 ) Though this patch is a large Boost-wide patch, it's very simple so I think someone can commit it to every library at once. Regards, Michel

4 9

can i make two io_service::strand instance whith same one io_service instance?
by shada 13 Nov '13

13 Nov '13

can i make two io_service::strand instance whith same one io_service instance?

2 1

[1.55][log] Last minute bug fix
by Andrey Semashev 12 Nov '13

12 Nov '13

Hi, Is it too late for a fix in Boost.Log in 1.55? Here's the commit: https://svn.boost.org/trac/boost/changeset/86600 This fixes garbage output when using dump() manipulator on CPUs with AVX2 support. The bug didn't appear on any of our testers because apparently none of them have Haswell CPUs. I tested this change locally on Linux, gcc 4.8, but it should be valid on all platforms. If it's too late already then maybe a note with the patch in the release notes would be possible?

2 5

[release][1.55.0] Release Notes Additions
by Tom Kent 12 Nov '13

12 Nov '13

I noticed that the list of compilers tested did not include msvc-8.0, it should be added to the list. I believe it got as much testing as 9.0. Also, could we add a link below the download section for the windows binaries on sourceforge? https://sourceforge.net/projects/boost/files/boost-binaries/1.55.0/ Thanks, Tom

3 3

Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
by Antony Polukhin 12 Nov '13

12 Nov '13

2013/11/13 Niall Douglas <s_sourceforge(a)nedprod.com> <...> > On 12 Nov 2013 at 11:59, Robert Ramey wrote: > > > On Tuesday, November 12, 2013 11:34:27 AM UTC-8, Niall Douglas wrote: > > > > > Boost community feedback is requested for the formal peer review of > > > the TypeIndex library by Antony Polukhin. Feedback requested > > > includes ... > > > > > > The above phrasing is a little unclear to me. Is this is a formal review > of > > the library? > Yes, it's a formal review. > > I've just glanced over the documentation but I do have a couple of > > questions. > > > > The serialization library contains a component "extended_typeinfo". Am I > > correct > > in my understanding that this component is meant to address the same > > issues that extended_typeinfo does? If so, how are the two solutions > > different? > In short: * extended_typeinfo is not compatible with std::type_info and is hard to use * TypeIndex is a correctly working std::type_info that does not require RTTI + has other bonuses * detail/sp_typeinfo.hpp implements part of TypeIndex functionality, without workarounds for compiler issues Longer description: Serialization library is created to make a storeable in archive and portable between compilers type identifications. It's interface is not close to the interface of Standard Library, it requires A LOT of code to make typeids work (see example at http://www.boost.org/doc/libs/1_55_0/boost/serialization/extended_type_info… ) TypeIndex is designed to be simple, fast and lightweight. It's a drop-in replacement for std::type_info with big set of workarounds for issues of different compilers and an extension to get human readable type names + it contains a C++11 type_index class and works without RTTI. It does not require user's support code to work. Take a look at this page: http://apolukhin.github.io/type_index/boost_typeindex/getting_started.htmlto see how Standard Library classes and methods are mapped to the TypeIndex ones. TypeIndex is close to detail/sp_typeinfo.hpp (it's just a very very enchanted sp_typeinfo that does not adds macro, embeds workarounds and has interface of std::type_info + other features from paragraph above) -- Best regards, Antony Polukhin

1 0

[1.55] [uuid] Docs header says 'development version' on the website
by Andrey Semashev 12 Nov '13

12 Nov '13

Hi, On the website, Boost.UUID docs have a header that says that these docs are for the 'development version of boost': http://www.boost.org/doc/libs/1_55_0/libs/uuid/uuid.html I looked at a couple other libraries and the header is not displayed, so it's probably Boost.UUID specific. Does anyone know what could be the problem?

2 3

[multi_index] multiple definition errors since 86597
by Jürgen Hunold 12 Nov '13

12 Nov '13

Hi, revision 86597 changed boost/multi_index/detail/bucket_array.hpp Add were: static const std::size_t sizes[]; static const std::size_t sizes_length; member variables, initialised with +template<> +const std::size_t bucket_array_base<true>::sizes[]={ + BOOST_PP_SEQ_ENUM(BOOST_MULTI_INDEX_BA_SIZES) +template<> +const std::size_t bucket_array_base<true>::sizes_length= + sizeof(bucket_array_base<true>::sizes)/ + sizeof(bucket_array_base<true>::sizes[0]); + Now gcc (4.8.1) reports multiple definition errors when using multi_index in different translation units: file1.cpp.o:(.rodata+0x0): multiple definition of `boost::multi_index::detail::bucket_array_base<true>::sizes_length' file2.cpp.o:(.rodata+0x0): first defined here file1.cpp.o:(.rodata+0x20): multiple definition of `boost::multi_index::detail::bucket_array_base<true>::sizes' file2.cpp.o:(.rodata+0x20): first defined here CMakeFiles/graph_test.dir/main.cpp.o:(.rodata+0x0): multiple definition of `boost::multi_index::detail::bucket_array_base<true>::sizes_length' file2.cpp.o:(.rodata+0x0): first defined here file3.o:(.rodata+0x20): multiple definition of `boost::multi_index::detail::bucket_array_base<true>::sizes' file2.cpp.o:(.rodata+0x20): first defined here According to http://stackoverflow.com/questions/1553854/template-static-variable and my current c++ template knowledge, those instantiation belong to a .cpp file to avoid this. This does not work for a header-only library, of course. The current test suite does not catch this because it only contains single file tests. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

Data Structure and Algorithms yet to be implemented
by Manmohit Rekhi 12 Nov '13

12 Nov '13

Hi, I would really be grateful if could get to know 1)which Data Structures and Algorithms are yet to be implemented in boost? 2)How can i get started on them? Thanking you, Manmohit Rekhi

3 2

Boost 1.55.0 released!
by Marshall Clow 12 Nov '13

12 Nov '13

Release 1.55.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. === New Libraries === • Predef: This library defines a set of compiler, architecture, operating system, library, and other version numbers from the information it can gather of C, C++, Objective C, and Objective C++ predefined macros or those defined in generally available headers, from Rene Rivera. === Known bugs with Visual Studio 2013/Visual C++ 12 === Visual Studio 2013 was released quite late in the release process, so there exist several unresolved issues. These include: • Serialization can't compile because of a missing include. • Using has_member_function_callable_with from Boost.Container's allocator_traits causes a compile error (#9332). • For several libraries overloads with intializer lists are incorrectly reported as ambiguous. This is a Visual C++ bug and it isn't clear if there's a good workaround. • In libraries such as Unordered and MultiIndex, calling overloaded functions with initializer lists can result in a compile error, with Visual C++ claiming that the overloads are ambiguous. This is a Visual C++ bug and it isn't clear if there's a good workaround. This won't affect code that doesn't use initializer lists, or uses an initializer list that doesn't require an implicit conversion (i.e. an initializer list of the container's exact value type). • Thread: ex_scoped_thread compile fails (#9333). For details, including download links, see http://www.boost.org/users/news/version_1.55.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.55.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

2 2

Re: [boost] sqlpp11: SQL for C++
by Brian Wood 12 Nov '13

12 Nov '13

From: Bjorn Reese > On 11/09/2013 11:03 PM, Roland Bock wrote: >> >> * define types representing tables and columns, > > There seems to be room for improvement here. You should consider an > integration with Boost.Fusion. This way you can avoid having to build > a code generator. Hmm. If you want a second opinion, these guys http://springfuse.com are building a code generator. -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

2 1

[Functional/Factory] Value factory not accepts rvalues?
by Lin, Yi-Li 12 Nov '13

12 Nov '13

I found that boost::value_factory did not accept rvalues in some case. In my case, temporary value is produced and passed to value factory directly. But boost::value_factory<T>::operator() did not accept rvalue, they take lvaue reference instead. Maybe it'll be better to provide another version of operator takes const lvalue? (Additionally, use std::forward to forward universal reference in C++11?) Sample code which compiler complains: int get_value(); struct var { var( ); explicit var(int); }; void caller() { boost::value_factory<var> f; f(get_value()); }

2 2

Changes to trunk for clang using VC++RTL
by Edward Diener 12 Nov '13

12 Nov '13

I have held off making some changes to trunk in SVN for clang with VC++ RTL until Boost 1.55 was out. I can do so now based on my tests with clang but I am concerned that the changes will not be carried over to the Boost git development branch when Boost switches to git. Should I be waiting until the git changeover is made and everyone learns to deal with git and the setup for using Boost with git, or should I start making changes now and watch the regression tests cycle ? I am sure from my tests that the changes, although involved in low-level libraries like config, mpl, type_traits, will not adversely affect any other compiler and will help in testing clang using VC++ RTL for Boost as clang inches closer to full support in Windows using VC++ headers and libraries.

1 0

Re: [boost] [release][1.55.0] Visual C++ known bugs
by Daniel James 11 Nov '13

11 Nov '13

On 11 November 2013 20:40, Robert Ramey <robertmacleranramey(a)gmail.com> wrote: > > > On Monday, November 11, 2013 12:04:22 PM UTC-8, Daniel James wrote: >> >> On 11 November 2013 12:36, Sergey Cheban <s.ch...(a)drweb.com> wrote: >> > >> > Btw, what do you think about an additional SVN branch for the post-RC2 >> > VC12-related bugfixes? >> >> I just created a branch at: >> >> https://svn.boost.org/svn/boost/branches/maintenance/1_55_0 >> > > Since we've tagged the current state of the release branch with 1_55_0 do we > really have to create another branch? Can't > we just open the release branch for checkins? That would be easier. This branch is just for fixes. The release branch can have other changes, including breaking changes.

2 2

Re: [boost] [release][1.55.0] Visual C++ known bugs
by Daniel James 11 Nov '13

11 Nov '13

On 11 November 2013 21:23, Robert Ramey <robertmacleranramey(a)gmail.com> wrote: > > > On Monday, November 11, 2013 12:42:07 PM UTC-8, Daniel James wrote: >> >> On 11 November 2013 20:40, Robert Ramey <robertmac...(a)gmail.com> wrote: >> > >> > >> > On Monday, November 11, 2013 12:04:22 PM UTC-8, Daniel James wrote: >> >> >> >> On 11 November 2013 12:36, Sergey Cheban <s.ch...(a)drweb.com> wrote: >> >> > >> >> > Btw, what do you think about an additional SVN branch for the >> >> > post-RC2 >> >> > VC12-related bugfixes? >> >> >> >> I just created a branch at: >> >> >> >> https://svn.boost.org/svn/boost/branches/maintenance/1_55_0 >> >> >> > >> > Since we've tagged the current state of the release branch with 1_55_0 >> > do we >> > really have to create another branch? Can't >> > we just open the release branch for checkins? That would be easier. >> >> This branch is just for fixes. The release branch can have other >> changes, including breaking changes. > > > Soo... if we have fixes, we should check them into BOTH branches? If you want to, or just check it into release. It's a way to collect patches, make of that what you will.

1 0

Thanks to everyone for all the work on 1.55.0
by Marshall Clow 11 Nov '13

11 Nov '13

I just wanted to take off my "release manager" hat and say, personally, thank you to all the people who tried out the RCs/Betas/etc, reported bugs, and suggested fixes. You were all a big help in making the release. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[release][1.55.0] Visual C++ known bugs
by Daniel James 11 Nov '13

11 Nov '13

Hello everyone, I'm compiling a list of known issues in boost with Visual Studio 2013/Visual C++ 12. I've made a quick start at: http://www.boost.org/users/history/version_1_55_0.html#version_1_55_0.known… Please let me know if there's anything I should add. Also, if available, tested patches against the release branch or release candidate would be very useful (I don't have the compiler myself, so I can't do that). If you can, please make them using subversion from the root of the repository. thanks, Daniel

5 9

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 11 Nov '13

11 Nov '13

>> How is that supposed to work in Windows? (Does it need to?) Well, a simple analysis, it seems to be specific in POSIX, we do not have anything like it in WINDOWS. (I do not speak for sure) >> Its sensible to expose 'something' that can be integrated to native event loops, but the ideal choice under Windows is probably an event, not a pipe descriptor. I agree. I'm thinking of adding this aspect only in posix, Then if user want use it need add it and use it only on UNIX, e.g.: class myapp { public: int operator()(application::context& context) { #if defined(BOOST_ BOOST_POSIX_API) boost::shared_ptr<application:: selfpipe > selfpipe = context.get_aspect<application:: selfpipe >(); select(...,selfpipe->readfd(),...); #endif return 0; } }; // main int main(int argc, char *argv[]) { myapp app; application::context app_context; #if defined(BOOST_ BOOST_POSIX_API) app_context.add_aspect<application:: selfpipe>( boost::make_shared<application:: selfpipe>()); #endif return application::launch<application::common>(app, app_context); } Comments, Ideas, please! >> I think some analysis is needed. I need help in this subject, if any one with great experience on both sides can propose something (shine a light), it would be of great value! Thanks for help

2 2

Data Structure and Algorithms yet to be inplemented
by Manmohit Rekhi 11 Nov '13

11 Nov '13

Hi, I would really be grateful if could get to know 1)which Data Structures and Algorithms are yet to be implemented? 2)How can i get started on them? 3)Are there any constraints on the libraries i can use to implement them? Thanking you Manmohit Rekhi

1 0

[UUID] Document typo
by Naked Short-Selling 11 Nov '13

11 Nov '13

http://www.boost.org/doc/libs/1_55_0/libs/uuid/uuid.html#Nil I believe is_null() really meant "is_nil()" here...

2 1

[git][ Last merge before git conversion.
by Vicente J. Botet Escriba 10 Nov '13

10 Nov '13

Hi, I would like to know if there will be some time (~1 week) to merge the new features and bug fixed in the release branch before svn is closed for git migration. Note that the provisional calendar was: 8 November : release 1.55 15 November: Provisional: Close subversion for git conversion. Best, Vicente

2 1

[intrusive] possible workaround for vc12 compile errors
by Daniela Engert 10 Nov '13

10 Nov '13

Hi, I've attached a patch to ticket #9332 "has_member_function_callable_with.hpp compile error on msvc-12.0" (https://svn.boost.org/trac/boost/ticket/9332) This patch seems to fix the problem. My far-from-perfect understanding of C++ seems to indicate, that the root cause is in line 201: template< class F , std::size_t N = sizeof((boost::move_detail::declval<F>(). BOOST_INTRUSIVE_HAS_MEMBER_FUNCTION_CALLABLE_WITH_FUNCNAME (), 0))> struct BOOST_PP_CAT(zeroarg_checker_, BOOST_INTRUSIVE_HAS_MEMBER_FUNCTION_CALLABLE_WITH_FUNCNAME) the sizeof expression is evaluated with an unknown type U in declval<U>(). Ciao Dani

2 1

Re: [boost] sqlpp11: SQL for C++
by Roland Bock 10 Nov '13

10 Nov '13

On 2013-11-10 15:58, niXman wrote: > Roland Bock 2013-11-10 12:15: > >> No, sqlpp11 itself only depends on a decent C++11 compiler and matching >> STL. > > I think I can write a code generator using boost.preprocessor. But I > need the documentation of DDL, of course. > I was talking about SQL's DDL (http://en.wikipedia.org/wiki/Data_definition_language) Unfortunately every vendor seems to be using some additions, so that the task is not too simple in all generality, I guess... But using the preprocessor to generate the table types could be a very nice tool in some cases. For instance if you are using in-memory databases with Sqlite3. As a trivial byproduct it could also produce the create table string, so that I would not have to maintain that in two places. Also for such a purpose, it would make sense to restrict the DDL to a common subset. With larger tables, I guess I'd stick with my current approach though: running a separate code-generator as part of the build process. The main benefit is that I get clearer error message pointing to C++ code that exists outside the compiler memory in case the code generator produces incorrect output or I use the generated code in the wrong way, etc. Another benefit of using external code generators is string handling. In our company we use CamelCase for classes, camelCase for members and underscore separated compounds for SQL names. An external code generator can easily translate, of course, but the preprocessor is not equipped for string manipulation, afaik. But again, I can imagine a nice usage of a prepocessor-based code generator for in-memory databases with no external representation. Regards, Roland

1 0

[utility] Any interest for a macro which automatically creates default move-semantics, comparisson etc for a class
by Viktor Sehr 10 Nov '13

10 Nov '13

I've created a macro which automatically creates: - move constructor\assignment - swap member function - operator== and operator!= - operator< - assignment operator without side-effects if it throws. Example usage: class Foo { public: Foo() {} DEFAULT_EVERYTHING(Foo, ( (int)(a) ) ( (std::vector<int>)(b) ) ( (float)(c) ) ); }; Any interest, suggestions or ideas? Ofcourse it might be split into several macros depending on what operators the class requests (if it's a move-only class etc), and perhaps an extra parameter enable if a member is up for sorting and comparison. Code available here: https://www.dropbox.com/s/dhkxj94rrh83az0/DefaultEverything.h

3 10

[containers] Are there flat_map/set and stable_vector proposals at work?
by Klaim - Joël Lamotte 09 Nov '13

09 Nov '13

All is in the title: I would like to know if flat_map, flat_set and stable_vector have been proposed for inclusion in the C++ standard library, or if there are works going on to write such a proposal. I find that I use a bit more flat associative containers than tree-based standard associative containers in all my recent projects, and I think that having option in the standard to choose one or the other would be very useful for a lot of devs.

5 20

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 09 Nov '13

09 Nov '13

Hi, I will answer on list too. >> I would like to know if your application class is related only to console applications or is it a generic class that could be implemented also as a gui::application? It is generic. But now we don't provide any specific support to GUI, you can for sample use it with QT, to do this you need use "common mode". >> I'm trying to write a cross platform header only gui library, so I wonder if I should use it (hoping it's a header only library too) or have my own different gui::application class. http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/f_a_q_.html#boost_application.f_a_q_.can_i_build_another_application_mo de__what_is_needed_ Well, you can build a application mode that will use your GUI lib, e.g. application::gui use application::common as model. But we have some problem here! 1. Boost.Application is not a boost library yet! (have no support od boost.org) , and it is in working progress status. Things can change! 2. Boost.Application is header only, but have some dependencies that are not header only. http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/dependencies.html PS. If you think that this library is interesting to boost, please post on boost.devel, that you have interest on it. http://news.gmane.org/gmane.comp.lib.boost.devel Hope this helps in your decision. If you have any other questions, let me know! -- Renato Forti

1 0

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 09 Nov '13

09 Nov '13

Hi Stas, Thanks for your comments! >> I think it worth noting in documentation that SIGUSR1 is reserved for internal purposes. I will do! >> What do you think about self pipe built-in functionality? It is a widely used trick. I think it can be implemented as an aspect in a quite straightforward way. Can you give more details about what you're proposing here? Elegant signal handler is my main problem in this lib! I want ideas to get it correctly designed! Thanks for documentation appointments, I will fix all! And I forgot to put the main question on message: "Is there any interest in a library like this?" What you think? Thanks a lot!

3 4

[string_ref] string literal constructor
by Michael Marcin 08 Nov '13

08 Nov '13

I noticed string_ref doesn't have a constructor for a string literal. Wouldn't this save a call to strlen for a common case? Ex. template< std::size_t N > basic_string_ref( const charT( &str )[N] ) : basic_string_ref( str, N-1 ) { static_assert(N >= 1, "not a string literal"); } string_ref test( "test" ); I see that adding this directly doesn't work as the compiler is always choosing to decay and pick the const char* overload. Is there no way to make this work?

10 15

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 07 Nov '13

07 Nov '13

Hi All, I have a new "Prototype" version (Version 0.4) of Boost.Application ready to use. This version use a concept of "aspects" suggested by 'Vicente J. Botet Escriba'. Thus the library is much more flexible than version 0.3 (old-version), now the components are independents (loosely coupled). The documentation (work in progress status) is available on : <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html The lib can be downloaded on : <https://github.com/retf/Boost.Application> https://github.com/retf/Boost.Application Please send your feedback! -- Older Version (0.3): If you want to make a comparison with the previous version (0.3), check: <http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html Thanks

2 1

[1.55.0] Release candidate 2 available
by Marshall Clow 07 Nov '13

07 Nov '13

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 === Changes to release since rc1 === ---- Author: bemandawes Date: 2013-10-28 13:16:50 EDT (Mon, 28 Oct 2013) New Revision: 86503 URL: http://svn.boost.org/trac/boost/changeset/86503 Log: Merge 86426 from trunk. This should fix msvc test failures. ---- Author: bemandawes Date: 2013-10-29 09:15:03 EDT (Tue, 29 Oct 2013) New Revision: 86514 URL: http://svn.boost.org/trac/boost/changeset/86514 Log: Merge 84443 from trunk, to fix mpl assert failures for msvc in many libraries. ---- Author: eric_niebler Date: 2013-10-29 12:53:08 EDT (Tue, 29 Oct 2013) New Revision: 86516 URL: http://svn.boost.org/trac/boost/changeset/86516 Log: merge [86460] from trunk, fix bootstrap on mingw --- Author: jhunold Date: 2013-10-29 13:19:33 EDT (Tue, 29 Oct 2013) New Revision: 86519 URL: http://svn.boost.org/trac/boost/changeset/86519 Log: Merge 84402 from ^/trunk ------------------------------------------------------------------------ r84402 | jhunold | 2013-05-21 14:23:20 +0200 (Di, 21 Mai 2013) | 4 lines Fix: cache file loading and saving must use native paths Fixes caching at least on Windows platform ------------------------------------------------------------------------ --- Author: johnmaddock Date: 2013-11-01 05:32:55 EDT (Fri, 01 Nov 2013) New Revision: 86532 URL: http://svn.boost.org/trac/boost/changeset/86532 Log: Merge fix for dependency tracking. --- Author: danieljames Date: 2013-11-03 14:20:09 EST (Sun, 03 Nov 2013) New Revision: 86551 URL: http://svn.boost.org/trac/boost/changeset/86551 Log: Merge Visual C++ 12 fix for Unordered. --- Author: viboes Date: 2013-11-03 15:43:42 EST (Sun, 03 Nov 2013) New Revision: 86552 URL: http://svn.boost.org/trac/boost/changeset/86552 Log: Thread: merge [86540] to fix #9319.

11 16

Re: [boost] [1.55.0] Release candidate 2 available
by Peter Dimov 06 Nov '13

06 Nov '13

Robert Ramey wrote: > lol - I'm already dealing with the fallout from a previous "trivial one > line fix". I actually do understand, because most trivial one-line fixes aren't. This one (adding the missing #include <algorithm>) really is, though. (At least according to my experience.)

1 0

Re: [boost] [1.55.0] Release candidate 2 available
by Eric Niebler 06 Nov '13

06 Nov '13

On 11/5/2013 1:46 AM, LeMay.Steve wrote: > VS2013 needs archive's transform_width.hpp to #include <algorithm> so > that std::min will be properly defined. Looks like it. Can you file the bug please? -- Eric Niebler Boost.org http://www.boost.org

11 17

[math] Contribution and TODO-list implementation.
by Bikineev 06 Nov '13

06 Nov '13

Hello. I'm russian student. My department is Applied Math. I need to make my magister work and I would like to relate it with Boost.Math development. I think this work could be something like implementation of tasks mentioned in TODO-list. New feature development may take a long time. In the best case, I would be glad to take job and reviewer for it. If anyone has an idea - I'm ready to take serious and big job for 1,5 years. Thanks.

5 11

Boost API System or Library Calls ..
by Rahul Mathur 06 Nov '13

06 Nov '13

Out of curiosity, wish to know if BOOST ASIO calls like - boost::asio::read() boost::asio::transfer_all() boost::asio::write() BOOST LEXICAL calls like - boost::lexical_cast<std::string>() BOOST POSIX TIME calls like - boost::posix_time::microsec_clock::universal_time() boost::posix_time::microsec_clock::ptime() are LIBRARY or SYSTEM calls. How to know which calls of BOOST are SYSTEM and LIBRARY calls? Thanks.

3 3

Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable?
by Ahmed Charles 05 Nov '13

05 Nov '13

What about combining throw_exception.hpp and exception.hpp and move that header to config, since it won't depend on anything else and only really does configuration anyways? Note, if you don't like config as a choice, the new version of detail which only depends on config sounds nice as well. ________________________________ From: Emil Dotchevski Sent: 11/3/2013 12:29 PM To: boost(a)lists.boost.org Subject: Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable? 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 3

[unordered] Visual C++ 2013 initializer_list overload failure.
by Daniel James 05 Nov '13

05 Nov '13

Hi, I'm getting some test failures for inserting an initializer_list into the unordered containers: http://www.boost.org/development/tests/trunk/developer/output/teeks99-10-wi… I don't have access to Visual C++ 12 to investigate this. This is just a guess, but I think the problem is converting an initializer_list of string literals to an initializer list of std::string. This works okay with clang and g++ so I assume it's allowed. A minimal test might be something like the following (although it might not). #include <initializer_list> #include <string> template <typename T> struct thing { void insert(T const&) {} void insert(T&&) {} void insert(std::initializer_list<T>) {} }; int main() { thing<std::string> x; x.insert("a"); x.insert({"a"}); x.insert({"a", "b"}); }

5 13

[tweener] Doxygen documentation issues
by Julien Jorge 05 Nov '13

05 Nov '13

Hi, I am writing the documentation of Boost.Tweener and I encounter various difficulties. One of them is the generation of the class documentation with doxygen. It seems that it cannot extract the class and member documentation from .ipp files. I like to document the methods of my classes near the implementation. In Boost.Tweener, most of the class documentation is then in the .ipp files and I have written the following lines in the Jamfile.v2: import quickbook ; using boostbook ; using doxygen ; doxygen reference : [ glob ../../../boost/tweener/*.hpp ] [ glob ../../../boost/tweener/detail/*.hpp ] [ glob ../../../boost/tweener/detail/impl/*.ipp ] [ glob ../../../boost/tweener/detail/impl/easing/*.ipp ] [ glob ../../../boost/tweener/easing/*.hpp ] But when I try to build the documentation, I have the following error: boost_1_52_0/tools/build/v2/build/generators.jam:1085: in ensure-type from module generators error: target { ../../../boost/tweener/detail/impl/tweener_group.ipp. } has no type Moreover, if I remove the ipp files, the generation of the documentation does not fail but the doxygen documentation is not extracted, except for the private members. So, how can I also disable the extraction of the private members in the documentation? You can check the Jamfile.v2 in the git repository of the project: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a… Regards, Julien

2 3

[modularization] Modularizing Boost (modularization)
by Stephen Kelly 05 Nov '13

05 Nov '13

Hi there, my plan for modularizing and modernizing Boost was roughly this: * Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph * Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. * Phase 3 - Try to port the mpl to variadic templates so that the dependency on Boost.PP is not needed when variadic templates are available. I recommend completing up to phase 2 before migrating to git, as otherwise files will have to be deleted from one repo, and added to another without history. Phase 0 is aborted, so let's look at phase 1. [Note: This should go without saying, but my experience on this list tells me it needs to be said: * I do not propose making many commits with the commit message 'migrate' * The below is scripted for your understanding only. Scripting gives an exactness which prose does not, and allows reproducibility. Don't take it too literally. * Of course, forwarding headers should be understood to be left behind when a file is moved, where possible. * Don't cry too loudly about where I'm moving files to. See Phase 2 above, and understand that this is partly only an experiment to see how modularization can be done. EndNote] If the dependencies between repositories are analysed, the result is this graph: http://steveire.com/boost/graph_all.dot http://steveire.com/boost/graph_all_small.png There are 104 nodes and 1159 edges. Each edge is a real dependency which exists between repos, and which will exist between boost modularized packages. They should not be considered optional. If we remove any nodes which are not strongly connected, we are left with a new graph of nodes which are all strongly connected: http://steveire.com/boost/graph_strong.dot http://steveire.com/boost/graph_strong_small.png There are 68 nodes and 675 edges. Move enable_if from utility to type_traits: git submodule foreach 'git grep -l -P utility/enable_if.hpp -- include/boost | xargs sed -i "s|utility/enable_if.hpp|type_traits/enable_if.hpp|" || echo' mv libs/utility/include/boost/utility/enable_if.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 670 edges and 68 nodes. Next, move boost/detail/workaround.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/detail/workaround.hpp -- include/boost | xargs sed -i "s|boost/detail/workaround.hpp|boost/config/workaround.hpp|" || echo' mv libs/detail/include/boost/detail/workaround.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 661 edges and 68 nodes. Next, move boost/limits.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/limits.hpp -- include/boost | xargs sed -i "s|boost/limits.hpp|boost/config/limits.hpp|" || echo' mv libs/detail/include/boost/limits.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 653 edges and 68 nodes. Next, move boost/detail/iterator.hpp and boost/iterator/iterator_traits.hpp to the type_traits library/repo: git submodule foreach 'git grep -l -P boost/detail/iterator.hpp -- include/boost | xargs sed -i "s|boost/detail/iterator.hpp|boost/type_traits/detail/iterator.hpp|" || echo' git submodule foreach 'git grep -l -P boost/iterator/iterator_traits.hpp -- include/boost | xargs sed -i "s|boost/iterator/iterator_traits.hpp|boost/type_traits/iterator_traits.hpp|" || echo' mv libs/detail/include/boost/detail/iterator.hpp libs/type_traits/include/boost/type_traits/detail/ mv libs/iterator/include/boost/iterator/iterator_traits.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 650 edges and 68 nodes. Next, move boost/iterator.hpp from iterator to the utility library/repo: mv libs/iterator/include/boost/iterator.hpp libs/utility/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 649 edges and 68 nodes. utility no longer depends on iterator. Move boost/version.hpp to config: mv libs/detail/include/boost/version.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 512 edges and 64 nodes. The config, integer, io and static_assert libraries are no longer part of the mesh Next, move boost/pointee.hpp from iterator to detail: mv ./libs/iterator/include/boost/pointee.hpp libs/detail/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move exception/detail/attribute_noreturn.hpp into config: git submodule foreach 'git grep -l -P boost/exception/detail/attribute_noreturn.hpp -- include/boost | xargs sed -i "s|boost/exception/detail/attribute_noreturn.hpp|boost/config/attribute_noreturn.hpp|" || echo' mv libs/exception/include/boost/exception/detail/attribute_noreturn.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move boost/throw_exception.hpp and exception.hpp into utility: mv libs/exception/include/boost/throw_exception.hpp libs/utility/include/boost mv libs/exception/include/boost/exception/exception.hpp libs/utility/include/boost/utility git submodule foreach 'git grep -l -P boost/exception/exception.hpp -- include/boost | xargs sed -i "s|boost/exception/exception.hpp|boost/utility/exception.hpp|" || echo' git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 485 edges and 64 nodes. Several libraries form an inner mesh: $ grep -P "^\s*(type_traits|mpl|detail|utility|smart_ptr|typeof)" output.dot detail->mpl detail->type_traits detail->smart_ptr detail->utility utility->mpl utility->type_traits utility->detail type_traits->detail type_traits->mpl type_traits->typeof type_traits->utility smart_ptr->type_traits smart_ptr->detail smart_ptr->utility mpl->type_traits mpl->detail mpl->utility typeof->mpl typeof->type_traits If we treat them as one element for now, we get a new graph from the rest http://steveire.com/boost/graph_with_corelib.dot http://steveire.com/boost/graph_with_corelib.png There are now 138 edges and 39 nodes Move parts of {vector_,}property_map into graph_parallel: sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/property_map.hpp > tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/property_map.hpp sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/vector_property_map.hpp >> tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/vector_property_map.hpp sed -i '/#undef PBGL_DISTRIB_PMAP/r tmp.hpp' libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp rm tmp.hpp git submodule foreach 'git grep -l -P boost/property_map/parallel/distributed_property_map.hpp -- include/boost | xargs sed -i "s|boost/property_map/parallel/distributed_property_map.hpp|boost/graph/parallel/distributed_property_map.hpp|" || echo' git submodule foreach 'git grep -l -P boost/property_map/parallel/impl/distributed_property_map.ipp -- include/boost | xargs sed -i "s|boost/property_map/parallel/impl/distributed_property_map.hpp|boost/graph/parallel/detail/distributed_property_map.hpp|" || echo' mv libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp libs/graph_parallel/include/boost/graph/parallel mv libs/property_map/include/boost/property_map/parallel/impl/distributed_property_map.ipp libs/graph_parallel/include/boost/graph/parallel/detail git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' http://steveire.com/boost/graph_after_parallel.dot http://steveire.com/boost/graph_after_parallel.png There are now 95 edges and 33 nodes The remaining problematic edges are: conversion->range conversion->math range->algorithm math->multiprecision concept_check->parameter Assuming they can be broken by moving some files aroung (I believe they can be), we end up with a small graph of strongly connected components: http://steveire.com/boost/graph_after_remaining.dot http://steveire.com/boost/graph_after_remaining.png There are now 18 edges and 11 nodes. Looking at the entire graph again, we get this: http://steveire.com/boost/graph_final.dot http://steveire.com/boost/graph_final_small.png Obviously, this is not perfect, but it is a beginning, and it is mostly now a directed graph. Any comments? Thanks, Steve.

29 162

[parameter] referring to argument types in BOOST_PARAMETER_FUNCTION return values
by Erik Erlandson 05 Nov '13

05 Nov '13

There is documentation that demonstrates using boost::parameter::value_type<> to extract the type of an argument in the boost::parameter library. However, the example does *not* use the BOOST_PARAMETER_FUNCTION() macro, and so the resulting function doesn't benefit from all the features you can get from that macro: Section 3.2.2: http://www.boost.org/doc/libs/1_54_0/libs/parameter/doc/html/index.html#mor… I was able to fairly easily obtain the same kind of arg type information inside of a BOOST_PARAMETER_FUNCTION() declaration, which I show in this example: https://gist.github.com/erikerlandson/7319975 To come up with that, I had to throw '-E' and examine the macro expansions to determine that 'Args' is the appropriate argument-pack template name to use. In other words, what I did doesn't appear to be officially supported: // not officially documented or supported? (typename boost::parameter::value_type<Args, tag::c, int>::type) However, I don't see any barrier to officially supporting the above. All it requires is a promise that 'Args' is the template name that will be generated by the macros. Alternatively, provide a new utility macro, such as: #define BOOST_PARAMETER_ARG_TYPE(arg_name) typename boost::parameter::value_type<[template arg name], [namespace]::arg_name, int>::type

1 0

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

[MPL] RFC: An MPL macro to define a has_member_xxx<T> predicate
by Erik Erlandson 31 Oct '13

31 Oct '13

If there's already a boost solution for this, then I have egg on my face, but I can't find one: I'd like an MPL macro that defines a predicate template which inherits from boost::true_type iff the given type defines *any* member with a particular name (false_type otherwise), and which does not assume the member name exists, like this: struct my_class { // foo might be member data, member function, a typedef, etc: int foo; }; CREATE_MEMBER_CHECK(foo); CREATE_MEMBER_CHECK(bar); has_member_foo<my_class> t1; // this inherits from true_type has_member_bar<my_class> t2; // this inherits from false_type I wrote an implementation of the above, and example, here: https://gist.github.com/erikerlandson/7251015 The macro BOOST_MPL_HAS_XXX_TRAIT_DEF produces a predicate class that detects if a nested type exists, but only works for types, not other kinds of defined members. The class is_member_pointer<T>, but appears to require that you already know a symbol exists. I suppose such a macro might be called BOOST_MPL_HAS_XXX_MEMBER_DEF.

2 2

Re: [boost] [asio] Bug: Handlers execute on the wrong strand (Gavin Lambert).
by Marat Abrarov 31 Oct '13

31 Oct '13

> I actually ended up abandoning Asio and rolling my own threadqueue (I > didn't want any of the socket-related stuff so this wasn't as big a job > as it sounds). Mine isn't fully-baked yet (and it's Windows-only for > the moment) and I'm not sure I'd want to show it off either, but on the > upside most of the guts are entirely lock-free (though not wait-free, > since it's based on Boost.LockFree's queue). Asio at Windows uses IOCP (default settings, using asio::io_service for task scheduling) and that is the (theoretical) reason of better thread scheduling for the Asio-based thread pool. Sometimes it's really visible. Regards, Marat Abrarov.

3 6

Reimplementation of the MPL for C++11
by Louis Dionne 31 Oct '13

31 Oct '13

Hi, I am currently working on a reimplementation of the MPL for C++11. Although the library is not complete yet, I would like to gauge interest for the project from the Boost community. I wanted to wait until I have resolved some core issues before posting here, but reading the [modularization] thread made it unbearable to wait any longer :-). The library is available on GitHub: github.com/ldionne/mpl11. If some people happen to be interested by the project and would like to get involved, please get in touch with me. Regards, Louis Dionne N.B.: Some design decisions will be influenced by the community (if there's interest) and I'm experimenting a lot. Don't be put off if you see something that you don't like: it might change.

12 23

[range] RFC: span(iterator, size)
by TONGARI J 31 Oct '13

31 Oct '13

Hi there, I want to query if there's any interest in such a utility: span(iterator, size) : iterator_range which simply returns iterator_range(it, it + size) for RandomAccessIterator; for others modeling ForwardIterator, a special iterator adaptor, say, counted_iterator is used, so we don't have to advance it just for getting the end iterator. Thoughts?

3 15

BOOST ASIO: Having successful READ from the SERVER ..??
by Rahul Mathur 31 Oct '13

31 Oct '13

All, Initially after having done successful CONNECT with the server, sending successful LOGON message and finally KEEP ALIVE status, I tried to read from the server as - -- boost::asio::streambuf data; std::size_t length = boost::asio::read(socket, data, boost::asio::transfer_at_least(socket.available())); -- but was able to partially receive response from remote server which I don't think was completely successful, so to have COMPLETE RESPONSE from the server, tried with below modification - -- boost::system::error_code ec; boost::asio::streambuf data; std::size_t length = boost::asio::read(socket, data, boost::asio::transfer_all(), ec); --- but this modification doesn't work. Any clue what should be the proper way? Thanks!!

1 0

[git help] Cloning the boost git repository recursively seems to have issues.
by Daniel Pfeifer 30 Oct '13

30 Oct '13

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? -- You received this message because you are subscribed to the Google Groups "ryppl-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to ryppl-dev+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.

1 0

Re: [boost] Introduction and Cray support. [config] [build] [atomic] [interprocess] [asio] [dump] [tr1]
by Brian Wood 30 Oct '13

30 Oct '13

From: Richard Dale > Hello world, > > My name is Richard Dale. I work at Cray, Inc. > My purpose here is to get the boost libraries and Cray C++ compiler to > work and play together better. > > I have a couple of questions, but maybe some background first. Hi, Richard, Would you be willing to check if the archive here: http://webEbenezer.net/build_integration.html builds with the Cray compiler? That software is needed to use the C++ Middleware Writer (CMW). The CMW has marshalling support for some Boost libraries. On a machine here, the software builds in under six seconds. Barring portability problems, I'm sure it would be less than that on one of your machines. Also/alternatively, could I have remote access to one of your machines with your C++ compiler on it? Thank you for considering these requests. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[build] bootstrap.sh is still broken
by Stephan T. Lavavej 30 Oct '13

30 Oct '13

Hi, For months, I've been pinging the boost-build list about bootstrap.sh being completely broken for MinGW, with no response. As the 1.55.0 branch is closing in just a week, it would be wonderful if somebody could look at and apply my two patches that are ready to go: http://lists.boost.org/boost-build/2013/10/27025.php Note that they will fix this: https://svn.boost.org/trac/boost/ticket/8762 Thanks, STL

15 68

[git] "headers" target fails
by Brian Ravnsgaard Riis 30 Oct '13

30 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I see the same error that Vicente reported yesterday, when trying to follow the wiki approach to the modularised boost: Monty: ~/programming/boost +[git:master] → ./b2 headers link.jam: No such file or directory Jamroot:145: in modules.load ERROR: rule "link-directory" unknown in module "Jamfile</home/brian/programming/boost>". /home/brian/programming/boost/tools/build/v2/build/project.jam:311: in load-jamfile /home/brian/programming/boost/tools/build/v2/build/project.jam:64: in load /home/brian/programming/boost/tools/build/v2/build/project.jam:145: in project.find /home/brian/programming/boost/tools/build/v2/build-system.jam:535: in load /home/brian/programming/boost/tools/build/v2/kernel/modules.jam:289: in import /home/brian/programming/boost/tools/build/v2/kernel/bootstrap.jam:139: in boost-build /home/brian/programming/boost/boost-build.jam:17: in module scope Monty: ~/programming/boost +[git:master] → I don't think we can blame retention on the convert script anymore. Regards, /Brian Ravnsgaard Riis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJScU45AAoJEFES4N8QrEod+wIH/RYF/GpB0nh+T6/fYEP6iQSO l8XVA0dyPuFx/LY9eLZFYFVQlJut7EJYujk3SUSqN3UUmphmnm2yNPeYkIzNMUzz 07PYvs9/2n74dWsJkfusxbvwXLcuBbGQlMfmaDsKj3UTjdUScrD3dFjH3fyhC5Il gvyH68YyWkX1V3at09hCyqplslum70WT2HAJty4ra+sXfxcbqSq95N6YdvOkbYRD QGjlpAABxdtLym9WzEekQV+H32t7T/CzqRw8Ay4n89DeFNI7T/1twOtCFVZjwtVG JbFVpDCjUtKpLBEqSwP5WkdcAbXmHYD2MuhhaK1tYAuXkPT1Uz1PrL23D0ZB2BA= =iiDy -----END PGP SIGNATURE-----

3 5

[test] failures in heap testsuite
by Tim Blechmann 30 Oct '13

30 Oct '13

hi all, i'm not sure what is the reason for this, but the boost.heap testsuite has some severe problems, which seem to be related with boost.test: in the release branch, all (!!!) tests fail on all unixy platforms. this was not the case when i developed the library. and i've reported this issue more than once. well, using a testing framework, which crashes before the test cases are even executed is a bit, well, worrying. iac, i was happy that the tests in the release branch used to work at least ... however i am seeing a lot of messages like: Assertion failed: (!!s_active_handler), function jump_buffer, file ../boost/test/impl/execution_monitor.ipp, line 683. Assertion failed: (!!s_active_handler), function sys_sig, file ../boost/test/impl/execution_monitor.ipp, line 690. what does this tell me? thnx, tim

2 2

[git] Recent checkout
by Brian Ravnsgaard Riis 30 Oct '13

30 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've tried to clone the boost git repo to see how we're coming along. Doing ``git clone --recursive`` and changing into the boost directory caused some immediate confusion: Monty: ~/programming/boost +[git:master] The `+` to the right means zsh has determined the working directory is dirty. This on a newly checked out repo! Monty: ~/programming/boost +[git:master] → git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: bootstrap.bat # modified: libs/geometry (modified content) # modified: libs/interprocess (modified content) # modified: libs/intrusive (modified content) # modified: libs/math (modified content) # modified: libs/multiprecision (modified content) # modified: libs/pool (modified content) # no changes added to commit (use "git add" and/or "git commit -a") Monty: ~/programming/boost +[git:master] → As far as I can see, this is related to eol conversions? Should my local .gitconfig contain anything special in this regard? I have no global settings regarding crlf handling. /Brian Ravnsgaard Riis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJScUtkAAoJEFES4N8QrEodypYH/1syQuRXXrHBqXf0Jd9Zd+Kb SjG9GwIVo+o1iAWM5GgulU2tv8NcMcsn3Jk82dqSIeiqEl9LPY/1OtugjcajGoAX 5J0AfYBtv8bOi0eFUmOKMA0AcrS9Y6bclUZBpu4qJsUvnHCDVThpn6iSH3ZYzZ5M TIvWggGszOMvlJeS9DrDTXVQIpoIKTY9C2exeA3tcb8oMS4zADtuYjqyx/RD5shC RupAfKKNaVCZU5cVXdPF/butxQDIbTVJTqPd1h263vYHT7SwpJQ0wYiAAfHQhy+e LWkSJ1WDHW+sD24aQoPF84XwL50DJkDJ579cFmWYMbY60x1RIglS56koLePOSSU= =Zpqj -----END PGP SIGNATURE-----

1 0

[cryptography] is there a library?
by Michael Marcin 30 Oct '13

30 Oct '13

I'm writing to an API that requires: "The language selected must also include a key generator and encrypt and decrypt API. The only messages that are not encrypted are error messages. The encryption and decryption algorithms are not configurable. Make sure the encrypt and decrypt API supports the algorithms in use. The current algorithm in use is Password-Based Key Definition (PBKDF2) to generate the key from a given password, iteration count and salt value. DESede + CBC + PKCS5 v2.0 is then used with the key to encrypt and decrypt the message." Is there such a library hiding in or around boost somewhere? Thanks.

4 4

[cryptography] is there a library?
by Renato Forti 30 Oct '13

30 Oct '13

>> Is there such a library hiding in or around boost somewhere? Take a look on botan: http://botan.randombit.net/

1 0

[coroutine] Recommended documentation clarification
by Jason 30 Oct '13

30 Oct '13

I just upgraded my local Boost installation from v1.54 to v1.55b1 and tried to compile one of my applications with the updated library. To my surprise, I found that all of my code that used Boost.Coroutine now failed to compile. After looking at the beta documentation, it seems that the coroutine class interface from v1.54 has been abruptly deprecated with essentially no explanation. Since I don't have time to rewrite all of my client code at this point, using the old interface is a must. After inspecting some of the Coroutine headers, I found that I could define BOOST_COROUTINE_V1 to get the old behavior, but there isn't any mention of this in the docs. It would probably be a more user-friendly change to make this change and workaround more clear in the documentation before the v1.55 release. Jason -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-Recommended-documentation-clar… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[1.55b1][coroutine][exception] not propagating exception type
by Jeff Flinn 29 Oct '13

29 Oct '13

I'm on VS2013, with BOOST_COROUTINES_V1 defined. I've merged boost::coroutine's exception test with boost::exception's derives_std_exception test. A std::exception& is caught when based on docs I would expect derives_std_exception to be caught. Am I doing something obviously wrong? Thanks, Jeff #include <boost/coroutine/all.hpp> #include <boost/bind.hpp> struct derives_std_exception : std::exception {}; namespace coro = boost::coroutines; typedef coro::coroutine< void() > coro_void_void; template< typename E > void f14(coro_void_void::caller_type & , E const& e) { throw e; } int main() { try { coro_void_void coro( boost::bind(f14< derives_std_exception > , _1, derives_std_exception())); return -1; } catch (derives_std_exception const&) { return 0; } catch (std::exception const&) { return -1; } catch (...) { return -1; } }

3 4

Introduction and Cray support. [config] [build] [atomic] [interprocess] [asio] [dump] [tr1]
by Richard Dale 29 Oct '13

29 Oct '13

Hello world, My name is Richard Dale. I work at Cray, Inc. My purpose here is to get the boost libraries and Cray C++ compiler to work and play together better. I have a couple of questions, but maybe some background first. The first thing I plan to do is fix up the existing config/compiler/cray.hpp and .../v2/tools/cray.jam files. With this done, both the static and dynamic versions of most buildable libraries build successfully. The second thing is to address cray specific issues in the libraries listed in the subject line. With the exception of tr1, these are all preprocessor changes to avoid inline assembly, which the cray C++ compiler does not support yet, and probably won't anytime soon. The tr1 change is to provide a Cray version of the macro BOOST_TR1_STD_HEADER_NAME. The third thing will be to "officialize" the cray compiler, so that it gets picked up and used by default when it is the default compiler on Cray systems. The target is to provide good support for Cray C++ in the 1.56 release. Once the configuration changes are done, we (Cray) will start running the regression tests on a regular basis. I'm a little uncertain as to how to proceed in the immediate term, especially given the impending conversion to git. The idea of compiler support is somewhat orthogonal to the notion of library support, and there doesn't seem to be a well defined concept of compiler owner. I seem to have couple of options. The first option would be to get as much done as possible pre-conversion. My assumption is that I would check everything into the trunk, (The library changes are pretty trivial), using Trac tickets to keep the library owners in the loop. I assume it is the individual library owners who take care of the merges from trunk to branches/release (master?), although I'm unsure where this falls on the continuum between ordinarily true and always true. The second option would be to wait until the cutover to git, and do the workflow for making changes to a library owned by someone else. This is probably the right thing, but I'm more fluent with svn than with git. So, I guess I'm looking for advice and consent here. Please straighten me out if there is something I seem not to understand. For what it's worth, I've made myself "champion" for the Cray compiler. I don't pretend to know everything, but if I can't figure something out, I probably know who to ask. I'll take any Trac tickets relating to Boost on Cray. Regards, Richard

3 2

[1.55] Request permission to merge 84402
by Jürgen Hunold 29 Oct '13

29 Oct '13

Hi! I would like to merge 84402 to release. I missed the deadline due to provider hardware problems killing my DSL. ------------------------------------------------------------------------ r84402 | jhunold | 2013-05-21 14:23:20 +0200 (Di, 21 Mai 2013) | 4 lines Fix: cache file loading and saving must use native paths Fixes caching at least on Windows platform ------------------------------------------------------------------------ Building Boost and using Boost.Build without this fix works, but the caching system is rendered useless at least on Windows. The cache files simply can't be written. Seems this already missed 1.54. Tested on trunk with msvc and gcc. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

[release] permission to merge Stephan's bootstrap changes?
by Eric Niebler 29 Oct '13

29 Oct '13

I've manually verified Stephan's fix. May I merge https://svn.boost.org/trac/boost/changeset/86460 and end Stephan's suffering? See the extensive thread beginning at http://lists.boost.org/Archives/boost/2013/10/207525.php for the complete discussion (or as much of it as lists.boost.org currently has archived). -- Eric Niebler Boost.org http://www.boost.org

3 3

[1.55] Request permission to merge 84443
by Beman Dawes 29 Oct '13

29 Oct '13

I just finished merging and testing locally. Lack of 84443 was causing both MSVC 2012 and 2013 to fail iterator_adaptor_test (and many other tests in many other libraries). After the merge, iterator_adaptor_test passes for both compilers. Request permission to merge. Andrey Semashev reports: > The problem has already been mentioned several times on the maling lists > and the bug tracker: > > https://svn.boost.org/trac/boost/ticket/9205 > > https://svn.boost.org/trac/boost/ticket/9249 > > https://svn.boost.org/trac/boost/ticket/9278 > > http://thread.gmane.org/gmane.comp.lib.boost.user/79919 > > http://thread.gmane.org/gmane.comp.lib.boost.user/79932 > > http://thread.gmane.org/gmane.comp.lib.boost.devel/244986 > > http://thread.gmane.org/gmane.comp.lib.boost.devel/245596 --Beman

2 2

[1.55][mpl][atomic] Tests failing on MSVC-12
by Andrey Semashev 29 Oct '13

29 Oct '13

Hi, I'm seeing Boost.Atomic test failures on MSVC-12 with the following errors: C:\local\boost\boost/iterator/detail/facade_iterator_category.hpp(166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' C:\local\boost\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=boost::unit_test::basic_cstring<const char> , Reference=boost::unit_test::basic_cstring<const char> ] Here's the link with the complete message: http://www.boost.org/development/tests/release/developer/output/teeks99-10-… It doesn't seem to be a problem with Boost.Atomic but rather some incompatibility of BOOST_MPL_ASSERT_NOT and MSVC-12. Does anyone know what the problem is?

3 8

[config] BOOST_NO_CXX11_HDR_MEMORY and gcc-4.6.2
by Vicente J. Botet Escriba 29 Oct '13

29 Oct '13

Hi, I'm checking for BOOST_NO_CXX11_HDR_MEMORY to include <memory> file with gcc-4.6.2 C++0x and while the file is there (it was a C++98 file),it is not defining in particular pointer_traits and allocator_traits Could the following patch be applied? Best, Vicente svn diff stdlib/libstdcpp3.hpp Index: stdlib/libstdcpp3.hpp =================================================================== --- stdlib/libstdcpp3.hpp (revision 86431) +++ stdlib/libstdcpp3.hpp (working copy) @@ -154,9 +154,11 @@ // Note that although <chrono> existed prior to 4.7, "stead_clock" is spelled "monotonic_clock" // so 4.7.0 is the first truely conforming one. # define BOOST_NO_CXX11_HDR_CHRONO +// C++11 header not yet (fully!) implemented, e.g. pointer_traits and allocator_traits. +# define BOOST_NO_CXX11_HDR_MEMORY # define BOOST_NO_CXX11_ALLOCATOR #endif -// C++0x headers not yet (fully!) implemented +// C++11 headers not yet (fully!) implemented // # define BOOST_NO_CXX11_HDR_THREAD # define BOOST_NO_CXX11_HDR_TYPE_TRAITS

6 14

The release branch is now closed
by Marshall Clow 28 Oct '13

28 Oct '13

Please do not commit anything to the release branch w/o explicit permission from the release managers. -- Marshall

5 4

[1.55] Request permission to merge 86426 to branches/release
by Beman Dawes 28 Oct '13

28 Oct '13

86426 needs to be merged to branches/release. It is a showstopper since without it all msvc tests are broken. It is a one-liner from Steven that simply deletes line 15, " : usage-requirements <implicit-dependency>/boost//headers" from libs/Jamfile.v2. This was was part of a three revision set of patches (86393, 86398, and 86426) that was being held waiting for trunk tests to cycle. The first two got merged yesterday, but the last one was missed in the last minute rush. --Beman

3 3

[config] gcc 4.6 unified initialization syntax buggy
by klaus triendl 28 Oct '13

28 Oct '13

hi, gcc 4.6 (with -std=c++0x) has a bug in its support for unified initialization. specifically a derived class cannot initialize its base with members, if the base has no user-defined constructor: <code> struct base { int i; }; struct derived: base { explicit derived(int i): base{i} {} }; </code> therefore the configuration macro BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX should be fixed... Has this been already addressed? -- klaus triendl

1 0

[config] clang/int128 support
by Tim Blechmann 28 Oct '13

28 Oct '13

hi all, is it ok to commit this patch? this works around some issues when compiling boost.atomic with clang-3.4: ../../../boost/atomic/detail/gcc-atomic.hpp:961:64: error: no matching constructor for initialization of 'storage_type' (aka 'boost::atomics::detail::storage128_type') explicit base_atomic(value_type const& v) BOOST_NOEXCEPT : v_(0) thnx, tim --- a/boost/config/compiler/clang.hpp +++ b/boost/config/compiler/clang.hpp @@ -39,6 +39,11 @@ // Clang supports "long long" in all compilation modes. #define BOOST_HAS_LONG_LONG +#if defined(__SIZEOF_INT128__) +# define BOOST_HAS_INT128 +#endif + +

2 1

[numeric] Lack headers for ARM CPU
by christine bouzant 28 Oct '13

28 Oct '13

Hello all, I would need to include the header boost/numeric/interval/hw_rounding.hpp but i see that the ARM CPU is not taken in account. Is someone would have a non official header version for the ARM cpu case ? Thank you! Cheers, Christine

1 0

boost::polygon type genericity
by T. Raykoff 28 Oct '13

28 Oct '13

boost::polygon has a nice facility for generic numeric types for coordinate values via coordinate_traits, etc. But there are a number of places in the library code where a hard-coded type, usually a double, is used instead of referring to the appropriate type in this trait struct. Should this be considered a bug in b::p? Background: I'd like to use a custom class as a type which manages the scaling of real-world decimal coordinates to the integral values that b::p likes to use. I understand the whole thing about snap-rounding to an integral grid and all that, so need to scale up the real-world decimal values to an appropriate grid size. But it makes sense to carry this paradigm through to all of the typedef's in coordinate_traits and high_precision_type, but this is where things break with the hard-coded double's. T -- View this message in context: http://boost.2283326.n4.nabble.com/boost-polygon-type-genericity-tp4651484.… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 10

[1.55] Late release Notes?
by John Maddock 27 Oct '13

27 Oct '13

In order to save my blushes(!), can the following line please be added to the Math lib release notes: * Add improvement to non-central chi squared distribution quantile due to Thomas Luu. Apologies to Thomas for forgetting him! John.

4 5

[git] [conversion] Schedule and remaining showstoppers?
by Beman Dawes 27 Oct '13

27 Oct '13

It seems to me the best time for the svn to modular git changeover is right after a Boost release. That will give us the maximum time window to get the new house in order before the subsequent release. So should we convert right after 1.55 ships? I'm well aware that there is a long list of conversion related tasks that we haven't completed. But the svn -> git conversion process itself is so complex that only Dave and Daniel can make modifications. They have done a staggering amount of work already and are nearing exhaustion. Once the conversion is done, there are many of us that understand git well enough to help with problems. For example, https://github.com/ryppl/Boost2Git/issues/5, "Mimic gitfow", is a showstopper in that what is now "master" should be "develop" and the true "master" (i.e. releases) branch needs to be synthesized. But while it would be great if the Boost2Git process could handle that, it could probably also be do by a post-conversion step performed by git and other command line tools that many of us could help with. Messy, but I'm not willing to take a further delay waiting for perfection. Which of the issues in https://github.com/ryppl/Boost2Git/issues?state=openare true show stoppers? Are there any true showstoppers missing from that list? --Beman

12 45

[git] conversion stalled
by Jürgen Hunold 27 Oct '13

27 Oct '13

Hi! It seems the conversion script is stalled on commit 515f5649bbfb25e2ac89958d700ff2a67fddc030 Date: Fri Sep 13 14:48:17 2013 +0000 There have been some Boost.Build commits in the meantime, can someone please re-enable the conversion again? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

7 15

[winapi] Default target Windows version
by Andrey Semashev 26 Oct '13

26 Oct '13

Hi, First, a little intro. As part of ongoing work on Boost.Sync we've created quite a few headers with WinAPI declarations that are often needed in Boost libraries. The headers are in boost/detail/winapi and can be used by any library that wishes to avoid including windows.h. The headers declare some symbols that depend on the target Windows version. For example, GetTickCount64 only appeared in Windows Vista. The user can define BOOST_USE_WINAPI_VERSION macro before including any Boost headers to indicate the target WinAPI version Boost should use. If the macro is not defined, the headers attempt to deduce the target Windows version from the _WIN32_WINNT and WINVER macros, if they are defined by the user. Lastly, if everything fails, the headers fall back to a default, which is currently Windows XP. I wanted to ask the community if it is appropriate to raise the default to Windows Vista. The rationale for this is that Vista introduced a lot of useful APIs (in thread synchronization, in particular) and XP is losing its popularity and soon will be completely unsupported by Microsoft. Also, I'm not sure what is the current state of affair, but Microsoft already tried to drop pre-Vista targets in MSVC. Note that I'm not suggesting to drop support for pre-Vista Windows. The user will still be able to enable previous versions of WinAPI in one of the mentioned above ways. Lastly, I'd like to encourage Boost developers to use this protocol for defining WinAPI version used by libraries. It would be ideal if by defining BOOST_USE_WINAPI_VERSION the user would be able to control WinAPI version used by all Boost libraries, not just Boost.Sync and Boost.Chrono (the current users of these headers). If you want to add support for this protocol to your library, simply include boost/detail/winapi/config.hpp. This will result in BOOST_USE_WINAPI_VERSION being defined so that it can be checked by the library. Other headers boost/detail/winapi make use of this macro, you can see them as an example.

9 36

Re: [boost] [voronoi]medial axis
by Michael Simbirsky 26 Oct '13

26 Oct '13

Thanks, Andrii, Louis, Like Louis, I try to use Boost.Polygon Voronoi diagram for medial axis computation. Since Voronoi diagram is stored as DCEL, it is not difficult to represent it as a combination of two dual graphs. The "primal" bidirected graph has Voronoi vertices as its vertices and (finite) halfedges as edges. The "dual" graph has Voronoi cells as its vertices; half-edges "connect" adjacent cells. This graph is also bi-directed. I think this understanding of DCEL is rather common; I believe CGAL applies similar approach to provide Boost Graph adapters for its DCEL arrangements. For my purposes I am writing the adapters on my own. Iterator parts are straight-forward. For efficiency it is also useful to convert some internals into "property maps". For example, color map is already provided, one has only to wrap it into boost::property_map with correct access functions. Similarly, the fact that vertices are packed into continuous storage gives us an efficient "vertex to integer" bimap, an important ingredient for many search algorithms from Boost Graph library. As the next step I hope to implement your discussion on vertices connected to infinity, vertices in holes etc.using Boost.Graph. Andrii, I would be glad to share this code with you and Boost.Polygon users. Thanks, -Michael

2 3

[release] Permission to merge after regression cycle
by Vicente J. Botet Escriba 26 Oct '13

26 Oct '13

Hi, I have been fixing some bugs on Boost.Chrono #9274 <https://svn.boost.org/trac/boost/ticket/9274> lost of precission on system_clock input <https://svn.boost.org/trac/boost/ticket/9274> #9276 <https://svn.boost.org/trac/boost/ticket/9276> output from a system_clock::time_point get a time_point that is one day later than expected <https://svn.boost.org/trac/boost/ticket/9276> #9265 <https://svn.boost.org/trac/boost/ticket/9265> time_point_output_h test crashes regression test <https://svn.boost.org/trac/boost/ticket/9265> #8328 <https://svn.boost.org/trac/boost/ticket/8328> chrono crashes visual studio 2012 regression tests <https://svn.boost.org/trac/boost/ticket/8328> The concerned change sets are 19:00 Changeset /[86410]/ by viboes <https://svn.boost.org/trac/boost/changeset/86410> Thread: Try to fix system_clock::time_point output on windows. 18:01 Changeset /[86384]/ by viboes <https://svn.boost.org/trac/boost/changeset/86384> Chrono: try to avoid the crash with msvc 11 on chrono_io. 17:36 Changeset /[86383]/ by viboes <https://svn.boost.org/trac/boost/changeset/86383> Chrono: set precission to 9 so that there is no lost with the hisgest ... 14:27 Changeset /[86376]/ by viboes <https://svn.boost.org/trac/boost/changeset/86376> Chrono: fix two important issues with Boost.Chrono IO v2 on windows * ... 14:54 Changeset /[86357]/ by viboes <https://svn.boost.org/trac/boost/changeset/86357> Chrono: don't run test_good_utc_fmt_system_clock on windows as this is ... I would like to merge these changeset to release. Is it time to do it before releasing boost 1.55? Best, Vicente Patch: svn diff boost/chrono/detail/inlined/win/chrono.hpp boost/chrono/io/time_point_io.hpp libs/chrono/test/io/time_point_output.cpp libs/chrono/example/io_ex1.cpp Index: boost/chrono/detail/inlined/win/chrono.hpp =================================================================== --- boost/chrono/detail/inlined/win/chrono.hpp (revision 86326) +++ boost/chrono/detail/inlined/win/chrono.hpp (working copy) @@ -109,8 +109,11 @@ { ec.clear(); } - return time_point(duration( - (static_cast<__int64>( ft.dwHighDateTime ) << 32) | ft.dwLowDateTime)); + return system_clock::time_point( + system_clock::duration( + ((static_cast<__int64>( ft.dwHighDateTime ) << 32) | ft.dwLowDateTime) + -116444736000000000LL + )); } #endif Index: boost/chrono/io/time_point_io.hpp =================================================================== --- boost/chrono/io/time_point_io.hpp (revision 86326) +++ boost/chrono/io/time_point_io.hpp (working copy) @@ -28,6 +28,7 @@ #include <boost/chrono/clock_string.hpp> #include <boost/chrono/round.hpp> #include <boost/chrono/detail/scan_keyword.hpp> +#include <boost/static_assert.hpp> #include <boost/detail/no_exceptions_support.hpp> #include <cstring> #include <locale> @@ -46,9 +47,11 @@ { namespace chrono { + typedef double fractional_seconds; namespace detail { + template <class CharT, class InputIterator = std::istreambuf_iterator<CharT> > struct time_get { @@ -758,6 +761,7 @@ { 0,31,59,90,120,151,181,212,243,273,304,334}, { 0,31,60,91,121,152,182,213,244,274,305,335} }; + return days[is_leap(year)][month-1] + day - 1; } @@ -779,7 +783,7 @@ month++; int day = t->tm_mday; int day_of_year = days_from_1jan(year,month,day); - int days_since_epoch = days_from_1970(year) + day_of_year; + int days_since_epoch = days_from_1970(year) + day_of_year ; time_t seconds_in_day = 3600 * 24; time_t result = seconds_in_day * days_since_epoch + 3600 * t->tm_hour + 60 * t->tm_min + t->tm_sec; @@ -801,11 +805,36 @@ return y * 365 + y / 4 - y / 100 + y / 400; } + // Returns year/month/day triple in civil calendar + // Preconditions: z is number of days since 1970-01-01 and is in the range: + // [numeric_limits<Int>::min(), numeric_limits<Int>::max()-719468]. + template <class Int> + //constexpr + void + inline civil_from_days(Int z, Int& y, unsigned& m, unsigned& d) BOOST_NOEXCEPT + { + BOOST_STATIC_ASSERT_MSG(std::numeric_limits<unsigned>::digits >= 18, + "This algorithm has not been ported to a 16 bit unsigned integer"); + BOOST_STATIC_ASSERT_MSG(std::numeric_limits<Int>::digits >= 20, + "This algorithm has not been ported to a 16 bit signed integer"); + z += 719468; + const Int era = (z >= 0 ? z : z - 146096) / 146097; + const unsigned doe = static_cast<unsigned>(z - era * 146097); // [0, 146096] + const unsigned yoe = (doe - doe/1460 + doe/36524 - doe/146096) / 365; // [0, 399] + y = static_cast<Int>(yoe) + era * 400; + const unsigned doy = doe - (365*yoe + yoe/4 - yoe/100); // [0, 365] + const unsigned mp = (5*doy + 2)/153; // [0, 11] + d = doy - (153*mp+2)/5 + 1; // [1, 31] + m = mp + (mp < 10 ? 3 : -9); // [1, 12] + y += (m <= 2); + --m; + } inline std::tm * internal_gmtime(std::time_t const* t, std::tm *tm) { if (t==0) return 0; if (tm==0) return 0; +#if 0 static const unsigned char day_of_year_month[2][366] = { @@ -820,6 +849,7 @@ { -1, 30, 58, 89, 119, 150, 180, 211, 242, 272, 303, 333, 364 }, { -1, 30, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 } }; +#endif const time_t seconds_in_day = 3600 * 24; int32_t days_since_epoch = static_cast<int32_t>(*t / seconds_in_day); @@ -829,6 +859,7 @@ hms = seconds_in_day+hms; } +#if 0 int32_t x = days_since_epoch; int32_t y = static_cast<int32_t> (static_cast<long long> (x + 2) * 400 / 146097); @@ -843,16 +874,23 @@ //y -= 32767 + 2; y += 70; tm->tm_year=y; - const bool leap = is_leap(y); + const int32_t leap = is_leap(y); tm->tm_mon = day_of_year_month[leap][doy]-1; - tm->tm_mday = doy - days_in_year_before[leap][day_of_year_month[leap][doy] - 1]; + tm->tm_mday = doy - days_in_year_before[leap][tm->tm_mon] ; +#else + int32_t y; + unsigned m, d; + civil_from_days(days_since_epoch, y, m, d); + tm->tm_year=y-1900; tm->tm_mon=m; tm->tm_mday=d; +#endif - tm->tm_hour = hms / 3600; const int ms = hms % 3600; tm->tm_min = ms / 60; tm->tm_sec = ms % 60; + tm->tm_isdst = -1; + (void)mktime(tm); return tm; } @@ -907,6 +945,9 @@ tm = *tmp; #else if (gmtime_r(&t, &tm) == 0) failed = true; + tm.tm_isdst = -1; + (void)mktime(&tm); + #endif } @@ -922,7 +963,7 @@ failed = tpf.put(os, os, os.fill(), &tm, pb, pe).failed(); if (!failed) { - duration<double> d = tp - system_clock::from_time_t(t) + seconds(tm.tm_sec); + duration<fractional_seconds> d = tp - system_clock::from_time_t(t) + seconds(tm.tm_sec); if (d.count() < 10) os << CharT('0'); //if (! os.good()) { // throw "exception"; @@ -932,6 +973,7 @@ //if (! os.good()) { //throw "exception"; //} + os.precision(9); os << d.count(); //if (! os.good()) { //throw "exception"; @@ -1058,12 +1100,8 @@ const std::time_get<CharT>& tg = std::use_facet<std::time_get<CharT> >(loc); const std::ctype<CharT>& ct = std::use_facet<std::ctype<CharT> >(loc); tm tm; // {0} - tm.tm_year=0; - tm.tm_mon=0; - tm.tm_mday=0; - tm.tm_hour=0; - tm.tm_min=0; - tm.tm_sec=0; + std::memset(&tm, 0, sizeof(std::tm)); + typedef std::istreambuf_iterator<CharT, Traits> It; if (pb == pe) { @@ -1079,9 +1117,13 @@ tg.get(is, 0, is, err, &tm, pb, pe); #endif if (err & std::ios_base::failbit) goto exit; - double sec; + fractional_seconds sec; CharT c = CharT(); + std::ios::fmtflags flgs = is.flags(); + is.setf(std::ios::fixed, std::ios::floatfield); + is.precision(9); is >> sec; + is.flags(flgs); if (is.fail()) { err |= std::ios_base::failbit; @@ -1099,13 +1141,14 @@ if (err & std::ios_base::failbit) goto exit; time_t t; + #if BOOST_CHRONO_INTERNAL_TIMEGM t = detail::internal_timegm(&tm); #else t = timegm(&tm); #endif tp = time_point_cast<Duration>( - system_clock::from_time_t(t) - min + round<microseconds> (duration<double> (sec)) + system_clock::from_time_t(t) - min + round<system_clock::duration> (duration<fractional_seconds> (sec)) ); } else Index: libs/chrono/test/io/time_point_output.cpp =================================================================== --- libs/chrono/test/io/time_point_output.cpp (revision 86326) +++ libs/chrono/test/io/time_point_output.cpp (working copy) @@ -148,68 +148,102 @@ using namespace boost::chrono; using namespace boost; - test_good_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2), duration_style::prefix); - test_good_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2), duration_style::symbol); + test_good_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2), duration_style::prefix); + test_good_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2), duration_style::symbol); - test_good_prefix_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2)); - test_good_prefix_system_clock("1970-01-01 00:02:00.000000 +0000", minutes(2)); - test_good_prefix_system_clock("1970-01-01 00:00:02.000000 +0000", seconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:01.000000 +0000", seconds(1)); - test_good_prefix_system_clock("1969-12-31 23:59:59.000000 +0000", seconds(-1)); - test_good_prefix_system_clock("1970-01-01 00:00:00.000000 +0000", seconds(0)); - test_good_prefix_system_clock("1970-01-01 00:00:00.002000 +0000", milliseconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.000002 +0000", microseconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.000000 +0000", nanoseconds(2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.200000 +0000", duration<boost::int_least64_t, deci> (2)); - test_good_prefix_system_clock("1970-01-01 00:00:00.066667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); + test_good_prefix_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2)); + test_good_prefix_system_clock("1970-01-01 00:02:00.000000000 +0000", minutes(2)); + test_good_prefix_system_clock("1970-01-01 00:00:02.000000000 +0000", seconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:01.000000000 +0000", seconds(1)); + test_good_prefix_system_clock("1969-12-31 23:59:59.000000000 +0000", seconds(-1)); + test_good_prefix_system_clock("1970-01-01 00:00:00.000000000 +0000", seconds(0)); + test_good_prefix_system_clock("1970-01-01 00:00:00.002000000 +0000", milliseconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.000002000 +0000", microseconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.000000002 +0000", nanoseconds(2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.200000000 +0000", duration<boost::int_least64_t, deci> (2)); + test_good_prefix_system_clock("1970-01-01 00:00:00.066666667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); - test_good_symbol_system_clock("1970-01-01 02:00:00.000000 +0000", hours(2)); - test_good_symbol_system_clock("1970-01-01 00:02:00.000000 +0000", minutes(2)); - test_good_symbol_system_clock("1970-01-01 00:00:02.000000 +0000", seconds(2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.002000 +0000", milliseconds(2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.000000 +0000", nanoseconds(2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.200000 +0000", duration<boost::int_least64_t, deci> (2)); - test_good_symbol_system_clock("1970-01-01 00:00:00.066667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); + test_good_symbol_system_clock("1970-01-01 02:00:00.000000000 +0000", hours(2)); + test_good_symbol_system_clock("1970-01-01 00:02:00.000000000 +0000", minutes(2)); + test_good_symbol_system_clock("1970-01-01 00:00:02.000000000 +0000", seconds(2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.002000000 +0000", milliseconds(2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.000000002 +0000", nanoseconds(2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.200000000 +0000", duration<boost::int_least64_t, deci> (2)); + test_good_symbol_system_clock("1970-01-01 00:00:00.066666667 +0000", duration<boost::int_least64_t, ratio<1, 30> > (2)); test_good_utc_fmt_system_clock("1970-01-01 02:00:00", "%Y-%m-%d %H:%M:%S", hours(2)); test_good_utc_fmt_system_clock("1970-01-01 02", "%Y-%m-%d %H", hours(2)); - +#if ! defined(BOOST_CHRONO_WINDOWS_API) test_good_utc_fmt_system_clock ("1970-01-01 02:00:00", "%Y-%m-%d %T", hours(2)); test_good_utc_fmt_system_clock ("1970-01-01 02:00", "%Y-%m-%d %R", hours(2)); test_good_utc_fmt_system_clock ("% 1970-01-01 02:00", "%% %Y-%m-%d %R", hours(2)); test_good_utc_fmt_system_clock ("1970-01-01 02:00 Thursday January", "%Y-%m-%d %R %A %B", hours(2)); - +#endif } + +#endif +#if BOOST_CHRONO_VERSION == 2 void test_gmtime(std::time_t t) { std::cout << "t " << t << std::endl; + puts(ctime(&t)); std::tm tm; + std::memset(&tm, 0, sizeof(std::tm)); if (boost::chrono::detail::internal_gmtime(&t, &tm)) { - std::cout << "year " << tm.tm_year << std::endl; - std::cout << "month " << tm.tm_mon << std::endl; - std::cout << "day " << tm.tm_mday << std::endl; - std::cout << "hour " << tm.tm_hour << std::endl; - std::cout << "min " << tm.tm_min << std::endl; - std::cout << "sec " << tm.tm_sec << std::endl; + tm.tm_isdst = -1; + (void)mktime(&tm); + std::tm tm2; + std::memset(&tm2, 0, sizeof(std::tm)); + if (gmtime_r(&t, &tm2)) + { + tm2.tm_isdst = -1; + (void)mktime(&tm2); + + BOOST_TEST_EQ( tm.tm_year , tm2.tm_year ); + BOOST_TEST_EQ( tm.tm_mon , tm2.tm_mon ); + BOOST_TEST_EQ( tm.tm_mday , tm2.tm_mday ); + BOOST_TEST_EQ( tm.tm_hour , tm2.tm_hour); + BOOST_TEST_EQ( tm.tm_min , tm2.tm_min ); + BOOST_TEST_EQ( tm.tm_sec , tm2.tm_sec ); + BOOST_TEST_EQ( tm.tm_wday , tm2.tm_wday ); + BOOST_TEST_EQ( tm.tm_yday , tm2.tm_yday ); + BOOST_TEST_EQ( tm.tm_isdst , tm2.tm_isdst ); + } } + } #endif + int main() { -// test_gmtime( 0 ); -// test_gmtime( -1 ); -// test_gmtime( +1 ); -// test_gmtime( 0 - (3600 * 24) ); -// test_gmtime( -1 - (3600 * 24) ); -// test_gmtime( +1 - (3600 * 24) ); -// test_gmtime( 0 + (3600 * 24) ); -// test_gmtime( -1 + (3600 * 24) ); -// test_gmtime( +1 + (3600 * 24) ); +#if BOOST_CHRONO_VERSION == 2 + test_gmtime( 0 ); + test_gmtime( -1 ); + test_gmtime( +1 ); + test_gmtime( 0 - (3600 * 24) ); + test_gmtime( -1 - (3600 * 24) ); + test_gmtime( +1 - (3600 * 24) ); + test_gmtime( 0 + (3600 * 24) ); + test_gmtime( -1 + (3600 * 24) ); + test_gmtime( +1 + (3600 * 24) ); + test_gmtime( 0 + 365*(3600 * 24) ); + test_gmtime( 0 + 10LL*365*(3600 * 24) ); + test_gmtime( 0 + 15LL*365*(3600 * 24) ); + test_gmtime( 0 + 17LL*365*(3600 * 24) ); + test_gmtime( 0 + 18LL*365*(3600 * 24) ); + test_gmtime( 0 + 19LL*365*(3600 * 24) ); + test_gmtime( 0 + 19LL*365*(3600 * 24)+ (3600 * 24)); + test_gmtime( 0 + 19LL*365*(3600 * 24)+ 3*(3600 * 24)); + test_gmtime( 0 + 19LL*365*(3600 * 24)+ 4*(3600 * 24)); + test_gmtime( 0 + 20LL*365*(3600 * 24) ); + test_gmtime( 0 + 40LL*365*(3600 * 24) ); +#endif + std::cout << "high_resolution_clock=" << std::endl; check_all<boost::chrono::high_resolution_clock> (); #ifdef BOOST_CHRONO_HAS_CLOCK_STEADY @@ -239,6 +273,13 @@ check_all<boost::chrono::process_cpu_clock> (); #endif +#if BOOST_CHRONO_VERSION == 2 + boost::chrono::system_clock::time_point tp = boost::chrono::system_clock::now(); + std::cout << tp << std::endl; + time_t t = boost::chrono::system_clock::to_time_t(tp); + test_gmtime( t ); +#endif + return boost::report_errors(); } Index: libs/chrono/example/io_ex1.cpp =================================================================== --- libs/chrono/example/io_ex1.cpp (revision 86326) +++ libs/chrono/example/io_ex1.cpp (working copy) @@ -53,10 +53,13 @@ << ClockTick(3) + nanoseconds(10) << '\n'; cout << "\nsystem_clock::now() = " << system_clock::now() << '\n'; +#if defined _MSC_VER && _MSC_VER == 1700 +#else #if BOOST_CHRONO_VERSION==2 cout << "\nsystem_clock::now() = " << time_fmt(chrono::timezone::local) << system_clock::now() << '\n'; cout << "\nsystem_clock::now() = " << time_fmt(chrono::timezone::local,"%Y/%m/%d") << system_clock::now() << '\n'; #endif +#endif #ifdef BOOST_CHRONO_HAS_CLOCK_STEADY cout << "steady_clock::now() = " << steady_clock::now() << '\n';

3 4

[type traits] Removal of files broke regression tests
by Beman Dawes 26 Oct '13

26 Oct '13

r68300 removed boost/type_traits/broken_compiler_spec.hpp and boost/type_traits/transform_traits_spec.hpp. Removing the first broke regression tests for iterator, python, and serialization. Removing the second doesn't appear to have done any harm. John Maddock did the r68300 commit. I'm assuming it was in response to Steve Kelly's r86250, "Remove use of obsolete BOOST_TT_BROKEN_COMPILER_SPEC", so the fix may be to remove the #includes that are causing all the errors rather than restoring the file. --Beman

2 1

[fusion] flatten/flatten_view Proposal
by TONGARI J 25 Oct '13

25 Oct '13

Hi there, I've created the ticket, doc&test included https://svn.boost.org/trac/boost/ticket/9294 'flatten' is an algorithm which returns a view that allows you to go through the leaf elems sequentially. For example: flatten(make_vector(1, make_vector(2, 3))) == make_vector(1, 2, 3) This is developed when I use Fusion to work with SQL for simple data mapping. In addition to 'flatten', 'support/ref' is also provided in this patch for working with mutable sequence, which I had talked with Joel sometime ago. BTW, I think the ticket below is OK to close (the patch seem applied): https://svn.boost.org/trac/boost/ticket/8270 Thanks,

2 7

[config] A few headers moved from detail into config module
by Daniel James 25 Oct '13

25 Oct '13

Hi, In case you missed it on the other thread, a few headers have been moved to the config module from detail: boost/version.hpp boost/limits.hpp boost/detail/workaround.hpp Hopefully that isn't a controversial move, but if any of these are a problem, it's just a case of reverting the appropriate changeset in Boost2Git. You can see them at: https://github.com/ryppl/Boost2Git/commits/master Daniel

1 0

[Numeric] Lack Numeric/interval headers for ARM CPU
by christine bouzant 25 Oct '13

25 Oct '13

Hello all, I would need to include the header boost/numeric/interval/hw_rounding.hpp but i see that the ARM CPU is not taken in account. Is someone would have a non official header version for the ARM cpu case ? Thank you! Cheers, Christine

1 0

storing intrusive_ptr in atomic?!
by Oliver Kowalke 25 Oct '13

25 Oct '13

Hello, do you confirm that it is valid to store a intrusive_ptr inside an atomic?! struct X { std::size_t use_count; X() : use_count( 0) {} friend inline void intrusive_ptr_add_ref( X * p) BOOST_NOEXCEPT { ++p->use_count; } friend inline void intrusive_ptr_release( X * p) { if ( 0 == --p->use_count) delete p; } }; X::ptr_t x1( new X() ); X::ptr_t x2( new X() ); boost::atomic< X::ptr_t > av1( x1); BOOST_ASSERT( av1.compare_exchange_strong( x1, x2) ); BOOST_ASSERT( av1.load() != x1); BOOST_ASSERT( av1.load() == x2); A type T used in generic template atomic<T> is required to be trivial copy-able, e.g. I think it is trivial copy-able (std::memcpy) only the use_count will not incremented. The memory layout of intrusive_ptr is a raw-pointer so trivial copy-able should be correct. What do you think? Oliver

4 26

[git] creation of .gitignores
by Jürgen Hunold 25 Oct '13

25 Oct '13

Hi, the converted repository is missing .gitignores. svn provides the ignores patterns in the "svn:ignore" property. The question is: Can those patterns be extracted by the conversion script or shall manually create .gitignores in current svn (patch attached). The third option is to add them after the conversion. Adding (and modifying) the .gitignores during the conversion has the advantage of having .gitignores throughout the whole history instead of only "now". Any comments? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 2

[git help] Documenting common modular boost workflows
by Beman Dawes 25 Oct '13

25 Oct '13

I think we need to document simple suggested modular boost workflows. Each workflow could start with the assumption that the steps described in https://svn.boost.org/trac/boost/wiki/TryModBoost have been completed. Workflows might include: 1) Switch to the "develop" branch, fix a minor problem, test, commit, switch back to "master". 2) Same as (1) but also push to remote. 3) Same as (2) but also merge develop to master. 4) Same as (3) but end by submitting a pull request to the boost super-project. I don't mind writing the actual wiki pages, but am a little hobbled by being a TortoiseGit rather than command line git user, and by never having worked with sub-modules. So what would recommended git commands look like for one or more of the above workflows? Thanks, --Beman

12 30

[utility][enable_if] Documentation issue
by Agustín K-ballo Bergé 25 Oct '13

25 Oct '13

The documentation for `enable_if` has a duplicated anchor for sections 3.1 and 3.2, making it impossible to link to section 3.2 directly. See http://www.boost.org/libs/utility/enable_if.html#htoc7 This issue is still present in trunk. Could this be fixed? I could provide a patch but I do not see a .qbk file for it, should the html be modified directly? Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

2 2

[Type_Traits] [remove_bounds]: Wrong workaround for IBM C++ compiler is applied in remove_bounds.hpp
by Kilian Kilger 24 Oct '13

24 Oct '13

Hi, in remove_bounds.hpp, a wrong workaround for the IBM C++ compiler is applied. This workaround is only valid for IBM C++ on AIX, but wrong for IBM C++ on z/OS. The z/OS compiler has no bug and thus no workaround must be applied (else we get wrong results). So instead of testing against __IBMCPP__ one should also test against __MVS__. This last macro is only defined for IBM C++ on z/OS. I wanted to open a ticket on trac, but this system did always identify my posting as spam. Best regards, Kilian.

4 11

[1.55 beta][serialization] VS2013 boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min'
by Jeff Flinn 24 Oct '13

24 Oct '13

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

1 0

[functors] proposal
by Piotr Wygocki 24 Oct '13

24 Oct '13

Hi, I've developed a small set of functors and functor adaptors. Although this code is very simple it might be very useful for some subset of the community. Do you think it might become a part of the boost library? If not I'm still very interested in any feedback. I think it's not big enough to be a separate library. To my knowledge of boost it fits in the utility lib. The code can be found here: https://github.com/wygos/functors List of utilities: SkipFunctor takes any number of arguments; does completely nothing ReturnSomethingFunctor<T,t> takes any number of arguments; returns t; IdentityFunctor takes one parameter and returns it. ReturnFalseFunctor takes any number of arguments; returns false; ReturnTrueFunctor takes any number of arguments; returns true; ReturnZeroFunctor takes any number of arguments; returns 0; AssertFunctor takes any number of arguments; asserts; ArrayToFunctor<Array> Stores an object which provides operator[]. Provides operator()(). A set of non-template comparison functors (only operator() is templated): * Greater * Less * GreaterEqual * LessEqual * EqualTo * NotEqualTo FunctorToComparator<Functor, Compare> This comparator takes a functor "f" and a comparator "c". For elements (x,y) it returns c(f(x), f(y)) c is Less by default FunctorToOutputIterator<Functor> The output iterator stores a functor and each time the operator= is called the given functor is called Logical operators as functors: * Not * Or * And * Xor LiftBinaryOperatorFunctor<Operator, FunctorLeft, FunctorRight> Functor stores a binary operator "o" and two functors "f" and "g". For given arguments args returns o(f(args), g(args)). Boolean functor adapters. Each of them stores a boolean functor and performs an appropriate logical operation in the operator(). * NotFunctor<Functor> * OrFunctor<FunctorLeft, FunctorRight> * AndFunctor<FunctorLeft, FunctorRight> * XorFunctor<FunctorLeft, FunctorRight> Regards, Piotr

5 12

[boost-testing] something broke my tester(lazypiranha)
by Michael Mathews 24 Oct '13

24 Oct '13

Hi Folks, starting with last nights run my tester has been failing with : File "/home/michael/boost_testing/tools_regression_src/regression.py", line 329, in command_test self.command_test_boost_build() File "/home/michael/boost_testing/tools_regression_src/regression.py", line 369, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/home/michael/boost_testing/results/boost/bin.v2/libs/any/test/any_test.test' Is there an easy an easy way for me to determine the missing test? thanks michael

1 0

NT2 and Boost.SIMD beta 2 available
by Joel Falcou 23 Oct '13

23 Oct '13

This following releases updates NT2 and Boost.SIMD libraries.10 months had past and 176 Issues have been closed since last beta release and more than 2000 commits have been issued. Boost.SIMD is heading toward API stability. We want to tackle ons ome more compile time issues before going for an actual Boost Review. Special thanks to Tim Blenchmann and Domagoj Saric for their help and suggestions throughout this development. The release Changelog is here : https://github.com/MetaScale/nt2/releases The files can be download from : http://nt2.metascale.org/downloads/ The Documentation (in progress) is here : http://nt2.metascale.org/doc/html/index.html

4 4

[1.55][Math] Are we still open to patches?
by John Maddock 23 Oct '13

23 Oct '13

Are we still open for patches for 1.55? If so I'd like to merge the patch for the issue raised here: http://boost.2283326.n4.nabble.com/Boost-1-54-0-boost-math-sph-bessel-n-x-c… now that the tests on Trunk have cycled. Thanks, John.

2 1

[website] Redirection to latest documentation
by Laurent Dupuy 23 Oct '13

23 Oct '13

Hello all, Would it be possible for the webmaster(s) to add a redirection (a symbolic link or whatever) to the latest documentation? Until recently, the URL http://www.boost.org/doc/libs/ did the job, but it does not anymore. Thanks! -- Laurent Dupuy.

2 1

Boost.Build commit heads up
by Beman Dawes 23 Oct '13

23 Oct '13

Here is the commit message for revision 86392: Add Boost.Build support for the Git modular layout, using links to to new header locations, thus preventing breakage to vast amounts of user code and build setups. Being added to SVN so that changes will automatically propagate to Git and modular Boost. Thanks to Steven Watanabe, Jürgen Hunold, Vladimir Prus, and Bjørn Roald for developing this patch. Steven in particular conceived the approach and did the initial implementation, which was further refined by the other contributors. In theory this commit won't break any existing boost builds. To verify that, on Win 7 and Ubunto I've done a fresh SVN checkout of trunk and verified bootstrap.bat, bootstrap.sh, and a b2 build work both before and after the patch is applied. On Windows, I verified that after the patch is applied a b2 build using an unpatched prior compilation of b2 still works. These tests increase confidence that committing the patch to trunk now isn't likely to cause breakage, but please post to this list right away if you spot any build breakage or other odd behavior. The files modified are listed below. Thanks, --Beman Modified: D:\boost\trunk\Jamroot Modified: D:\boost\trunk\libs\geometry\index\example\Jamfile.v2 Modified: D:\boost\trunk\libs\numeric\odeint\examples\vexcl\Jamfile.v2 Modified: D:\boost\trunk\libs\parameter\doc\html\index.html Modified: D:\boost\trunk\libs\parameter\doc\index.rst Modified: D:\boost\trunk\libs\python\example\Jamroot Modified: D:\boost\trunk\libs\python\example\quickstart\Jamroot Modified: D:\boost\trunk\libs\python\example\tutorial\Jamroot Modified: D:\boost\trunk\libs\signals2\example\Jamfile.v2 Modified: D:\boost\trunk\libs\spirit\example\qi\json\build\Jamfile Modified: D:\boost\trunk\libs\units\test\Jamfile.v2 Modified: D:\boost\trunk\tools\Jamfile.v2 Modified: D:\boost\trunk\tools\regression\build\Jamroot.jam

5 6

Re: [boost] [git help] Documenting common modular boost workflows
by Daryle Walker 23 Oct '13

23 Oct '13

Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind. I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems). And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle? Sent from Windows Mail From: Peter Dimov Sent: ‎Monday‎, ‎October‎ ‎21‎, ‎2013 ‎10‎:‎16‎ ‎AM To: Boost Dev-List Dave Abrahams wrote: > IIUC we already agreed long ago to use gitflow: It's not entirely clear to me what using gitflow would mean in the context of a Boost superproject with per-library submodules. Who is "we" who would be using gitflow, the Boost release managers or the library maintainers? When Boost release 1.64.0 is started, who is going to create the gitflow release branch, and from what? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 4

Reading & Parsing an .ini input file using BOOST... ..!!
by Rahul Mathur 22 Oct '13

22 Oct '13

All, Need small help. I have an "input.ini" input file which contains sample values like – --- App=| 5000 | 5001 | 0 | | | | 1BYTE | --- Starting with word (viz. App), followed by equal sign, than data within pipes (|) and blank space between two pipes ( | | ). Anything only between two pipes is to be read. I am looking to parse this input file. After parsing, assign each data to struct member type and than send this complete struct as socket. I am looking to use Boost property tree (or the needed one) and finally the ASIO to send the complete filled struct as stream. I tried below code to read complete data and it worked but - --- #include <iostream> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/ini_parser.hpp> #include <boost/filesystem/fstream.hpp> int main() { boost::property_tree::ptree pt; boost::property_tree::ini_parser::read_ini("input.ini", pt); std::cout << pt.get<std::string>("App") << std::endl; } --- But, how to read between pipes? Any clue?

1 0

Re: [boost] Boost.Build commit heads up
by Klaim - Joël Lamotte 22 Oct '13

22 Oct '13

(my last email is still in moderaition because of the zip with the log) On Tue, Oct 22, 2013 at 11:40 PM, Klaim - Joël Lamotte <mjklaim(a)gmail.com>wrote: > The boost build on my Win764bit finished for me for both VS2012 and > VS2013, apparently no error in the log I'm attaching to this mail with the > build script (which uses b2). > I'll try now to compile my main project. > I forgot to say that the revision I built was trunk r86395. So building boost with b2 now don't spawn errors, but compiling my project I still hit this bug: https://svn.boost.org/trac/boost/ticket/9266 see comments for details. (By the way, does the test suite is able to catch such compiler crashes?) To continue compiling my project, see other errors, I modified synchronized_value to activate only the code that do use variadic templates, which is a workaround I suggested in the bug report. I'm waiting for the rest of the project build right now.

1 1

[1.55] VS2013 massively failing
by Joaquin M Lopez Munoz 22 Oct '13

22 Oct '13

I understand this is being taken care of, but... VS2013 is failing to pass most libs in the release branch. For the one I care about most the problem is: D:\teeks99-10\boost\boost/mpl/aux_/preprocessed/plain/arg.hpp(45) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' which seems to be fixed in trunk. Thank you, Joaquín M López Muñoz Telefónica Digital

3 2

Reading & Parsing an .ini input file using BOOST... ..Thanks!!
by Rahul Mathur 22 Oct '13

22 Oct '13

All, I have an .ini input file which contains sample values like – --- App=| 5000 | 5001 | 0 | | | | 1BYTE | --- Starting with word (viz. App), followed by equal sign, than data within pipes (|) and blank space between two pipes ( | | ). Anything only between two pipes is to be read. I am looking to parse this input file. After parsing, assign each data to struct member type and than send this complete struct as socket. I am looking to use Boost property tree (or the needed one) and finally the ASIO to send the complete filled struct as stream. Any clue?

2 2

Request permission to apply patch to trunk.
by Beman Dawes 22 Oct '13

22 Oct '13

I'd like to apply the attached patch to trunk. It is not supposed to break anything on an svn checkout, but we held off applying it until 1.55 beta shipped because of concern it would be disruptive if it somehow messed up the build system right in the middle of getting the beta out. Thanks to Bjørn Roald for developing the patch. Without this patch, the only way to test modular-boost headers mechanism is to manually apply the patch yourself, and that pretty much limits testing. OK to apply? --Beman

5 7

[modernization][skelly] Surprising changes
by Agustín K-ballo Bergé 22 Oct '13

22 Oct '13

I was going through recent Boost.Spirit changes and I was surprised to see this code: #if (defined(BOOST_MSVC) && (BOOST_MSVC < 1310)) \ || (defined(__BORLANDC__) && (__BORLANDC__ <= 0x570)) \ || (defined(__GNUC__) && (__GNUC__ < 3)) \ || (defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ < 1)) # error "Compiler not supported. See note in <boost/spirit/core/config.hpp>" #else // Pass... Compiler supported. #endif modified into this code: #if (defined(__BORLANDC__) && (__BORLANDC__ <= 0x570)) # error "Compiler not supported. See note in <boost/spirit/core/config.hpp>" #else // Pass... Compiler supported. #endif The whole point of the check is to detect unsupported compilers. It seems the modernization changes do not take into account the context in which they are done. To Stephen Kelly: I would like to suggest going over your modernization commits looking for unwanted changes like this one, and reverting them. I have already revisited your modifications to Boost.Spirit and found all changes but the one I mentioned to be valid ones (thank you for those!). Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

2 1

[multiprecision] New binary floating point type
by John Maddock 21 Oct '13

21 Oct '13

Folks, One of the main feature requests during the multiprecision lib review was for a binary floating point type. There is now such a type in the sandbox under the "multiprecision.cpp_bin_float" directory - you will also need latest SVN Trunk to try this out. This new type is correctly rounded to nearest for all arithmetic operations plus binary-decimal conversions and sqrt. Minimal docs so far here: https://svn.boost.org/svn/boost/sandbox/multiprecision.cpp_bin_float/libs/m… I'd welcome comments, and if folks would like to try and break it, that would be cool too ;-) Regards, John.

2 4

[mpl] integral_c [type_traits] integral_constant limits
by vicente.botet 21 Oct '13

21 Oct '13

Hi, I was testing Boost.Ratio with gcc-4.6 c++0x and I get some compile errors when instantiating std::cout << boost::mpl::integral_c< boost::intmax_t, boost::integer_traits<boost::intmax_t>::const_max >::value ; ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:24:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a valid template argument for type 'long long int' because it is a non-constant expression ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a constant expression integral_wrapper.hpp:72 contains typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next; The same line pass with gcc-4.6, gcc-4.5 and gcc-4.5 c++0x with just a warning. ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:23:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] integral_c is by integral_constant, but integral_constant doesn't needs next a prior types. This means that with the current implementation we can not use integral_constant with the max value of the type. Do you think this is a bug in integral_constant? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 6

[config] Macro for unused declarations
by Jeremiah Willcock 21 Oct '13

21 Oct '13

Would it be possible to have a macro for __attribute__((unused)) and similar pragmas to portably avoid "unused typedef" and related warnings (especially from recent versions of GCC)? I have mostly removed those in Boost.Graph, but there are some that need to remain---creating a typedef to a member type of a class to make sure that the member exists, for example. Thank you. -- Jeremiah Willcock

3 2

When Boost modularization and Git migration coupling were accepted on this ML?
by Vicente J. Botet Escriba 21 Oct '13

21 Oct '13

Hi, I would not take the time to inspect all the post relating to this subject. There are a lot of post related to the subject, a lot of discussion, but what I'm locking for is a decision. So please don't replay to this post by telling me, you have just to use this tool or this other tool to have the answer. If you consider that this post is bicksheding or a bad post, please, just ignore it. I remember a post that deceded to move to Git long time ago. I would just know if (and when) the Boost community has decided to couple the move to Git and the Boost modularization. And i would like to know also if changes to the trunk repository without requesting authors permission were allowed on this move. Who accepted the plan described by S. Kelly ? Who gave him the right to update the whole Boost repository? Was this discussed on this ML or on a specific ML that is not an official Boost ML? Le 18/10/13 00:24, Stephen Kelly a écrit : > my plan for modularizing and modernizing Boost was roughly this: > > * Phase 0 - remove dead weight by bumping compiler feature requirements > * Phase 1 - move some files around so that the modularized repos form a > mostly directed graph > * Phase 2 - Form some kind of 'boost core library' or 'boost feature > normalization library' from the guts of existing libraries like > type_traits, static_assert, config mpl and utilities. > * Phase 3 - Try to port the mpl to variadic templates so that the > dependency on Boost.PP is not needed when variadic templates are available. Apologies if this is clear for most of you. IMHO, this kind of decisions should be posted with an explicit title. Best, Vicente

3 2

C++Now 2014: Call for Submissions
by Hartmut Kaiser 20 Oct '13

20 Oct '13

============================================== C++ Now Conference 2014 Aspen CO, USA, May 12-17, 2014, www.cppnow.org ============================================== Call for Submissions -------------------- We invite you to submit session proposals to the 2nd annual C++ Now Conference (Aspen CO, USA, May 12-17, 2014). Building upon the resounding success of C++ Now 2013 and five years of BoostCon, C++ Now 2014 will present leading speakers from the whole C++ community. The C++ Now Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++ Now have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. At C++ Now 2014 we would like to focus on the now established C++11 standard and the new, upcoming C++14 and how those standard are and will shape C++'s future. However, by no means this is intended to restrict the topics of proposals we hope to see. Any other topic related to C++ as outlined below is perfectly fine for submission. Important dates --------------- New proposal submissions due: December 8th, 2013. Proposals decisions sent (tentative program available): January 30th, 2014. Fully scheduled program available: February 24th, 2014. Best Presentation Awards ------------------------ We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++ Now website for that year and a plaque containing all the C++ Now conference information. Session topics -------------- Topics of interest include, but are not restricted to, the following: * C++11/14 and how it changes life for users and library writers * General tutorial sessions on C++11/14, the C++11/14 Standards library, and one or more Boost libraries * Parallelism in the new C++11/14 standard * Parallel, distributed and GPGPU topics relating to C++ * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to C++ users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11 or C++14, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 or C++14 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 or C++14 and Boost. Workshops Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). Submission details ------------------ All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2014. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++ Now website and will be available to attendees. For general information on the C++ Now 2014 paper submission or the scope of technical papers solicited; please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2014(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Joel Falcou, email: joel.falcou(a)lri.fr (Program Committee Chair) Jon Kalb, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[modularization] Trying it out doesn't quite work?
by John Maddock 20 Oct '13

20 Oct '13

OK I'm following https://svn.boost.org/trac/boost/wiki/TryModBoost Git clone proceeds OK, and I seem to have everything I should have, likewise bootstrapping b2 proceeds OK. But: b2 headers does nothing at all. Trying: b2 --with-regex results in all the expected compile errors 'cos the headers aren't found. What gives? Thanks, John. PS this is on Windows Vista.

2 1

[modularization] What do we do with "glue" headers?
by John Maddock 20 Oct '13

20 Oct '13

Trying to get this discussion somewhat back on track... There are many libraries in Boost that have "glue" headers: by this I mean small headers that allow library A to interoperate with library B. Often these are simply specializations of traits classes or function overloads, are relatively trivial, and are not included unless you need them to be. By this I mean that: suppose library B wants to interoperate with lib A. It defines a special header which #includes what it needs from lib A and defines whatever specializations are required to get the two libraries working together. Now here's the thing: there is no dependency from lib B to lib A *unless you are already using both libraries*. A good example would be the serialization lib: a simple dependency tracker would show this up as a dependency to a large part of Boost, but in fact that's not true: in the vast majority of those cases there is no such dependency unless you actually want to use both libraries together and do so by including the "glue" header. So where does the glue header belong? In most cases if you want B to interoperate with A then you define a header which: * Includes headers from both libraries. * Uses the public interface of A, but may access the internals of B (think serialization). Which would imply that the header belongs with B. Pure and simple. Except it's not, because these two libraries may be peers, and interoperability may be more complex than simply unidirectional. I don't have an answer here, but it seems to me that "dependency" is a more complex thing than simply what-includes-what (and that's without getting into header file, vs source file, vs test file dependencies). Cheers, John.

9 15

[multi_index] problems with initializer lists in Intel 14.0 for Linux
by Joaquin M Lopez Munoz 20 Oct '13

20 Oct '13

Hi, I'm having here the same problems as described for Visual Studio 2013, only in an amplified way: http://tinyurl.com/pclssoe http://tinyurl.com/nzwzpu6 Any clue much appreciated. Joaquín M López Muñoz Telefónica Digital

1 0

[multi_index] problems with initializer lists in Visual Studio 2013
by Joaquin M Lopez Munoz 20 Oct '13

20 Oct '13

I think this is related to the similar problem just discussed in connection with Boost.Unordered with the same compiler. The following struct employee { employee(int id_,std::string name_,int age_,int ssn_); // ... }; employee_set es8({{0,"Rose",40,4512},{1,"Mary",38,3345}, {2,"Jo",25,7102}}); gives me (see http://tinyurl.com/pg4fsln ) ..\libs\multi_index\test\test_copy_assignment.cpp(159) : error C2440: 'initializing' : cannot convert from 'initializer-list' to 'boost::multi_index::multi_index_container<[...]>' No constructor could take the source type, or constructor overload resolution was ambiguous and this es9={{0,"Rose",40,4512},{1,"Mary",38,3345},{2,"Jo",25,7102}, {0,"Rose",40,4512}}; results in ..\libs\multi_index\test\test_copy_assignment.cpp(162) : error C2593: 'operator =' is ambiguous D:\teeks99-10\boost\boost/multi_index_container.hpp(329): could be 'boost::multi_index::multi_index_container<[...]> &boost::multi_index::multi_index_container<[...]>::operator= (std::initializer_list<employee>)' D:\teeks99-10\boost\boost/multi_index_container.hpp(321): or 'boost::multi_index::multi_index_container<[...]> &boost::multi_index::multi_index_container<[...]>::operator = (boost::multi_index::multi_index_container<[...]> &&)' D:\teeks99-10\boost\boost/multi_index_container.hpp(313): or 'boost::multi_index::multi_index_container<[...]> &boost::multi_index::multi_index_container<[...]>::operator = (const boost::multi_index::multi_index_container<[...]> &)' while trying to match the argument list '(employee_set, initializer-list)' Is this the compiler's fault or mine? Any applicable library-side workarond? Thank you, Joaquín M López Muñoz Telefónica Digital

1 0

Password Reminder Troubles
by Olaf van der Spek 19 Oct '13

19 Oct '13

Hi, The mailing list password reminder doesn't seem to work for me @ olafvdspek(a)gmail.com and ml(a)vdspek.org. Is there a known issue (sending mail to gmail)? Olaf

2 2

[Serialization] How to retrieve a class version in an archive without loading?
by nico 18 Oct '13

18 Oct '13

Hello. My question is about program rollback and the management of archive compatibility : let's say I saved on object of type T with my program in version 1.35 => archive.txt. If I roll back my program to a previous version (let say 1.30), I'd like to check (without trying to deserialize for performance issue) if T in 1.30 has the same "BOOST_CLASS_VERSION" as the object saved in archive.txt. *In brief : is there a way to retrieve the BOOST_CLASS_VERSION of T stored in the archive ?* I read boost code, but I didn't find a "quite direct" way to do that. It seems I must get cobject_id_vector of basic_iarchive_impl, but all this stuff is private. Is their another non-intrusive way to do it ? (By non-intrusive I mean : only using the boost public stuff, or at least with a simple inheritance to get protected member of base classes?). Thanks in advance. nicolas.

2 1

Re: [boost] Boost Serialization on Sun Solaris with rwtools7_std
by Brian Wood 18 Oct '13

18 Oct '13

From: Duc Tran: > That's not all errors, still have many. > Unfortunately, my company is unable to sponsor it. I have to do it myself. > Do you have any suggestions? I have alternative serialization approach. Unlike traditional library approach most of the code only runs on one platform as an on line code generator. I believe this makes porting to other platforms simpler than traditional approach. I'm willing to port my software to Solaris if you are interested. It should be easy. It would be nice to have someone to ask about Solaris install/admin questions. Additionally I'm willing to donate 15 hours/week for six months on a project that uses my software. -- Brian Ebenezer Enterprises http://webEbenezer.net

2 1

[mpi][type_traits] BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION macro missing
by Jeremiah Willcock 17 Oct '13

17 Oct '13

This macro was used in Boost.MPI, and it seems to no longer be defined in the Boost trunk, leading to compiler errors. Was it removed on purpose, and what should be done with the call to it in <boost/mpi/packed_iarchive.hpp>? -- Jeremiah Willcock

2 5

Extensive interdependencies in Boost
by Philip Bennefall 17 Oct '13

17 Oct '13

Hi all, I have been doing some tests with bcp recently, and the number of files I get for even the smallest header-only libraries (at least on the surface) is quite surprising to me. I know that not all files are used for compilation on a given platform, but I would still like to avoid putting 1253 files (11.7 MB) in my source tree just because I use a tiny part of Boost (boost/unordered_map.hpp in this case). I am wondering, will the effort that I have been reading about to modularize Boost, attempt to reduce some of these interdependencies? Or is the idea more about reducing the download size of the Boost distribution itself? Thanks in advance for any clarification. Kind regards, Philip Bennefall

3 3

[Correction] Extensive interdependencies in Boost
by Philip Bennefall 17 Oct '13

17 Oct '13

I'd like to correct some numbers in my recent post. I was looking at a directory containing the Boost files that had been put in a GIT repository so it had some files in it that were related to that. The true numbers are 1239 files (11.6 MB) when using bcp on boost/unordered_map.hpp. Sorry about the carelessness. Kind regards, Philip Bennefall

1 0

Contributing to boost
by Cosmin Boaca 17 Oct '13

17 Oct '13

Hi, My name is Cosmin Boaca and i would like to contribute to boost. I have contributed to some other open-source projects before and i have some C++ programming experience. I have no prior experience with boost. Can you give me some tips about what should i do first ? Thanks, Cosmin Boaca

4 3

Boost Serialization on Sun Solaris with rwtools7_std
by Duc Tran 17 Oct '13

17 Oct '13

Hi All, My project is using rwtools7_std library on Sun Solaris. However, Boos Serialization needs stlport4 and these two libraries cannot work together. Does anyone use Boost on Sun Solaris with rwtools7_std before? Can I change Boost library to use rwtools7_std instead of stlport4? The reason is my project has to use rwtools7_std. Thank you. Dennis

2 7

[regression test][IBM_Canada_Ltd] Regression tester stuck at rev 86223
by Joaquin M Lopez Munoz 16 Oct '13

16 Oct '13

Hi, a heads up: IBM_Canada_Ltd is cycling regulrly, but seems to be stuck at rev 86223, dating from Oct 9. Best, Joaquín M López Muñoz Telefónica Digital

1 0

GSoC 2014
by Sumol Lodha 16 Oct '13

16 Oct '13

Hi, My name is Sumol. I'm a 3rd year Computer Science student. I am new to Open Source Development and want to explore and experience it. I am interested to work for Boost in GSoC 2014. Seeing last year GSoC projects of BOOST I would be really interested in working projects related to maths and computing. Any pointers on how should I go about it ? Thanks, Sumol

4 4

Is there interest in a library for object (especially STL object) marshalling?
by Roger Sanders 16 Oct '13

16 Oct '13

Hi there, I'm not totally sure if this is the right "fit" for boost or not. Perhaps this problem isn't general or abstract enough to warrant inclusion within boost, but I thought I'd send an email around to see what people thought. I've written a library that I've been using extensively, both for my own code, and more recently for a large project in my work, that allows STL objects to easily be exchanged over a function call, even if the caller and the target function represent those STL objects using incompatible binary layouts. This is intended in particular to deal with the common problem of sharing STL objects between multiple compiled assemblies, such as a main executable and satellite DLL's. I'm already using this library extensively to exchange STL objects over pure virtual interfaces for a plugin-based application. The traditional advice people give is "don't use STL objects across DLL boundaries", but this is impractical for applications that are heavily modularized, or plugin-based applications with complex interfaces. Dealing with raw arrays and pointers is often difficult and error-prone, hence why we have STL containers to begin with. Returning data from a function call can also become extremely difficult when STL containers aren't used. With an array for example, if the total number of elements cannot be known by the caller, this can lead to fixed-sized buffers being used with hard-coded maximums, or functions requiring multiple calls, either to determine the size of the data, or to free an allocated buffer that's been returned. Attempting to use STL containers across assembly boundaries without addressing STL compatibility issues however basically requires you to use the exact same compiler version and compiler flags when building each assembly, which is not really possible with a plugin system designed to allow third-party plugins, or even simply with assemblies built at different times on different systems, and it's also inconvenient for development, since you can't easily compile just one assembly with debug compiler settings, while leaving the other assemblies compiled with release compiler settings. Ideally, you want the same signature for a function or method, whether the target code is contained within the same assembly or not. The goal is to make these assembly boundaries "invisible", so you can just write the same code to access functions, regardless of where the code for the target function is located. With the help of this library, along with a simple inline wrapper function which the caller is basically unaware of, that can be achieved, and existing code which makes use of STL objects can be shifted into separate assemblies without refactoring. I haven't found another library like this in the public domain, that attempts to solve this issue comprehensively for any type. Some of the points about my current library implementation are as follows: -Fully template based, with all code defined in header files. -Support for all *primary (see exclusions below) STL container types up to C++11, including strings and keyed containers. -Supports infinite nesting of STL container types, IE: std::vector<std::list<std::map<std::wstring, std::stack<unsigned int>>>> -Heavily optimized, with profiled performance comparable to the best possible hand-written marshalling code. -Extensible, so new STL container types, or boost container types for example, and potentially user-defined types, can be supported and marshalled in a consistent manner, even when nested within each other. *The only three containers I'm aware of that I haven't supported yet are std::pair, std::tuple, and std::bitset, although I can include support for them easily enough. Although difficult, I can also think of how to add support for pointer types such as std::shared_ptr, where object lifetime and destruction can be correctly and automatically managed across assemblies when these types are marshalled. The only compiler requirement here is that each assembly uses a compatible C++ ABI, or at least, as much as is required to allow calling a virtual member function on an object that was constructed within another assembly. What I wanted to get an idea on is whether there is any interest in having something like this included as part of boost? Perhaps there's enough scope here for a general "marshalling" library, that would address some other similar concerns in the future? There would be a fair amount of work to do in order to "boostify" the library and write the corresponding documentation, but I'd be willing to do it if there was interest. Any feedback, thoughts, criticisms? Thanks, Roger Sanders.

3 4

Re: [boost] Fastest Data-structure maybe from STL or Boost ..!!
by Andrew Hundt 15 Oct '13

15 Oct '13

On Mon, Oct 14, 2013 at 11:22 PM, Sylvain Bougerel < sylvain.bougerel.devel(a)gmail.com> wrote: > > > It's seems you need 2-dimensional sorting, one dimension for data, one > for > time. I have a library that is written for this kind of real-time analysis > in multi-dimension, it has k-d tree containers that are self re-balancing, > with insertion in fractional amortized time. You can check it out here: > http://spatial.sourceforge.net/ > > I've been wanting to propose it for review on boost, but never got around > to do it, cause I believe the documentation is sub-par. How does this compare to the Spatial Indexes in Boost.Geometry? http://www.boost.org/doc/libs/1_54_0/libs/geometry/doc/html/geometry/spatia… Cheers! Andrew Hundt

2 1

Testing clang in Windows using VC++ RTL with Boost libraries
by Edward Diener 15 Oct '13

15 Oct '13

I have been trying to test clang in Windows using the VC++ RTL with Boost libraries but I am unable to do so with the clang toolset in Boost Build. The main reason for this is that clang in the configuration I want to test only takes a subset of the gcc command-line options but the Boost Build clang toolset is for clang on Linux ( or a Unix-like environment on Windows like cygwin or MingW/msys ). I am neither knowledgable enough or willing enough to try to create such a Boost Build toolset myself. So I am going to stop. I wish the clang people and Chandler Carruth best of luck getting it to work for Windows using VC++ RTL.

2 2

[trac] [predef] No `prefef` component in trac
by Michel Morin 15 Oct '13

15 Oct '13

There is no `predef` component, which will be shipped in Boost 1.55, in trac. Thanks, Michel

2 5

[predef] missing file On MacOS 10.7.5.
by Vicente J. Botet Escriba 15 Oct '13

15 Oct '13

Hi, I'm getting this error clang-darwin.compile.c++ ../../../bin.v2/libs/thread/build/clang-darwin-3.2x/debug/link-static/threading-multi/pthread/thread.o In file included from ../../../libs/thread/src/pthread/thread.cpp:33: In file included from ../../../boost/lexical_cast.hpp:156: In file included from ../../../boost/math/special_functions/sign.hpp:18: In file included from ../../../boost/math/special_functions/detail/fp_traits.hpp:27: In file included from ../../../boost/detail/endian.hpp:9: In file included from ../../../boost/predef/detail/endian_compat.h:11: ../../../boost/predef/other/endian.h:61:25: fatal error: 'sys/endian.h' file not found # include <sys/endian.h> ^ On MacOS 10.7.5. Please could this be fixed? Is there a test on the regression test using this file? Best, Vicente

5 15

Fastest Data-structure maybe from STL or Boost ..!!
by Rahul Mathur 15 Oct '13

15 Oct '13

All, I wish to record 1000 real time data which need to be in sorted order. I used STL MAP which sorts using KEYS and than sorted the value using STL VECTOR, the complete scenario give me almost 6ms of time analysis. The TARGET is to achieve almost 1.5 - 2.0 ms. Also, once this data structure is completely filled I want to delete the first data and replace it with the new data. Can I have the fastest data structure (STL or BOOST) techniques for the same. ~ Thanks!!

5 4

[release/atomic] request permission to merge 86144
by Tim Blechmann 15 Oct '13

15 Oct '13

i'd like to merge r86144 into release. it is not exactly a bugfix, but it enables double-width cas support for msvc, which is rather important for many lock-free algorithms to be lockfree with this toolchain (including some configurations of stack/queue of boost.lockfree). thnx, tim

3 8

Boost ASIO - Client Request TCP Help..!!
by Rahul Mathur 14 Oct '13

14 Oct '13

All, Below is the client request code which makes a CONNECT request to remote SERVER (having IP & PORT#) but gives error code during send() process - --- #include <iostream> #include <string> #include <boost/asio.hpp> namespace opp = boost::asio::ip; struct PacketFormat { unsigned short length; //Length int sequenceNumber; }; int main(int argc, char* argv[]) { std::string port = "8000"; std::string hostname = "X.X.X.X"; boost::asio::io_service io_service; opp::tcp::resolver resolver(io_service); opp::tcp::resolver::query query(hostname, port); opp::tcp::resolver::iterator iter = resolver.resolve(query); opp::tcp::resolver::iterator end; // End marker. // Looking for a successful endpoint connection opp::tcp::socket socket(io_service); boost::system::error_code error = boost::asio::error::host_not_found; while (error && iter != end) { socket.close(); socket.connect(*iter++ , error); } if (error) throw boost::system::system_error(error); std::cout << "Connected ..Thanks!! \n" << std::endl; PacketFormat pf; // where PacketFormat is struct defined pf.length = 236; pf.sequenceNumber = 2; std::cout << "Sending Logon Message.. . ..!! \n" << std::endl; std::size_t n = opp::tcp::socket::send(iter, boost::asio::buffer(&pf)); if (n < 0) std::cerr << "ERROR writing to Server .. . ..\n" << std::endl; std::cout << "Logon Message Sent.. . ..Thanks!!\n" << std::endl; if (n < 0) std::cerr << "ERROR writing to Server .. . ..\n" << std::endl; std::cout << "Logon Message Sent.. . ..Thanks!!\n" << std::endl; return 0; } __ The error message obtained is - -- # g++ testclient.cpp -o testclient -lboost_system -lboost_thread testclient.cpp: In function âint main(int, char**)â: testclient.cpp:42: error: no matching function for call to âbuffer(PacketFormat*)â /usr/local/include/boost/asio/buffer.hpp:704: note: candidates are: boost::asio::mutable_buffers_1 boost::asio::buffer(const boost::asio::mutable_buffer&) /usr/local/include/boost/asio/buffer.hpp:717: note: boost::asio::mutable_buffers_1 boost::asio::buffer(const boost::asio::mutable_buffer&, size_t) /usr/local/include/boost/asio/buffer.hpp:733: note: boost::asio::const_buffers_1 boost::asio::buffer(const boost::asio::const_buffer&) /usr/local/include/boost/asio/buffer.hpp:746: note: boost::asio::const_buffers_1 boost::asio::buffer(const boost::asio::const_buffer&, size_t) /usr/local/include/boost/asio/buffer.hpp:762: note: boost::asio::mutable_buffers_1 boost::asio::buffer(void*, size_t) /usr/local/include/boost/asio/buffer.hpp:772: note: boost::asio::const_buffers_1 boost::asio::buffer(const void*, size_t) __ Please help for L#42 "tcp::socket::send()" proper call. I believe above code fine apart from L#42 error. Thanks!!

4 12

Requesting svn access
by Mathias Gaunard 14 Oct '13

14 Oct '13

Hi, There are a couple of warnings generated by unmaintained libraries that I'd like to fix. (In particular https://svn.boost.org/trac/boost/ticket/9115) Would it be possible to have write access so that I can commit these to trunk and then to release?

3 2

[config] Patch for clang.hpp to support clang in Windows using VC++ RTL
by Edward Diener 14 Oct '13

14 Oct '13

Once Boost 1.55 is out the doors can I apply the attached patch for clang when _MSC_VER is defined ? Unfortunately clang in this situation does not currently support the C++11 types char16_t or char32_t ( there is a bug report for this ), and this means trying to compile Boost libraries like type_traits without this patch yields many errors. I would have used the BOOST_WORKAROUND macro but clang does not support a value which gives a single number for the compiler version so I felt that drumming up multiple BOOST_WORKAROUNDs using major/minor/patch version numbers was too much of a hack to bother about.

2 3

Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
by Joaquin M Lopez Munoz 14 Oct '13

14 Oct '13

I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? Thank you, Joaquín M López Muñoz Telefónica Digital

6 23

[algorithm][array] Inspection report (tabs)
by Michel Morin 14 Oct '13

14 Oct '13

Hi Marshall, An inspection report says that some files contain tabs: ( http://boost.cowic.de/rc/docs-inspect-trunk.html ) algorithm boost/algorithm/cxx14/equal.hpp: *Tab* boost/algorithm/cxx14/mismatch.hpp: *Tab* libs/algorithm/string/doc/external_concepts.html: Unlinked file libs/algorithm/string/test/find_test.cpp: *Tab* libs/algorithm/string/test/split_test.cpp: *Tab* libs/algorithm/test/iterator_test.hpp: *C*, *Lic*, *Tab* array libs/array/doc/Jamfile.v2: *C*, *Lic* libs/array/test/array_constexpr.cpp: *Tab* libs/array/test/array_getfail1.cpp: *Tab* Regards, Michel

1 0

Permission to proceed?
by Stephen Kelly 14 Oct '13

14 Oct '13

Hello, Now that the beta has been out for a while, I'd like to proceed with my clean-up commits in trunk. I'd like to commit the patch in http://thread.gmane.org/gmane.comp.lib.boost.devel/244392/focus=244397 immediately and then proceed to remove the resulting dead code. Can I go ahead and do that? I assume that does not have any effect on the release branch. Thanks, Steve.

6 13

Re: [boost] Improving Documentation
by Andrew Hundt 14 Oct '13

14 Oct '13

On Fri, Oct 11, 2013 at 2:49 PM, Robert Ramey <ramey(a)rrsd.com> wrote: > Mathias Gaunard wrote: > > On 11/10/13 15:31, TONGARI J wrote: > > > >> I think Doxygen is fine for "regular" libraries, but I always have a > >> question: how could a library like Spirit be doucumented with it? > > > > Same as any other library. > > You document the data types and the functions. > > what about the type constraints - aka concepts? > and templates? You can document template parameters with doxygen. If you are using the boost concept check library you can also use those classes to document your concepts. I believe gil does that if you would like an example. You can also always add custom fields fairly easily if none of the existing ones meet you needs. Cheers! Andrew Hundt

5 5

[config][release] Release notes for old compilers.
by Daniel James 14 Oct '13

14 Oct '13

Hi, I added a little release notes for config, and also a note about removing support for older compilers in the future. If this concerns you, please give it a quick check and let me know if you want any changes. This release note is not a promise that future changes will or won't be made, and it can be changed if appropriate. Sorry that this is a bit late. We can still change the release notes after the beta (and final) release, so don't worry about that. thanks, Daniel

5 12

Review request: Require a SFINAE capable compiler
by Stephen Kelly 14 Oct '13

14 Oct '13

Hello, Several of the ancient compilers define BOOST_NO_SFINAE. The attached patch removes support for those versions of the compilers which are not capable of SFINAE. This bumps the compiler requirement to remove support for Borland 5.x, Metrowerks prior to 9.0, and SunPro prior to 5.7. Compilers based on EDG 238 are also affected, though it is unknown what those are. Ok to commit? Thanks, Steve.

6 12

[compiler workaround] Are we purging history?
by Daryle Walker 14 Oct '13

14 Oct '13

As I understand it, the people modernizing Boost code by getting rid of old compiler workarounds are doing two things: 1. Remove the workaround macro flags and the code that uses them, leaving the code that doesn't use the workarounds behind. 2. Purging those workaround macros from Boost.Config. If we are doing [2], why? Doing [1] is sufficient for modernization. Doing [2] is just purging history that we spent blood/sweat/tears generating. Authors/maintainers generally have free reign to use as many or as few workarounds as they want. They can't do that if we're deleting that knowledge from Boost.Config. Daryle W.

3 2

Re: [boost] Improving Documentation
by Andrew Hundt 14 Oct '13

14 Oct '13

On Thu, Oct 10, 2013 at 4:29 PM, Mathias Gaunard < mathias.gaunard(a)ens-lyon.org> wrote: > > Documentation like this is generated by preprocessing Doxygen XML output > to integrate it into Boostbook and have a good look for C++ references. > It has most of what you can expect from Doxygen + the Boostbook stuff > which gives better cross-referencing than simple Doxygen. > > I personally don't understand how one cannot notice that the blue bits > that become underlined when you hover them and change colors once visited > are hyperlinks (especially since that's also true for any other hyperlink > in Boost docs and most of the World Wide Web). > What do you suggest would be better? I believe part of the problem is that everything is blue. For instance, on the boost.lockfree page: http://www.boost.org/doc/libs/1_54_0/doc/html/lockfree/reference.html#heade… - The following words are blue: - namespace, template, bool, struct, capacity, template, typename, allocator, class, fixed_sized, queue, spec_queue, stack - Out of those, the following are links: - fixed_sized, capacity, allocator, queue, spec_queue, stack I believe there is a word to describe the concept of building things such that people expect to interact with them. I think it is called an affordance, so a link should "afford" clicking. https://en.wikipedia.org/wiki/Affordance When it is your first time ever on the site, even if you try to hover over one of the blue words, you may choose one that can't be clicked on, then assume the same applies for the others. IMHO, changing the color of links or making the underlines always visible could be helpful. One possible improvement would be what Mario Mulansky described. In the Table of Contents of libraries the Reference section could contain a list of links to headers, classes, functions, metafunctions, and definitions. Then if you click to the reference link where it currently just lists headers it could also provide the synopsis of the aforementioned items and links to the detailed docs. Right now all of the documentation is an extremely deep hierarchical structure, which if I recall my conventions correctly has been moved away from in modern user experience design. Most websites try to focus on getting you to the information you need in as few clicks as possible. That is why I mentioned cppreference.com in my previous email, if you check out that site nearly everything is 3 levels deep or less. Since boost is so much larger a total of 4 levels with the top one being the list of libraries would make sense. Some link to the libs unit test and/or example folders in each library would also be helpful. These are a couple small, concrete steps that would probably help with browsing but aren't too out there. It doesn't help some of the possibilities for improved text which could also benefit, but it does help many things at a high level. As a side note, I wonder if the boost main page could be better served as a wiki of some sort? Cheers! Andrew Hundt

3 2

[typeof] trunk build broken
by Agustín K-ballo Bergé 12 Oct '13

12 Oct '13

Boost.TypeOf is broken as of revision #85920 due to an invalid preprocessing directive. Patch attached. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

3 3

Re: [boost] Improving Documentation
by Andrew Hundt 12 Oct '13

12 Oct '13

On Friday, October 11, 2013, Mathias Gaunard wrote: > On 11/10/13 00:07, Andrew Hundt wrote: > > I believe part of the problem is that everything is blue. For instance, on >> the boost.lockfree page: >> >> http://www.boost.org/doc/libs/**1_54_0/doc/html/lockfree/** >> reference.html#header.boost.**lockfree.policies_hpp<http://www.boost.org/doc/libs/1_54_0/doc/html/lockfree/reference.html#heade…> >> >> >> - The following words are blue: >> - namespace, template, bool, struct, capacity, template, typename, >> allocator, class, fixed_sized, queue, spec_queue, stack >> > > It's clearly not the same shade of blue though. The links (capacity, > allocator, fixed, queue, spec_queue, stack) are closer to a greenish blue. > Do they appear difficult to distinguish to you? > > Maybe the color palette could be changed. It isn't just me. I believe two others in this email chain mentioned it took them a while to figure out too, and I have had to explain it to other users who are not on this list. The shades certainly don't "pop" and it could just be more syntax highlighting. There isn't anything distinguishing it a a link when you just look at the page and imagine not already being familiar with this documentation layout. Doxygen and other documentation tools don't really have anything like it. > > Some link to the libs unit test and/or example folders in each library >> would also be helpful. >> > > I agree for examples, but I don't think unit tests should appear in the > documentation. > > They can be obscure test cases that users don't need to worry about. > Yeah, it would be great if everything had micro examples at the bottom of each page but often the only thing that exists is a unit test. While it isn't a great situation it would be better than nothing. Cheers! Andrew Hundt

2 1

[type_traits] Variadic function pointer with __fastcall calling convention
by Edward Diener 12 Oct '13

12 Oct '13

In type_traits/detail/is_function_ptr_tester.hpp there are pointer to function signatures being tested which have the __fastcall calling convention and variadic functions. While MSVC accepts this code clang in Windows, which defines _MSC_VER and _MSC_EXTENSIONS, currently gives an error. The justification for giving an error is that __fastcall is a callee stack cleanup calling convention, so it cannot be used for variadic functions. There is a bug report regarding this in the Bugzilla for llvm at http://llvm.org/bugs/show_bug.cgi?id=12535. Comments have been made to me in e-mail and the clang developer's mailing list that it is a type_traits error to allow this, even for MSVC-emulation code. Of course we can temporarily fix this for clang on Windows, possibly with a BOOST_WORKAROUND solution for clang and see if/how clang eventually addresses the bug report. But I would like some sort of resolution so that clang on Windows can compile type_traits in the current Boost trunk.

3 11

[1.55.0] Beta 1 Available
by Marshall Clow 12 Oct '13

12 Oct '13

Boost release 1.55.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.55.0.beta.1/ This release contains 1 new library: * Predef: This library defines a set of compiler, architecture, operating system, library, and other version numbers from the information it can gather of C, C++, Objective C, and Objective C++ predefined macros or those defined in generally available headers, from Rene Rivera. For details of what's in the release, see http://www.boost.org/users/history/version_1_55_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 11

results pages not updating
by Michael Mathews 11 Oct '13

11 Oct '13

Neither the trunk nor release results have updated since Wednesday michael

1 0

[1.55][Math] Permission to apply bug fix?
by John Maddock 11 Oct '13

11 Oct '13

Is 1.55 release branch open for bug fixes again? If so I'd like to apply the patch for: https://svn.boost.org/trac/boost/ticket/9183 in https://svn.boost.org/trac/boost/changeset/86205 Many thanks, John.

2 1

Looking for thoughts on a new smart pointer: shared_ptr_nonnull
by Luke Bradford 11 Oct '13

11 Oct '13

Hi, I'm new to this list, so apologies for any oversights or faux pas. I've been finding a lot of use for a type of smart pointer I call shared_ptr_nonnull, which is a variation on shared_ptr which is never allowed to be empty. Specifically: (1) It doesn't have reset() with no arguments, doesn't have a default constructor, and doesn't have implicit conversion to bool (which would always be true.) (2) It throws an exception whenever there's an attempt to make it empty, i.e. in constructors, reset, assignment, and swap. For convenience, it's implicitly convertible to shared_ptr, and I have all of shared_ptr's templated operators implemented with possible combinations of shared_ptr and shared_ptr_nonnull. Usually it can be used just by changing the type of a shared_ptr. We have a lot of shared_ptrs, especially member variables, which are claimed to be "always valid" and this class enforces that, at compile time (1) and runtime (2). Has there been any discussion of something like this? Does anybody have any thoughts, suggestions, criticisms? Who's in charge of the smart pointer library these days? Thanks, Luke

20 113

Review wizards response and Boost reviews
by Edward Diener 11 Oct '13

11 Oct '13

I tried to contact the review wizards via their e-mail addresses to update some information on the Boost Formal Review Schedule page at http://www.boost.org/community/review_schedule.html but have heard nothing in response. I appreciate that they have a hard job to do for which most people would not want the responsibility. But it does seem to me, either by plan or because there appear to be no people willing to act as review managers, that the Boost formal review process has completely bogged down for some time now. Since I am interested in getting my own library reviewed I would like to volunteer to act as a Review Manager for other libraries. I have no particular library in mind but I am pretty knowledgeable and interested in some of the ideas of libraries on the review schedule. I have been a Review Manager for a past library and think I did a pretty good job. At the same time I am looking for a review manager for my Variadic Macro Data library. Unfortunately the link to it on the web page above is wrong. It is now on GitHub at https://github.com/eldiener/variadic_macro_data. Edward Diener

2 4

libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Error: junk at end of line
by Frédéric Bron 11 Oct '13

11 Oct '13

Hello, When building with i686-w64-mingw32 cross compiler, this is what I get: libs/context/src/asm/make_i386_sysv_elf_gas.S: Assembler messages: libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Warning: .type pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Error: junk at end of line, first unrecognized character is `m' libs/context/src/asm/make_i386_sysv_elf_gas.S:77: Warning: .size pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/make_i386_sysv_elf_gas.S:77: Error: junk at end of line, first unrecognized character is `m' libs/context/src/asm/make_i386_sysv_elf_gas.S:80: Error: junk at end of line, first unrecognized character is `-' ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-mingw-4.8.1/debug/address-model-32/link-static/target-os-windows/threadapi-win32/threading-multi/asm/make_i386_> What does that mean? Frédéric

2 4

[type_traits] VC++ and vararg function/mmeber functions and varargs
by Edward Diener 10 Oct '13

10 Oct '13

After going back and for with Mr. Lavavej from Microsoft about how VC++ treats functions/member functions which have varargs parameters and calling conventions, I learned that VC++ always treats all these function types as if the calling convention is __cdecl, no matter what the end-user specifies. Therefore attempting to match function and member function types taking varargs, with VC++ and compatibles, by having to specify __cdecl, __fastcall, and __stdcall calling conventions for every function/member function declaration with varargs, is a waste since these are not potential new types being tested by templates but just the same type redeclared. These occur in type_traits/detail files is_mem_fun_pointer_tester.hpp and is_mem_fun_pointer_tester.hpp when BOOST_TT_TEST_MS_FUNC_SIGS ( essentially _MSC_EXTENSIONS) is defined. I would like to remove these redundant declarations from these files. I have made sure that my tests for VC++ pass. I will test Intel C++, if it also emulates VC++ in this way. Can I make the change on trunk to these files once I ascertain that Intel C++ tests with type_traits also pass with this change ? Are there any other VC++ emulation compilers that need to be tested ?

4 11

[BGL] Maximum Weight Matching
by Pablo Madoery 10 Oct '13

10 Oct '13

Hello, We wrote the attached code in c++ using Boost, Blossom V and Guido Shafer Reduction to compute Maximum-Weight-Matching (not necessarily perfect) of a graph. We want to contribute to Boost BGL library. We are not experts in boost BGL library but we think that this code can be improved and used in Boost. We wrote this code becouse we need this algorithm and it wasn't in Boost. Although it is in Lemon Library ( http://lemon.cs.elte.hu/pub/doc/1.2.3/a00537.html) we need other algorithms and functions that are only in Boost. Thank you very much

3 3

Weird Boost 1.55 beta failure on VS2013 RC
by Niall Douglas 10 Oct '13

10 Oct '13

Can someone else confirm that Boost v1.55 beta is not compiling on VS2013 RC? I see lots of this: 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(42): error C2065: 'ReadableIterator' : undeclared identifier 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(42): error C2065: 'Iterator' : undeclared identifier 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(43): error C2448: 'BOOST_concept' : function-style initializer appears to be a function definition 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(43): error C2143: syntax error : missing ';' before ':' 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(43): error C2065: 'Iterator' : undeclared identifier 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(43): error C2923: 'boost::Assignable' : 'Iterator' is not a valid template type argument for parameter 'TT' 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(44): error C2143: syntax error : missing ';' before ',' 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(44): error C2059: syntax error : ',' 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(44): error C2065: 'Iterator' : undeclared identifier 2>G:\TripleGit\boost\boost/iterator/iterator_concepts.hpp(44): error C2923: 'boost::CopyConstructible' : 'Iterator' is not a valid template type argument for parameter 'TT' .... Here is the really weird thing - the macro BOOST_concept appears to not be defined, so if you do a: #ifndef BOOST_concept #error Hello #endif ... you get error Hello. Methinks this is a compiler bug in the RC, but can anyone else confirm? Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

2 2

How to center an element in Boost QuickBook?
by Niall Douglas 10 Oct '13

10 Oct '13

As the documentation for proposed Boost.AFIO comes together for this week's GSoC Milestone 1 (feel free to check it out at https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AFIO_Doc umentation/?), a problem has emerged. We'd like a matrix table containing ticks and crosses, and building such a thing in QuickBook is easy. However, we'd also like to center the ticks and crosses in each table cell, otherwise it looks poor. Is there some way I haven't realized of aligning content in Boost QuickBook, or even BoostBook itself? The DocBook documentation suggests one can do a '''<entry align="center">'''__tick__'''</entry>''' (the triple single ticks escape from QuickBook into BoostBook). However unfortunately BoostBook defines CSS which overrides the per-cell alignment :( Thanks in advance for the help. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

9 22

Try out a multi-dimensional adapter class template?
by Daryle Walker 10 Oct '13

10 Oct '13

I added a new class template for my library at <https://github.com/CTMacUser/ArrayMD>. It's called "multiarray," and it's an adapter class like stack and queue. But the new interface is only for accessing elements. Besides the element and container types, the template header for the class takes the number of dimensions. The class uses at, operator [] and operator () to access an element. It has methods to read/write the shape of the array and the priority of each index. There are no methods to change the number of elements stored; you have to either use a fixed-size container or sub-class the multi-array to add methods to change the size. (The container sub-object is protected, like the Standard adapters.) I split the main code into two base class templates, because the code for computing the offset from an index tuple and the code for referencing an element were nearly distinct. This really screws up my attempt at Doxygen comments. Any ideas? Or is my case too complex for what Doxygen's author thought could be handled. Daryle W.

5 9

[tokenizer] Some remarks
by Robert Kawulak 09 Oct '13

09 Oct '13

Hi, I have a few proposals/questions related to boost::tokenizer: - the first template parameter of char_separator and other tokenizer functions could be defaulted to char to save typing and make it consistent with the defaults of tokenizer; - making the constructor of char_separator and other tokenizer functions non-explicit would allow for less verbose construction of a tokenizer; - the docs state that char_delimiters_separator is deprecated in favour of char_separator. Are there any plans to actually drop the former and change the default for the template parameter of tokenizer to the latter? I guess this might be controversial because interfaces and semantics of the two differ, so maybe providing a new template, say string_tokenizer, is a good idea? Combining the first two points, the following: auto t = boost::tokenizer<boost::char_separator<char>>( str, boost::char_separator<char>("-;|")); could be written more conveniently as: auto t = boost::tokenizer<boost::char_separator<>>(str, "-;|"); and adding the third point it would become: auto t = boost::string_tokenizer<>(str, "-;|"); which is IMO a significant improvement. Any thoughts? Best regards, Robert

1 0

[any] Infinite loop in boost::any in boost release 1.54.0 using Visual C++ 2010
by Bo Peng 09 Oct '13

09 Oct '13

This very simple code: #include <boost/any.hpp> #include <string> const boost::any getBoolVal() { return false; } int main() { boost::any vals[] = {1.0, std::string("1m"), getBoolVal()}; } When built using Visual C++ 2010, it will run into a infinite loop: ntdll.dll!_RtlAllocateHeap@12() + 0x8 bytes ntdll.dll!_RtlDebugAllocateHeap@12() + 0x86 bytes ntdll.dll!@RtlpAllocateHeap@20() + 0x1108a bytes ntdll.dll!_RtlAllocateHeap@12() - 0x28d8a bytes msvcr100d.dll!_heap_alloc_base(unsigned int size=44) Line 55 C msvcr100d.dll!_heap_alloc_dbg_impl(unsigned int nSize=8, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0, int * errno_tmp=0x002a3280) Line 431 + 0x9 bytes C++ msvcr100d.dll!_nh_malloc_dbg_impl(unsigned int nSize=8, int nhFlag=0, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0, int * errno_tmp=0x002a3280) Line 239 + 0x19 bytes C++ msvcr100d.dll!_nh_malloc_dbg(unsigned int nSize=8, int nhFlag=0, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0) Line 302 + 0x1d bytes C++ msvcr100d.dll!malloc(unsigned int nSize=8) Line 56 + 0x15 bytes C++ msvcr100d.dll!operator new(unsigned int size=8) Line 59 + 0x9 bytes C++ test.exe!boost::any::any<boost::any const >(const boost::any && value={...}, void * __formal=0x00000000) Line 73 + 0x49 bytes C++ test.exe!boost::any::holder<boost::any const >::holder<boost::any const >(const boost::any && value={...}) Line 177 C++ ... test.exe!boost::any::any<boost::any const >(const boost::any && value={...}, void * __formal=0x00000000) Line 73 + 0x71 bytes C++ test.exe!boost::any::holder<boost::any const >::holder<boost::any const >(const boost::any && value={...}) Line 177 C++ test.exe!boost::any::any<boost::any const >(const boost::any && value={...}, void * __formal=0x00000000) Line 73 + 0x71 bytes C++ test.exe!boost::any::holder<boost::any const >::holder<boost::any const >(const boost::any && value={...}) Line 177 C++ test.exe!boost::any::any<boost::any const >(const boost::any && value={...}, void * __formal=0x00000000) Line 73 + 0x71 bytes C++ test.exe!boost::any::holder<boost::any const >::holder<boost::any const >(const boost::any && value={...}) Line 177 C++ > test.exe!boost::any::any<boost::any const >(const boost::any && value={...}, void * __formal=0x00000000) Line 73 + 0x71 bytes C++ test.exe!main() Line 11 + 0x9c bytes C++ Sorry I don't know enough of the c++ standard to figure out whether it is because of Visual C++ or it is because of boost. But I think it is worth to raise it to the experts out here. Thanks Bo ---- http://www.pengbo.me

3 3

[Boost.extension] Current Status
by Sean Farrow 08 Oct '13

08 Oct '13

Hi, Does anybody know what the current status of the boost.extension library is, it's not been updated since 2008. Any help appreciated. Regards Sean.

2 1

[website][getting started] Linking to binaries
by Daniel James 08 Oct '13

08 Oct '13

On 8 October 2013 15:58, Tom Kent <lists(a)teeks99.com> wrote: > > The corresponding windows binaries for msvc-8.0, msvc-9.0, msvc-10.0, and > msvc-11.0 in 32 & 64 bit versions are now also available from sourceforge. > > https://sourceforge.net/projects/boost/files/boost-binaries/1.55.0_beta1/ We should probably link to binaries from the website somewhere. If not in the release notes, maybe there should be some information about alternative downloads on the download page. Any opinions? Also for other platforms? (e.g. debian packages). The getting started guide used to mention the old binaries, you can see what was removed at: https://svn.boost.org/trac/boost/changeset/82893/trunk/more/getting_started… We could put back something like that. Especially if anyone fancies writing it? I don't use windows much so I'm not the best person.

1 0

[graph] porting code from 1.46 to 1.54
by Maurizio Vitale 08 Oct '13

08 Oct '13

Hello boost, I'm trying to move some large code base to use boost 1.54. In some dark corner of it, the following was compiling fine: class Instance; typedef boost::setS OutEdgeList; typedef boost::listS VertexList; struct InstancePropertyTag { typedef boost::vertex_property_tag kind; }; typedef boost::property<InstancePropertyTag, Instance*> InstanceProperty; typedef boost::adjacency_list<OutEdgeList, VertexList, boost::bidirectionalS, InstanceProperty> Graph; typedef boost::property_map<Graph, boost::vertex_index_t>::type IndexGraph; under 1.54, I get 'attempt to form reference to void', but everything was fine under 1.46. I traced it a bit through template expansion, and the problem seems to be that the type for vertex_index_t is not found. The following declaration for InstanceProperty fixes (or hides) the problem: typedef boost::property<InstancePropertyTag, Instance*, boost::property<boost::vertex_index_t, int> > InstanceProperty; Does somebody know if some properties were added by default to graphs before and need to be explicitly added now? I don't find anything in the documentation and all examples I've found seem to imply that one wouldn't need to explicitly add a property declaration of vertex_index_t. Thanks a lot, Maurizio

3 4

[1.55.0] Release branch now open
by Marshall Clow 08 Oct '13

08 Oct '13

The release branch is now open for bug fixes and doc updates, without need to ask for a release manager's permission. It will remain open until Monday, October 28th. The 1.55.0 release is scheduled for November 4th. -- Marshall

1 0

[1.55.0] Release Notes
by Daniel James 08 Oct '13

08 Oct '13

Hello, If you haven't already, can you write your release notes for 1.55? You can send them to me, or add them yourself at: http://svn.boost.org/svn/boost/website/public_html/live/feed/history/ They're on the website at: http://www.boost.org/users/history/version_1_55_0.html thanks, Daniel

12 24

Boost.Application : Request for comments : Article / Thread Pool / Other Features / Documentation
by Renato Forti 08 Oct '13

08 Oct '13

Hi All, In this email I would like to discuss some areas of Boost.Application. 01) Thread Pool functionality One of the most recurring requests is that Boost.Application should provide Thread Pool functionality. A flexible Thread Pool can be a complex thing, need provide schedule polices, grow/reduce polices, Shutdown policies, deadline s and many others, and then I think that this feature devotes your own Boost library. The Boost.Application can be integrated easily with one Thread Pool provided by third parties, or the user can make one "specific" (Not flexible/Complex) to your needs, e.g.: I make a simple work queue model using Boost.Asio and Boost.Thread that I plug on Boost.Application, see these tutorial: * Creating a Work Queue (Thread Pool) Application Using Boost.Asio, Boost.Thread and Boost.Application http://www.codeproject.com/Articles/664709/Creating-a-Work-Queue-Thread-Pool -Application-Usin My question is: The boost users think that Boost.Application must provide a complex Thread Pool to be accepted? 02) Ideas (new features) So far these are the ideas proposed to improve Boost.Application: http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/application/f uture.html What functionality do you think should already be included in the first release, and not only in future versions? (Please mention here!) If you have any other ideas, (or improvement of current list) please post here so that I can update the "TODO" session. 03) Articles About "Boost.Application" I published other articles about "Boost.Application" on Code Project Website. Code Project Tutorials * Create a Windows Service Application http://www.codeproject.com/Articles/662221/Create-a-Windows-Service-Applicat ion-Using-the-Boo 04) Documentation Feedback Also, the library documentation was updated. If someone can take a look! Please, tell me if this is a little more understandable. * On-Line Documentation http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html 05) Boost.Application Resources [Other Boost.Application Resources] * Download Last Version https://sourceforge.net/projects/boostapp/ Note that the latest version is (10/07/2013): Boost.Application_beta_3a_release_5.zip (1.4 MB) * Please Write a Review https://sourceforge.net/projects/boostapp/reviews Please send comments. (Specify if you think if the library should be accepted as part of boost) Thank you very much! -- Renato

4 6

1.55.0 beta 1 release candidates available for testing
by Marshall Clow 08 Oct '13

08 Oct '13

Release candidate files for 1.55.0 beta 1 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: 9fa020efb06f5485628c646451b927c6 *boost_1_55_0b1_rc1.tar.gz 02d26b038ac96f19c3478d0c45a63c9b *boost_1_55_0b1_rc1.tar.bz2 de5f7d60b2387c4fe3d03eb327f095a9 *boost_1_55_0b1_rc1.zip 7deb9063846873452e6ec6918cb75a87 *boost_1_55_0b1_rc1.7z Thanks, --The release managers

7 13

Boost result_of maintainer
by Daniel Walker 07 Oct '13

07 Oct '13

Hi all, I have been the maintainer of boost::result_of since Doug Gregor handed it over to me a few years ago, but my circumstances are changing, and I'm afraid it's time for me to hand the library over to someone else. Any volunteers? - Daniel

3 5

boost 153 interprocess_mutex much slower in windows 7 than xp?
by Noll, Jeffrey T UTAS 07 Oct '13

07 Oct '13

We have 3 processes that are synchronized with an interprocess mutex. Basically one of them has a multiplier which allows the others to run at a synchronized accelerated rate. Under XP we typically can get it to run at 5000 times realtime. New desktop refreshes are coming out running Windows 7 and the same code with faster machines with more memory are maxing out at 250 times with 95%+ cpu idle time. Am new to boost so am wondering if we're doing something wrong. Here's the crux of the code. 3 processes and some shared memory. Share memory defines struct ds_control_sync { boost::interprocess::interprocess_mutex mutex; //Mutex to protect access to the queue boost::interprocess::interprocess_condition cond_running; //Condition to wait when the control software is running boost::interprocess::interprocess_condition cond_timestep; //Condition to wait until the control software is to run again }; struct ds_plant_sync { boost::interprocess::interprocess_mutex mutex; //Mutex to protect access to the queue boost::interprocess::interprocess_condition cond_running; //Condition to wait when the plant software is running boost::interprocess::interprocess_condition cond_timestep; //Condition to wait until the plant software is to run again }; Control process has a thread that waits for a signal to run once. DWORD __stdcall Control_Sync (LPVOID) { scoped_lock<interprocess_mutex> lock(sm_control_sync->mutex); while (1) { sm_control_sync->cond_running.notify_one(); sm_control_sync->cond_timestep.wait(lock); ns_common::TimeProfile_Periodic (&sm_io->status.control_sync, &sync_first, &sync_time); Control_PWM (); if (control_run) { Control_Run (); control_run = FALSE; } else { control_run = TRUE; } ns_common::TimeProfile_Execution (&sm_io->status.control_sync, &sync_first, &sync_time); } } Plant process has the same sort of thing DWORD __stdcall Plant_Sync (LPVOID) { scoped_lock<interprocess_mutex> lock(sm_plant_sync->mutex); while (1) { sm_plant_sync->cond_running.notify_one(); sm_plant_sync->cond_timestep.wait(lock); ns_common::TimeProfile_Periodic (&sm_io->status.plant_sync, &sync_first, &sync_time); Plant_Run (); ns_common::TimeProfile_Execution (&sm_io->status.plant_sync, &sync_first, &sync_time); } } And then main process counts down a multiplier to increase it's run rate. In this case 10000X boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> plant_lock(plant_sync.mutex); boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> control_lock(control_sync.mutex); mult = 10000; if(mult > 1) { iterations = 0; while(mult-- > 0) { plant_sync.cond_timestep.notify_one(); control_sync.cond_timestep.notify_one(); plant_sync.cond_running.wait(plant_lock); control_sync.cond_running.wait(control_lock); iterations++; } } Works great under XP, our new Windows 7 desktops it are dog slow by a factor of around 50. Any ideas why this would be? Thanks! Jeffrey Noll Software Engineer (860)654-6378 CONFIDENTIALITY WARNING: This email may contain privileged or confidential information and is for the sole use of the inteded recipients. Unauthorized disclosure or use of this communication is prohibited. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system.

5 5

Re: [boost] boost 153 interprocess_mutex much slower in windows 7 than xp?
by jim＠jc-bell.com 07 Oct '13

07 Oct '13

> We have 3 processes that are synchronized with an interprocess mutex. > Basically one of them has a multiplier which allows the others to run at a > synchronized accelerated rate. Under XP we typically can get it to run at > 5000 times realtime. New desktop refreshes are coming out running Windows > 7 and the same code with faster machines with more memory are maxing out > at 250 times with 95%+ cpu idle time. > > Am new to boost so am wondering if we're doing something wrong. Here's the > crux of the code. 3 processes and some shared memory. > ... It might be hitting the disk when it shouldn't be. Try pointing SysInternals' ProcMon at each and see if one's doing file accesses where the other isn't. (SysInternals.com.)

1 0

[interest] rich-typed smart pointers
by Julian Gonggrijp 07 Oct '13

07 Oct '13

Dear Boost members, I have designed a smart pointer that relies on the type system to offer safe and flexible automatic memory management at no runtime cost. It combines single ownership as in std::unique_ptr and reliable access from multiple places as in std::shared_ptr with some additional features. I believe it to be about as safe and practically useful as a smart pointer in C++11 could get. Further explanation and a proof-of-concept implementation is available over here: https://github.com/jgonggrijp/rich-typed-pointers There is no license yet, but you have my explicit permission to try the library and the example programs at your own risk. :-) Could this library be useful addition to Boost? I look forward to your comments. Thanks in advance, -Julian PS: a possible minor seed for discussion is the current lack of an implicit cast to bool. I agree with Jeff Flinn's argument why the implicit cast may be desirable [1]. However, it interferes with the comparison operators when one of the operands should be implicitly cast to weak_ptr, as explained in [2]. I could repeat myself and write comparison functions for all possible overloads, but this seems inelegant. [1] http://boost.2283326.n4.nabble.com/Looking-for-thoughts-on-a-new-smart-poin… [2] https://github.com/jgonggrijp/rich-typed-pointers/commit/89fcf2821cb39bbb9f…

5 24

[utility][enable_if]Fiddly function lookup failure on msvc11
by 山本賢一 07 Oct '13

07 Oct '13

Hi, I found a part of my code failed to compile with boost::enable_if_c when I was porting my code for msvc11 (Visual Studio 2012). The original code was bit too complex but I simplified it to boil down the issue. The simplified code is eventually like this: #include <boost/mpl/bool.hpp> #include <boost/mpl/not.hpp> #include <boost/utility/enable_if.hpp> template <class T> struct always_true : boost::mpl::true_ { }; template <class T> inline typename boost::enable_if_c< !boost::mpl::not_< always_true<T> // Argument of boost::mpl::not_ >::type::value // Refer the result of boost::mpl::not_ , int >::type get_one(T) { return 1; } void test() { get_one('a'); // Compile fails at this line with error C2893 } msvc11 fails to resolve the call to get_one() but I believe the code is definitely correct. With some more extra test, I found: (1)The same code compiles on msvc10 (Visual Studio 2010) and msvc9 (Visual Studio 2008). (2)If I changed the line I commented "//Argument of boost::mpl::not_" to "boost::mpl::true_", the code compiled on msvc11. template <class T> inline typename boost::enable_if_c< !boost::mpl::not_< boost::mpl::true_ // *** Argument of boost::mpl::not_ >::type::value // Refer the result of boost::mpl::not_ , int >::type get_one(T) { return 1; } (3)If changed the line I commented "// Refer the result of boost::mpl::not_" to ">::value", the code compiled on msvc11. template <class T> inline typename boost::enable_if_c< !boost::mpl::not_< always_true<T> // Argument of boost::mpl::not_ >::value // *** Refer the result of boost::mpl::not_ , int >::type get_one(T) { return 1; } The issue seems to be rather a compiler quirk of msvc11 than a enable_if's problem, but I posted the issue here because we need a workaround to avoid it (on msvc11) when we use enable_if. Please let me know if you have any idea about the issue. Thanks. Yamamoto

3 3

[algorithm] documentation mistakes in 'equal' and 'mismatch'
by Takatoshi Kondo 06 Oct '13

06 Oct '13

Hi, Marshall IIUC, I found some mistakes in the documentation of 'equal' and 'mismatch'. http://www.boost.org/doc/libs/1_54_0/libs/algorithm/doc/html/algorithm/CXX1… http://www.boost.org/doc/libs/1_54_0/libs/algorithm/doc/html/the_boost_algo… In the first code block, auto seq1 = { 0, 1, 2 }; auto seq2 = { 0, 1, 2, 3, 4 }; std::equal ( seq1.begin (), seq1.end (), seq2.begin ()); // true std::equal ( seq2.begin (), seq2.end (), seq1.begin ()); // Undefined behavior std::equal ( seq1.begin (), seq1.end (), seq1.begin (), seq2.end ()); // false The second seq1.begin() in the last line should be seq2.begin() as follows. std::equal ( seq1.begin (), seq1.end (), seq2.begin (), seq2.end ()); // false Similarly, std::mismatch ( seq1.begin (), seq1.end (), seq1.begin (), seq2.end ()); // <3, 3> should be std::mismatch ( seq1.begin (), seq1.end (), seq2.begin (), seq2.end ()); // <3, 3> Thanks, Takatoshi

2 1

[svn] Server problems?
by Rene Rivera 06 Oct '13

06 Oct '13

I'm getting a persistent error on te SVN server like so: === Froggy:trunk grafik$ svn up Updating '.': svn: E175002: Server sent unexpected return value (413 Request Entity Too Large) in response to REPORT request for '/svn/boost/!svn/vcc/default' === Any ideas? Rene -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

[circular-buffer] Missing images.
by Daniel James 06 Oct '13

06 Oct '13

Hi, I made a change to try to fix some broken links in the circular buffer documentation: https://svn.boost.org/trac/boost/changeset/86174/ You can see the broken links in the inspect report: http://boost.cowic.de/rc/docs-inspect-trunk.html#doc Although hopefully in a couple of hours they'll be gone. But there are still a couple of links to images which I can't find: 'circular_buffer.png' and 'space_optimized.png', did someone forget to check them in? It's probably best not to check them in at 'libs/circular_buffer/doc/html/images', but instead at something like 'libs/circular_buffer/doc/images', that way the images are kept separate from generated documentation. I'll help get the image links right, as it's more tricky than it should be. thanks, Daniel

1 0

[regression] Beagle Bone Black
by Jim Bell 05 Oct '13

05 Oct '13

For anyone interested, Boost regression tests fare pretty well on the $45 Beagle Bone Black (beaglebone.org) Stop by the release regression matrix and check it out (http://www.boost.org/development/tests/release/developer/summary.html) And while you're over there, investigate & fix a regression test failure on your platform: submit a patch and make the matrix a greener place! (See http://www.boost.org/development/bugs.html.) Cheers! -Jim

1 0

[log] logger linking problem
by Tadeusz Jordan 05 Oct '13

05 Oct '13

Hi everyone, I have been using Boost for some time now and really like it. Unfortunately, recently I have bumped into a linker issue when trying to use boost::log, was wondering if anyone has seen this before, or has any insights … thank you very much. The problem is described in the below post. http://stackoverflow.com/questions/18881602/boost-logger-linking-issue -- Sincerely, Tadeusz Jordan Software Engineer at The Broad Institute of MIT and Harvard MS Candidate in CS at Northeastern University This email message and any attachments are confidential and may be privileged. It is intended only for the individual or individuals to whom it is addressed and may not be saved, copied, printed, disclosed or otherwise used by anyone else. If you are not the intended recipient, kindly notify the sender and delete this email and any attachments immediately.

3 11

Re: [boost] [type_traits][function_types] Discard param const qualification, bug or feature?
by Sergey Zhuravlev 05 Oct '13

05 Oct '13

Signature type int(int, const std::string) can be used as parameter for some compiletime algorithm. For example, algorithm that generate new signature type with optimal transfer arguments int (int, const std::string&) or generate signature with all argument references int (int&, const std::string&) Can't use type_traits, function_types at that cases, because const be omitted. This will lead to compiletime error, if function with first signature call function with second signature and use arguments from function with first signature for this call. Signature type void(int, const std::string) can use as types tuple for some compiletime algorithm. Can't use type_traits, function_types, at that case, because const be lost. Signature type void(int, const std::string) can use as parentheses dropper for "types list", e.g. for macro parameter. (int, const std::string) => int, const std::string. Can't use type_traits, function_types, at that case, because const be lost. I think default behavior is correct, but need parameter for change this behavior. At least function_types.

6 16

lots of warning with gcc-4.8.1 + boost-1.54.0
by Neal Becker 04 Oct '13

04 Oct '13

Lots of warnings like this: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] when building 1.54.0 with gcc-4.8.1 (fedora f19)

8 9

[log] MSVC 9 build hangs
by Andrey Semashev 04 Oct '13

04 Oct '13

Hi, Many test results for Boost.Log on teeks99-03b-win2008-64on64 [1] show that the build aborts due to timeout. From the test setup description (2 GiB of RAM, 2 CPUs, 4 build jobs) it seems that the problem could be in the insufficient system resources. 4 jobs building Boost.Log can easily exceed 2 gigs of RAM, especially considering some of the memory is reserved by OS and other programs. If there isn't any swap, the build may be just aborting, and if there is, it's probably performing dead slow. And 2 cores might also be too limiting. Could the tester take a look what is happening on that setup? If it's not a resource problem, then I would appreciate any information on the problem. [1] http://www.boost.org/development/tests/trunk/developer/log.html

3 27

[ASIO] Safely shut down timer thread in boost::asio::io_service in Windows DLL
by Bo Peng 03 Oct '13

03 Oct '13

Hi folks, As you might already know, Windows DLL has quite some limitation about what you can do during its loading and unloading. For example, you can't 'join' a thread when unloading a DLL. The consequence of doing that, from my opinion, is quite serious: it will hang the process in a dead lock. I have a Windows DLL, which uses boost::asio::deadline_timer. I found that deadline_timer::async_wait creates a timer thread as a private member of io_service. This thread won't be shut down even if all the timers are cancelled. In the destructor of io_service, 'join' will be called on the thread. In some exceptional situation, users might exit their main function before destructs the io_service inside my DLL, so the destructor is called during the unloading of the DLL, which hangs their process. The following code demonstrates this issue. action.h and action.cpp are the code for the dll, main.cpp are the code for the application which uses the dll. action.h: #pragma once #ifndef _WIN32_WINNT #define _WIN32_WINNT 0x0501 #endif extern "C" __declspec(dllexport) void start(); extern "C" __declspec(dllexport) void stop(); action.cpp: #include "action.h" #include <boost/asio.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/thread.hpp> class Action { public: Action() : ios_(), timer_(ios_, boost::posix_time::seconds(1)), worker_() { } void start() { worker_.reset(new boost::thread(boost::bind(&Action::startEntry, this))); } void stop() { if (worker_) { ios_.post(boost::bind(&Action::stopEntry, this)); worker_->join(); worker_.reset(); } } private: void startEntry() { timer_.async_wait(boost::bind(&Action::timerHandler, this, _1)); ios_.run(); } void stopEntry() { timer_.cancel(); } void timerHandler(const boost::system::error_code& e) { if(e == boost::asio::error::operation_aborted) { std::cout << "Finished." << std::endl; } else { std::cout << "Triggered." << std::endl; timer_.expires_from_now(boost::posix_time::seconds(1)); timer_.async_wait(boost::bind(&Action::timerHandler, this, _1)); } } boost::asio::io_service ios_; boost::asio::deadline_timer timer_; boost::shared_ptr<boost::thread> worker_; }; boost::shared_ptr<Action> action; void start() { action.reset(new Action); action->start(); } void stop() { if (action) { action->stop(); action.reset(); } } main.cpp: #include <iostream> #include <windows.h> int main() { typedef void (__cdecl *PROC)(); HINSTANCE hInstLib = LoadLibrary(TEXT("dll.dll")); if (hInstLib == NULL) { std::cout << "Failed to load dll" << std::endl; return 1; } PROC startProc = reinterpret_cast<PROC>(GetProcAddress(hInstLib, "start")); if (startProc == NULL) { std::cout << "Failed to load start function" << std::endl; return 1; } PROC stopProc = reinterpret_cast<PROC>(GetProcAddress(hInstLib, "stop")); if (startProc == NULL) { std::cout << "Failed to load stop function" << std::endl; return 1; } startProc(); std::cout << "Press any key to exit..." << std::endl; getchar(); //stopProc(); FreeLibrary(hInstLib); return 0; } As you can see, stopProc() is commented out to simulate that the user doesn't have the chance to call the clean up function of my DLL. What I am wondering is, is it possible to shut down the thread whenever there isn't any timer outstanding. Or if I had access to the handle of this thread, I could call TerminateThread, which is allowed even during dll unloading. Regards, Bo

2 2