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

[test] missing include files
by Vicente J. Botet Escriba 12 Feb '13

12 Feb '13

Hi, I have needed to apply this patch to be able to compile with Boost.Test. Could I commit it? Best, Vicente svn diff boost/test Index: boost/test/tools/detail/print_helper.hpp =================================================================== --- boost/test/tools/detail/print_helper.hpp (revision 82823) +++ boost/test/tools/detail/print_helper.hpp (working copy) @@ -25,6 +25,7 @@ #include <boost/type_traits/is_array.hpp> #include <boost/type_traits/is_function.hpp> #include <boost/type_traits/is_abstract.hpp> +#include <limits> #include <boost/test/detail/suppress_warnings.hpp> Index: boost/test/utils/is_forward_iterable.hpp =================================================================== --- boost/test/utils/is_forward_iterable.hpp (revision 82823) +++ boost/test/utils/is_forward_iterable.hpp (working copy) @@ -33,6 +33,7 @@ // STL #include <utility> +#include <type_traits> #endif //____________________________________________________________________________//

2 2

[odeint] Docs don't build in 1.53.0
by John Maddock 12 Feb '13

12 Feb '13

I've finally got around to building the PDF docs for 1.53, and the the docs for Odeint don't build in 1.53: xslt-xsltproc.windows ..\..\..\..\bin.v2\libs\numeric\odeint\doc\msvc-10.0\debug \auto-index-internal-on\auto-index-verbose-on\auto-index-on\threading-multi\refe rence-xml.doxygen file:///D:/data/boost/branches/1.53.0/bin.v2/libs/numeric/odeint/doc/msvc-10.0/d ebug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/ reference-xml/index.xml:1327: parser error : Opening and ending tag mismatch: co mpound line 334 and doxygenindex </doxygenindex> ^ file:///D:/data/boost/branches/1.53.0/bin.v2/libs/numeric/odeint/doc/msvc-10.0/debug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/reference-xml/index.xml:1328: parser error : Premature end of data in tag compound line 333 ^ file:///D:/data/boost/branches/1.53.0/bin.v2/libs/numeric/odeint/doc/msvc-10.0/debug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/reference-xml/index.xml:1328: parser error : Premature end of data in tag compound line 266 Any ideas? Thanks, John.

3 2

[1.53] PDF doc build
by John Maddock 12 Feb '13

12 Feb '13

There's a preliminary build of the PDF docs for 1.53 here: https://sourceforge.net/projects/boost/files/boost-docs/1.53.0/ Currently missing Odeint, but should otherwise be complete and OK. Regards, John.

1 0

[interprocess] Platform-specific flags for mapped_region
by Andrey Semashev 12 Feb '13

12 Feb '13

Hi, I wanted to try using Linux huge pages in my application, which uses Boost.Interprocess currently for interprocess communication. However there seems to be no way to pass MAP_HUGETLB flag to mmap in the interface of mapped_region. I understand that this is a platform-specific option, so probably it would be best to just add an opaque unsigned int flags parameter to the mapped_region constructor with the default value of 0. Or is there a better way of doing this? I'll create a ticket for this feature, but I wanted to know if the general idea of this extension is welcome.

2 3

[Boost.Range] An issue with the documentation of 'remove_erase_if' algorithm
by Adam Romanek 12 Feb '13

12 Feb '13

Hi, I think there's an issue with the documentation of 'remove_erase_if' algorithm from Boost.Range library. It says: "remove_erase_if removes the elements x that satisfy pred(x) from the container. This is in contrast to the erase algorithm which merely rearranges elements." I believe it's not in contrast to the "erase" algorithm but rather the "remove" algorithm. WBR, Adam Romanek

5 8

Future of Boost Windows Installers
by Dave Abrahams 11 Feb '13

11 Feb '13

Hi, As many of you already know, I'm going to work at Apple in late February, and BoostPro is closing its doors. For many years, the Boost Getting Started Guide has suggested that Windows users pop over to BoostPro's website and use the latest installer to get Windows binaries. We'd like to donate to the community the technology used to build those installers. If anyone would like to pick up the job of creating them, we'd be happy to offer guidance. Right now I'm on a plane where an uplink to GitHub is creeping along at 4KB/s, so I've been pushing the stuff up in bits and pieces and the latest stuff isn't up there, but it's going to http://github.com/boostpro/installer and will be complete within 24 hours. Whatever happens with this installer code, someone is going to need to update the Getting Started Guide, either to point at the installer's new home, or to remove references to it. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

3 7

Release branch now open for merging
by Marshall Clow 11 Feb '13

11 Feb '13

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

2 1

[iostreams] mapped_file_source fails for zero sized file
by Michael Marcin 11 Feb '13

11 Feb '13

While testing out iostreams memory mapped file source I ran into an issue where it throws when opening a zero sized file (testing on windows 7 vc11 x64). for example something like: namespace io = boost::iostreams; namespace fs = boost::filesystem; fs::path path("C:\\boost\\boost_1_53_0\\libs\\context\\src\\dummy.cpp"); io::stream<io::mapped_file_source> file( path ); Will throw: failed create mapping: The volume for a file has been externally altered so that the opened file is no longer valid. From: http://tinyurl.com/cx2b9ru "When you do not want the size of the file to change (for example, when mapping read-only files), call CreateFileMapping and specify zero for both dwMaximumSizeHigh and dwMaximumSizeLow. Doing this creates a file mapping object that is exactly the same size as the file. Otherwise, you must calculate or estimate the size of the finished file because file mapping objects are static in size; once created, their size cannot be increased or decreased. An attempt to map a file with a length of zero in this manner fails with an error code of ERROR_FILE_INVALID. Programs should test for files with a length of zero and reject such files." I don't see anything in the docs that would lead me to believe this should throw. Rather I would expect: std::istream_iterator<char>(file) == std::istream_iterator<char>()

1 0

Picking overload with the most specific concept
by Louis Dionne 11 Feb '13

11 Feb '13

Hi, I was playing around today and I achieved to do something I find quite cool. I would like to know whether the technique/general principle is of any interest. Basically, it allows to overload functions based on the modeling of a concept by a type without having to write complicated enable_ifs. It does come with some problems and it is not very general for the moment, but it's a first shot. Here we go: #include <duck.hpp> // the library where I implemented that #include <forward_list> #include <utility> #include <vector> // Generates some boilerplate required to enable concept overloading for // a function named `my_distance`. Ignore this for now. DUCK_ENABLE_CONCEPT_OVERLOADING( my_distance, my_distance(std::declval<Iterator>(), std::declval<Iterator>(), State()), typename Iterator ) struct random_access_version_picked { }; struct forward_version_picked { }; // The State template parameter will be used to carry information during // the resolution. tag::my_distance was defined by the above macro. template <typename Iterator, typename State = tag::my_distance> // This can be seen like an enable_if with some more functionality. typename duck::requires< // This overload is picked iff Iterator models RandomAccessIterator // and no other overload for a more specific concept exist. // Concepts are MPL metafunction classes, so there's no magic here. duck::model_of<duck::RandomAccessIterator, Iterator> // Could add more duck::model_of clauses here , duck::overload_resolution_state<State> // required for the mechanics , duck::template_parameters<Iterator> // ditto , random_access_version_picked>::type // return type my_distance(Iterator, Iterator, State = State()) { return random_access_version_picked(); } // Same thing for the ForwardIterator implementation. template <typename Iterator, typename State = tag::my_distance> typename duck::requires< duck::model_of<duck::ForwardIterator, Iterator> , duck::overload_resolution_state<State> , duck::template_parameters<Iterator> , forward_version_picked>::type my_distance(Iterator, Iterator, State = State()) { return forward_version_picked(); } int main() { std::forward_list<int> list; std::vector<int> vec; forward_version_picked forward = my_distance(begin(list), end(list)); random_access_version_picked random = my_distance(begin(vec),end(vec)); } This example works with Clang 3.3 and GCC 4.8. For those interested in seeing more, the full library is available at: http://github.com/ldionne/duck Look for the `next` branch. The file involved with the above mechanics is include/duck/requires.hpp. Also see the test in test/requires.cpp. Regards, Louis Dionne

1 0

[Git] Status update
by Dave Abrahams 10 Feb '13

10 Feb '13

Please see https://github.com/ryppl/boost-svn2git/wiki if you're interested in the status of modularized history conversion. -- Dave Abrahams

4 3

[smart_ptr] !defined(BOOST_NO_CXX11_SMART_PTR) does not imply !defined(BOOST_NO_CXX11_RVALUE_REFERENCES)
by Michel Morin 10 Feb '13

10 Feb '13

`!defined(BOOST_NO_CXX11_SMART_PTR)` does not necessarily mean that the compiler support of rvalue references is available. For example, when I use shared_ptr (on trunk) with clang + libc++ in a C++03 mode, I get warnings something like boost/smart_ptr/shared_ptr.hpp:556:51: warning: rvalue references are a C++11 extension [-Wc++11-extensions] shared_ptr & operator=( std::unique_ptr<Y, D> && r ) Regards, Michel

3 4

[preprocessor] enabling variadics support
by Gennadiy Rozental 09 Feb '13

09 Feb '13

Hi, It appears PP variadics support is disabled on wide range of compilers where it is in fact working (at least It seems to be). This includes Clang and PGI. Can we enable it now? Gennadiy

3 2

[variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)
by Antony Polukhin 08 Feb '13

08 Feb '13

Current implementation of recursive_wrapper move constructor is not optimal: recursive_wrapper<T>::recursive_wrapper(recursive_wrapper&& operand) : p_(new T(std::move(operand.get()) )) { } During descussion were made following proposals: I: Leave it as is - bad performance - can not provide noexcept guarantee II: Set operand.p_ to NULL, add BOOST_ASSERT in get operations + good performance + provides noexcept guarantee for move constructor + optimization will be used even if varinat has no type with trivial default constructor + easy to implement - triggers an assert when user tries to reuse moved object - adds an empty state to the recursive_wrapper III: Make recursive_wrapper and variant cooperate, enable move for varinat in the presence of recursive_wrappers only when there is at least one type that is nothrow-default-constructible, regardless of whether it's current. It is easyer to understand by example: typedef variant<int, recursive_wrapper<foo>> V; V v1( std::move(v2) ); This move-constructs v1 from v2 and leaves int() into v2. + good performance + provides noexcept guarantee for rcursive_wrapper + does not adds an empty state - optimization won't trigger if varinat has no type with trivial default constructor - hard to implement - user may be obscured by the fact, that v2 from the example now contains int IV: After move away, delay construction of type held by recursive_wrapper till it will be be required. +/- good performance? but more checks + provides noexcept guarantee for rcursive_wrapper + does not adds an explicit empty state + optimization will be used even if varinat has no type with trivial default constructor +/- not hard to implement --- additional requirement for type T of recursive_wrapper: it must be default constructible - less obvious behavior for user (for example get() function would construct values, allocate memory and can possibly throw) Please, vote for solution or propose a better one. P.S.: As I know Joel de Guzman votes for solution II (and totally agains solution I, because it is too slow). I wanted to leave as is (solution I) or use solution IV, but Joel talked me to solution II. P.P.S.: More info can be obtained from ticket #7718 https://svn.boost.org/trac/boost/ticket/7718 and previous series of letters. -- Best regards, Antony Polukhin

23 126

[asio] socks and http connect proxy support
by ecyrbe 08 Feb '13

08 Feb '13

Hi, I made a boost asio client stream to handle tcp proxy support (both socks v4/v5 and http connect). I think boost asio lack this type of support, so i'm asking if there is any interest to integrate such a feature in boost.Asio? I'm mainly asking this question to boost.Asio maintainers. if you want i can come with a patch for a proxyfied_stream<Stream> template class. Regards, ecyrbe.

1 0

[Git] Tracking conversion milestones and issues
by Beman Dawes 08 Feb '13

08 Feb '13

To track the Git and modular Boost conversion milestones and issues, see github.com/ryppl/boost-svn2git/issues/milestones github.com/ryppl/boost-svn2git/issues --Beman

1 0

[log] v2 Initialisation, default sink behaviour and filtering documentation
by Mats Taraldsvik 08 Feb '13

08 Feb '13

Hi, I'm in the process of adopting a logging library, so the timing of the Boost.Log v2 "status report" - for me - could not have been better. :) This library is awesome, thank you for making it! -- I am in the process of moving beyond the default sink now, and had some issues. I tried to add the sinks after my logger object had been default initialized, and this caused some problems (partial streams/corruption, mostly). Currently I'm calling core->remove_all_sinks() to remove the default sink. Are there any "best practices" here? Perhaps it would be a good idea to add these "requirements" to the documentation, if they are not there already and I missed them? :) -- I also noticed that the severity filter examples are : logging::core::get()->set_filter ( logging::trivial::severity >= logging::trivial::info ); >From "Setting up sinks", and sink->set_filter(expr::attr< int >("Severity") >= 2); (i.e. comparing the Severity with an int) when moving to the more advanced section in "Sink frontends". Could you adjust one of the examples in "Sink frontends" to use the severity_level type (that the documentation introduces in the tutorial "Adding more information to log: Attributes") directly? For example: sink->set_filter(expr::attr< severity_level >("Severity") >= warning); Or explaining this in "Log record formatting". I had trouble understanding this at first, but I might be the only one :). Thought I'd mention it anyway. -- Regards, Mats Taraldsvik Norkart AS norkart.no

2 5

[bind] Request: use result_of instead of result_type for functors
by Jason 07 Feb '13

07 Feb '13

One of the drawbacks of using functors with Boost.Bind is that the result type of the functor must be specified either as a typedef inside the functor's definition or as a template argument when building the binding. As the documentation states it: "In the general case, the return type of the generated function object's operator() has to be specified explicitly (without a typeof operator the return type cannot be inferred)" It seems that result_of() would be a good implementation of the "typeof" operator referenced in the above, instead of relying upon a single result_type typedef inside the functor struct/class. This would allow the use of functors whose result type depends upon the arguments passed to the functor. It looks like there was a proof-of-concept patch submitted for this a couple years ago: https://svn.boost.org/trac/boost/ticket/4542 It doesn't appear to have received any attention, however. Is this something that might happen? -- View this message in context: http://boost.2283326.n4.nabble.com/bind-Request-use-result-of-instead-of-re… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 11

[log] missing file in trunk?
by Michael Caisse 07 Feb '13

07 Feb '13

boost/log/filters.hpp seems to be missing from https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log revision 827. Ideas? michael -- Michael Caisse ciere consulting ciere.com

2 3

[bbv2] pdf doc missing?
by Michael Marcin 07 Feb '13

07 Feb '13

http://www.boost.org/doc/libs/1_53_0/tools/build/v2/index.html links to http://www.boost.org/doc/libs/1_53_0/tools/build/v2/doc/userman.pdf Which appears to be broken 404 Not Found File "/home/grafik/www.boost.org/archives/live/boost_1_53_0/tools/build/v2/doc/userman.pdf" not found. In fact the last working one seems to be http://www.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf

1 0

[Function] : Memory allocation upon bind()
by Harry van Haaren 06 Feb '13

06 Feb '13

Hi All, Summary: Boost::bind() allocates memory on the heap. In my situaion it is necessary to use manual memory pool instead of heap allocation, to conform with real-time timing requirements. (no malloc() calls allowed in real-time code) A solution might be writing a custom allocator for the boost::bind()'s data, and use a pre-allocated memory pool with the "placement" new( void* ) to write directly into it. I've found that there was a discussion on std::allocator support for std::bind and std::function here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2308.html I'm not very familiar with the internals of bind() and Function in general, hence advice is appreciated. What is the status of boost::bind() and custom allocators? Is there a chance this could work? Am I missing some "easy" workaround or solution? Thanks for reading, -Harry

2 2

[log][phoenix] Bound arguments not protoified?
by Andrey Semashev 06 Feb '13

06 Feb '13

Hi, I have a problem with Boost.Phoenix v3 bind implementation when used with attribute keywords from Boost.Log. For some reason phoenix::bind does not apply proto::detail::protoify to the bound arguments which breaks compilation of some formatting expressions in Boost.Log. Here's an example: namespace logging = boost::log; namespace expr = boost::log::expressions; namespace phoenix = boost::phoenix; // Custom severity level formatting function std::string severity_level_as_urgency( logging::value_ref< logging::trivial::severity_level, logging::trivial::tag::severity > const& level); // The function initializes the logging library void init_logging() { // ... sink->set_formatter ( expr::stream << phoenix::bind(&severity_level_as_urgency, logging::trivial::severity) ); } The intended behavior of this code is to invoke severity_level_as_urgency function with severity level value extracted from a log record and put the result of this function into a stream, thus forming a formatted representation of the record. trivial::severity is a keyword of type expr::attribute_keyword< ... >. Keywords themselves should never actually be embedded into phoenix expressions, instead I have attribute_actor that implements all the necessary work to extract attribute values. I have specialized proto::detail::protoify template for attribute_keyword (including references and reference_wrappers thereof) so that it is automatically converted to attribute_actor whenever it participates in expressions. But it doesn't work with the above code, Boost.Phoenix embeds attribute_keyword as is into the expression. This results in the error I posted in the end of the post. I realize that proto::detail::protoify is not for public use and may not be intended for my use case but I did not find any other way to implement what I described. Anyway, I think bind should treat bound arguments as child subexpressions and protoify them. Is that right? In case if you want to see the complete code of the example and/or Boost.Log, you can check it out from SVN: svn co https://boost-log.svn.sourceforge.net/svnroot/boost- log/branches/bleeding-edge boost-log The example resides in libs/log/example/doc/extension_app_launcher.cpp. I have modified it to call or_none() on trivial::severity so that the example compiles; in order to reproduce the problem you have to remove this call (it sould be performed by my protoify specialization instead). Compilation error: In file included from ./boost/phoenix/core/preprocessed/expression.hpp:12:0, from ./boost/phoenix/core/expression.hpp:21, from ./boost/phoenix/core/argument.hpp:14, from ./boost/phoenix/core.hpp:17, from ./boost/phoenix/phoenix.hpp:11, from ./boost/phoenix.hpp:11, from libs/log/example/doc/extension_app_launcher.cpp:13: ./boost/phoenix/core/preprocessed/expression_10.hpp: In instantiation of ‘static boost::phoenix::expr_ext<Actor, Tag, A0, A1>::type boost::phoenix::expr_ext<Actor, Tag, A0, A1>::make(typename boost::call_traits<A0>::param_type, typename boost::call_traits<A1>::param_type) [with Actor = boost::phoenix::actor; Tag = boost::phoenix::detail::tag::function_eval; A0 = boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>; A1 = boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity>; boost::phoenix::expr_ext<Actor, Tag, A0, A1>::type = boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l> >; typename boost::call_traits<A0>::param_type = const boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>&; typename boost::call_traits<A1>::param_type = const boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity>&]’: ./boost/phoenix/bind/bind_function.hpp:45:83: required from ‘const typename boost::phoenix::detail::expression::function_eval<boost::phoenix::detail::function_ptr<1, RT, RT (*)(T0)>, A0>::type boost::phoenix::bind(RT (*)(T0), const A0&) [with RT = std::basic_string<char>; T0 = const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&; A0 = boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity>; typename boost::phoenix::detail::expression::function_eval<boost::phoenix::detail::function_ptr<1, RT, RT (*)(T0)>, A0>::type = boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l> >]’ libs/log/example/doc/extension_app_launcher.cpp:92:91: required from here ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: warning: missing braces around initializer for ‘boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l> >::expr_type {aka boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l>}’ [-Wmissing-braces] ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: warning: missing braces around initializer for ‘boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor> >, 2l>::proto_child0 {aka boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>}’ [-Wmissing- braces] ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: error: could not convert ‘boost::proto::make_expr<boost::phoenix::detail::tag::function_eval, boost::proto::domainns_::basic_default_domain, boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>, boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity> >((* & a0), (* & a1))’ from ‘const type {aka const boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>, boost::log::v2s_mt_posix::expressions::attribute_keyword<boost::log::v2s_mt_posix::trivial::tag::severity> >, 2l>}’ to ‘boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)> >, 0l>::proto_child0 {aka boost::phoenix::detail::function_ptr<1, std::basic_string<char>, std::basic_string<char> (*)(const boost::log::v2s_mt_posix::value_ref<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::trivial::tag::severity>&)>}’ ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: error: no matching function for call to ‘boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor>::attribute_actor(<brace-enclosed initializer list>)’ ./boost/phoenix/core/preprocessed/expression_10.hpp:98:17: note: candidates are: In file included from ./boost/log/expressions.hpp:20:0, from libs/log/example/doc/extension_app_launcher.cpp:16: ./boost/log/expressions/attr.hpp:174:14: note: boost::log::v2s_mt_posix::expressions::attribute_actor<T, FallbackPolicyT, TagT, ActorT>::attribute_actor(const base_type&) [with T = boost::log::v2s_mt_posix::trivial::severity_level; FallbackPolicyT = boost::log::v2s_mt_posix::fallback_to_none; TagT = boost::log::v2s_mt_posix::trivial::tag::severity; ActorT = boost::phoenix::actor; boost::log::v2s_mt_posix::expressions::attribute_actor<T, FallbackPolicyT, TagT, ActorT>::base_type = boost::phoenix::actor<boost::log::v2s_mt_posix::expressions::attribute_terminal<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity> >] ./boost/log/expressions/attr.hpp:174:14: note: candidate expects 1 argument, 0 provided ./boost/log/expressions/attr.hpp:156:7: note: boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor>::attribute_actor(const boost::log::v2s_mt_posix::expressions::attribute_actor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity, boost::phoenix::actor>&) ./boost/log/expressions/attr.hpp:156:7: note: candidate expects 1 argument, 0 provided

2 3

-commits list broken?
by Marshall Clow 06 Feb '13

06 Feb '13

I just noticed that I haven't received any mail from boost-commits since 1/29. The archives on the web site stop at 1/14. Any ideas for giving the server a thwack? -- 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

[range] missing includes in any_range.hpp
by svarneticist 05 Feb '13

05 Feb '13

Hello, I get errors when I try to use boost/range/any_range.hpp It appears that boost/range/detail/any_iterator.hpp needs #include <boost/utility/enable_if.hpp> and boost/range/detail/any_iterator_wrapper.hpp needs #include <boost/range/concepts.hpp> Thank you -- View this message in context: http://boost.2283326.n4.nabble.com/range-missing-includes-in-any-range-hpp-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 05 Feb '13

05 Feb '13

Okay, I believe I need to provide a really good example that can show the need of static construction with no preliminary calls to initialization functions. The example if part of my work project: - I have two layers: presentation and model. - Each layer work in its own thread because presentation must remain responsive whatever happens in model. - Model itself is an abstract layer, the actual logic implementation is implemented in specific agents, so the model is not aware of the agents. - Agents are asynchronous tasks. - I have DatabaseFacade utility class, internal data of which require some preliminary initialization, like setting initial values, creating locks, filling hash maps, but not actual connection because it's a proxy to real database object. - All agents use the DatabaseFacade asynchronously. These are the possible scenarios of initialization of DatabaseFacade internal data: 1. Make a call to DatabaseFacade::initialize() from main (or other wiring code), thus making main aware about DatabaseFacade, i.e. introduce an unnecessary dependency. 2. Call DatabaseFacade::initialize() from model construction, again introducing an unnecessary dependency, because the abstract model doesn't care about some specific needs of some agents. 3. Call DatabaseFacade::initialize() during specific agent construction. But another agent can be inside a call to DatabaseFacade::initialize(). So, I'd need to wrap it in critical section. But the critical section itself has to be initialized before agents start. Should I introduce dependency on this specific critical section to the abstract model? Nop. Should I wrap DatabaseFacade::initialize() inside in a static critical section thus making assumptions about clients of the function? Nop again. And by introducing public method DatabaseFacade::initialize() I will open a possibility for double initialization. Of course I can insert checks, but the checks can reveal problems at run-time only. So it's more correct to allow a class to initialize its internal data itself on its own discretion, thus writing robust API that cannot be misused: "Anything that can go wrong will go wrong" - Murphy's Law ;) Thank you. ______________________________ With best regards, Alexander Stoyan

1 0

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 05 Feb '13

05 Feb '13

Hello everybody, Sorry for late response. To Mateusz. Thank you for a good point, I have updated my initial blogpost with with clear statement of the goal. And I also corrected naming and put some extra comments. To Mathias. >> What's the functional difference between putting it as a type list and >> putting it as code? Not sure that I understood your question correctly, but if you meant differences between dependencies in the static_dependencies list and dependencies caused by calling initialization from main, then the difference is clear: if we put dependencies B and C to static_dependencies list when declaring class A, then only class A declaration becomes dependent on B and C. But if we require a call to A::initialize, B::initialize and C::initialize from main, then main becomes dependent on A, B and C. This way your startup code will be dependent on everything like that, that's not right. >> If you want it to be initialized before main, then use global variables or static members. Ok, try to answer your question yourself: struct A { static A& instance() { ... } } struct B { static A& instance() { ... } } struct C { static A& instance() { ... } } ... static A& forceAConstr = A::instance(); static B& forceBConstr = A::instance(); static C& forceCConstr = A::instance(); ... int main() { ... } Can you guarantee the order of construction for A, B and C in this case when standard explicitly states that the order of initialization is not determined? >> But then you have to make sure no threads exist prior to entering main. >> Unlike for static variables in functions, global constructors are not thread-safe. Starting threads before main execution is a bad idea itself, so don't do it. >> I have no idea what you're talking about. The compiler cannot remove >> things if it changes observable behaviour, outside of a few situations >> where copy constructors can be elided. In my code you can find a declaration and initialization of bool static_constructible<T, Dependencies>::constructed. So, if this variable is not referenced in the code it never get initialized. At least this is how VS11 compiler works. So in order to refer this variable all data access functions have to make a call to static_constructible<T, Dependencies>::ensure_static_constructed. This way if you call a data access function from main, which calls ensure_static_constructed, then static_constructible::constructed becomes referenced! >> There is an "isinside" boolean. That's only made for cases if a derived class from singleton does not provide his own static constructor. If you remove B::static_construct() the code will work fine anyway. >> A given order can still be forced. Unless it's through compile configuration, provide an example please. Otherwise, having long lists of initialization orders for all supported compilers is error prone. The code itself has to describe itself as much as possible. I appreciate your attention. Thank you. ______________________________ With best regards, Alexander Stoyan

2 1

[gil] compiler error with clang in c++11 mode
by Christian Henning 05 Feb '13

05 Feb '13

Hi there, Can someone shed some light on the following compiler errors: c:\boost\boost\gil/channel_algorithm.hpp:54:85: error: non-type template argument evaluates to -1, which cannot be narrowed to type 'unsigned long long' [-Wc++11-narrowing] struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,-1> {}; ^ c:\boost\boost\gil/channel_algorithm.hpp:204:19: note: in instantiation of template class 'boost::gil::detail::unsigned_integral_max_value<unsigned long long>' requested here if (src > unsigned_integral_max_value<uintmax_t>::value - div2) I only get those in c++11 mode. The code to trigger them is: #include <boost\gil\gil_all.hpp> int main() { return 0; } I'm using clang 3.2 on Windows with CodeBlocks. Thanks, Christian

2 3

[type_traits] Request: is_iterable
by Nevin Liber 05 Feb '13

05 Feb '13

I'd like to make a request for an is_iterable<T> type trait, which detects if a type can be used in C++11 range-based for. I have a prototype which currently meets my needs (I can make it available; it detects if both std::begin(c) and std::end(c) can be called), but I'm wondering: a) What should the name be? (I'm not married to is_iterable) b) Should there be a second template parameter indicating the type returned by derefencing the iterator, defaulting to don't care. c) What should the C++03 behavior be? d) Is there someone with more expertise than I willing to implement a robust version of it? Does this sound like a good idea? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

4 4

Boost 1.53.0 released!
by Marshall Clow 04 Feb '13

04 Feb '13

Release 1.53.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 five new libraries and numerous enhancements and bug fixes for existing libraries. New Libraries: * Atomic: C++11-style atomic<>, from Helge Bahmann, maintained by Tim Blechmann. * Coroutine: Coroutine library, from Oliver Kowalke. * Lockfree: Lockfree data structures, from Tim Blechmann. * Multiprecision: Extended precision arithmetic types for floating point, integer and rational arithmetic from John Maddock and Christopher Kormanyos. * Odeint: Solving ordinary differential equations, from Karsten Ahnert and Mario Mulansky. For details, including download links, see http://www.boost.org/users/news/version_1.53.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.53.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 Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

6 7

[1.53] Too late for doc fixes?
by John Maddock 04 Feb '13

04 Feb '13

Am I correct in assuming that it's too late to fix typos in docs: https://svn.boost.org/trac/boost/ticket/7958 ? Thanks, John.

3 3

[function] Documentation suggestion (FAQ)
by Evan Driscoll 04 Feb '13

04 Feb '13

I just wrote up a longish email (excerpted below) that was basically asking for advice about how to work around the fact that I can't compare two function objects. However, I fortunately decided to take another look at the docs before sending, and realized that Boost actually supports what I *really* needed, which was to compare a function object to see if it points to a particular function so I could use a much faster implementation. In other words, I was doing void backing_func() {...} boost::function<void()> func(backing_func); void foo(function<void()> callback) { if (callback == func) { fast_foo(); } else { slow_foo(callback); } } but by changing the if statement condition to if (callback == &backing_func) everything is fine and dandy. My suggestion is that the FAQ entry at http://www.boost.org/doc/libs/1_52_0/doc/html/function/faq.html should be updated to point out that there IS a way to do this specific case. If everyone read the whole docs and remembered them perfectly this wouldn't be a problem, but of course those statements are probably true of exactly no one. :-) I stumbled across the FAQ entry, which I feel strongly suggests that what I want to do is impossible. Evan P.S. If you have suggestions for a better design, I'm open to suggestions. --------- I'd like input about how to handle a design. I'll describe what I'm doing; my question is what people would suggest. I have a class which stores a boost::function<> as a parameter so as to provide a hook to customize its behavior. I can give the actual code and description of what I'm doing if that will help, but I suspect it distract more than help, so I'll just make something up (untested): typedef boost::function<bool (int, int)> CallbackType; class MyClass { CallbackType callback; void foo() { ... if (callback(x, y)) { .... } } MyClass(CallbackType cb) : callback(cb) {} }; There are a couple generically useful behaviors, so the library predefines callbacks for those: bool behavior_a(int, int) {...} bool behavior_b(int, int) {...} bool behavior_c(int, int) {...} CallbackType behavior_a_callback(behavior_a), behavior_b_callback(behavior_b), behavior_c_callback(behavior_c); I have need to make 'foo' fairly general and support fairly general callbacks, but for one behavior (say behavior_a), I can use a substantially more efficient algorithm (log or constant time, instead of linear) inside foo(). What I WANTED to do was make the behavior_a(int,int) function just a dummy, then do void foo() { if (callback == behavior_a_callback) { fast_foo(); } else { slow_foo(); } } However, for reasons described at http://www.boost.org/doc/libs/1_52_0/doc/html/function/faq.html#id1617166, you can't compare functions with equality. Any thoughts as to how you'd do this? Evan

2 1

[Fusion] Some ideas
by TONGARI 03 Feb '13

03 Feb '13

Hi, Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::transform(a, b, some_void_return_ftor)) * Conversion function 'as_view' to make Container a view to reserve the mutability. What do you think? Are these already achieved in some way that I didn't aware of? BTW, I just implemented left_mapping/left_mapped_view, it's used like result = left_mapping(m1, m2, transform); For elements not mapped, fusion::void_ is passed to transform. Still mapping & full_mapping to do...

3 14

Re: [boost] (no subject)
by Gilbert Polo 03 Feb '13

03 Feb '13

Is boost version 1.48 portable to AIX version 6.1. xlC version 11.1

2 1

[thread] possible raise in future?
by Oliver Kowalke 03 Feb '13

03 Feb '13

Hello Vicente, after analyzing the code of future<> from boost.thread I think the code might contain raise condition. future.hpp:226: future_object_base defined 'bool done'. future_object_base::mark_finished_internal() sets 'done' tot true (line 308) and future_object_base::wait_internal() reads it (line 347). Shouldn't 'done' be of type atomic<bool >? I believe that the compiler can reorder the usage of 'done' and two threads (writer thread calling make_finished_internal() and reader calling wait_internal()) might see different values. At least I think it might be possible that some thread will always be waiting in waiters.wait() (line 349), because the write r thread sets done=true and call waiters.notify_all() and a reader thread calls later wait_internal() but does not see that done is true because of memory reordering etc. and will be blocked in waiters.wait()forever. What do you think? best regards, Oliver

2 3

Re: [boost] [thread] possible raise in future
by Oliver Kowalke 03 Feb '13

03 Feb '13

hmm - both functions are called by other member-fn of future_object_base, locking the same mutex before. But might reordering (of var done' inlined code) still be possible? I'm asking because l've some experimental code using future<> which sometimes blocks (I assume inside future<>::wait()).

1 0

Writing documentation
by Borislav Stanimirov 03 Feb '13

03 Feb '13

Hello, I'm developing a project for boost (discussion can be found here: http://lists.boost.org/Archives/boost/2013/01/200598.php) I was wondering how one writes documentation. I did find some templates here, but they seem outdated (ot at least different), compared to the documentation files that already exist for the libraries. So, are there any new templates? Is there a html generation tool I should use? -- Borislav

5 10

[auto_index] segfault during boostbook xml processing
by Alexey Kutumov 03 Feb '13

03 Feb '13

Hi! Recently i started to port boost documentation building to CMake ( https://github.com/boost-cmake/) with ryppl-dev community, and i have some issues with auto_index. According to documentation ( http://www.boost.org/doc/libs/1_52_0/tools/auto_index/doc/html/boost_autoin…) this tool supports boostbook XML, however when i started to process XML with auto_index it crashes. I created ticket (https://svn.boost.org/trac/boost/ticket/7967) and added example for reproducing ( https://svn.boost.org/trac/boost/attachment/ticket/7967/autoindex_issue.zip ). Also i have a question: is it legal to use auto_index with boostbook XML, because i have same issue for some others projects?

2 1

new proposal: order statistics tree
by Szymon Wojciechowski 03 Feb '13

03 Feb '13

Hi, I would like to propose to add new data structure - order statistics tree. Briefly, it is container which allows logarithmic inserting, searching and erasing as in set, but additionally it permits to access elements via numerical value - key order. I have some ready implementation with all appropriate functions (without their all overloaded forms) with gtest regression list, but the code isn't boostified. The regression passes on gcc 4.6.3 and vs2010. Is there anybody interested in? Best regards, Szymon Wojciechowski

7 21

Ok to commit to trunk?
by Christian Henning 03 Feb '13

03 Feb '13

Hi there, I'm planning to commit some changes and add the toolbox to gil on the trunk ( not the release branch! ). Is it OK to commit? Thanks! Christian

3 4

[fixed_point] Request for interest in a binary fixed point library
by Vicente J. Botet Escriba 02 Feb '13

02 Feb '13

Hi, the recent discussion on the MultiplePrecission Arithmetic library has show that some people has its ow fixed point library. Is there an interest in a Boost library having as base http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html? I have started a prototype http://svn.boost.org/svn/boost/sandbox/fixed_point (there is no doc yet but the basic goal is quite close to the N3352 C++ proposal). This prototype should allow you to play a little bit with. If yes, what would you like to be changed, added or improved in n3352? Next follows some design decisions that IMO need to be decided before hand. * Should integers and reals be represented by separated classes? * Should signed and unsigned be represented by separated classes? * Should the library use a specific representation for signed numbers (separated sign, 2-complement? Let the user choose? * Should the library provide arbitrary range and resolution and allocators? * Should the library be open to overflow and rounding or just implement some of the possible policies? and in this case which ones? * Should fixed_point be convertible to/from integer/float/double? * Could the result of an arithmetic operation have more range and resolution than his arguments? * Is there a need for a specific I/O? * is there a need for radix other than 2 (binary)? * Should the library implement the basic functions, or should it imperatively implement the C++11 math functions? Could a first version just forward to the c++11 math functions? * Should the library support just one of the know ways to name a fixed-point, a U(a,b), nQm, ...? Provide some ways to move from one to another? * Could expect the same/better performances respect to hand written code? * What should be the size used by a fixed_point instance? _fast? _least? Should the user be able to decide which approach is better for his needs? * Which should be the namespace? boost? boost/fixed_point? boost/binary_fixed_point? boost/bfp? ... * others you can think of. Please, replay if you are interested, have some experience in the domain, good ideas, .. Best regards, Vicente

6 44

[1.53.0] Release candidates available
by Marshall Clow 02 Feb '13

02 Feb '13

Release candidate files for 1.53.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: 57a9e2047c0f511c4dfcf00eb5eb2fbb *boost_1_53_0_rc1.tar.gz a00d22605d5dbcfb4c9936a9b35bc4c2 *boost_1_53_0_rc1.tar.bz2 c618e030fd4882e4dbacf54baf824544 *boost_1_53_0_rc1.zip cc680cab53a5405ca102a10d43b92b88 *boost_1_53_0_rc1.7z Thanks! -- The release managers

9 10

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 01 Feb '13

01 Feb '13

Hello Mathias, I'm afraid you didn't get the point. Let me explain. >> The object will only be constructed when instance() is called Technically, yes, the instance will be create once singleton::instance is called for the first time, but in order to make it constructed BEFORE main, singleton::instance has to be called during static data initialization, and static_init GUARANTIES that this static initialization will be performed before main WITH NO additional calls. >> If the constructor of the object depends on >> other singletons, then instance() of those other singletons >> will naturally be called before, and therefore they >> will end up being constructed before. You're right, if you refer to singleton A's before creating singleton B's instance, to order of initialization would be correct. But let's no limit this case to singletons only, where initialization is achieved in just one call. There can many many different situation when you have to perform some additional data initialization and manipulation before creating singleton instance. Where would you put this code? Would you make singleton constructor or instance access method dependent on all this data when it naturally should not be? Anyway it doesn't solve the problem for the first call to a singleton if it has to be initialized before main. Unless you create a global static variable and make the first call to singleton during this variable initialization, but then you still need to refer to this variable from the code somewhere in order to make sure your compiler does not eliminate it due to optimization reasons, and this way you will introduce unnecessary dependency. 3. There is no construction recursion. If you did notice it somewhere, please point to exact place. 4. Static data construction order is undefined by C++ standard fixing it requires either changing the standard or getting rid of class and global static data. So, again, to make the idea crystal clear, the initial goal was: 1. Guarantee that static constructor method is called before main is executed 2. No additional calls in either global or any local scope should precede static constructor invocation in order not to introduce extra dependencies and eliminating a situation when initialization invocation code does not get called for any reason. 3. Provide a way to control the order of static constructors calls. No recursions are allowed. The described approach fully satisfies the three simple requirements. If anybody sees possible errors or ways to improve it, feedbacks are very appreciated. Thank you. ______________________________ With best regards, Alexander Stoyan

3 2

Building 1.52.0 with g++ 4.7.2
by Richard Hadsell 01 Feb '13

01 Feb '13

I am having trouble building Boost 1.52.0 libraries with g++ 4.7.2 on Linux Fedora 14. I was able to build it with 4.7.1, and I think our Systems guys configured 4.7.2 the same as 4.7.1, so I need help. This is in my user-config: using gcc : 4.7.2 : /opt/gcc-4.7.2/bin/g++ :<compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp"<linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; This is my command line: bin/bjam --user-config=user-config.LINUX_INTF14X threading=multi instruction-set=core2 address-model=64 variant=release link=static,shared --stagedir=stageF14X And this is the result (snipped out redundant info): Building the Boost C++ Libraries. Performing configuration checks - x86 : no - power : no - arm : no - mips1 : no error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>qcc not matched [snip] next alternative: required properties:<abi>ms<address-model>64<architecture>x86<binary-format>pe<target-os>windows not matched - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - Boost.Locale needs either iconv or ICU library to be built. [snip] - Boost.Locale needs either iconv or ICU library to be built. - gcc visibility : no - long double support : no warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched [snip] -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 2

[container] static_vector: fixed capacity vector update
by Andrew Hundt 01 Feb '13

01 Feb '13

*static_vector is a hybrid of boost::container::vector and boost::array with fixed capacity. Adam Wulkiewicz and I have updated static_vector with improvements from the list discussion and reorganized it for possible inclusion into boost.container. Overview: static_vector is a sequence container with contiguous storage that can change in size like boost::container::vector. It also includes static allocation, low overhead, and fixed capacity similar to boost::array. Synopsis: template* *<* * typename Value, * * std::size_t Capacity, * * typename Strategy = strategy::def<https://svn.boost.org/svn/boost/sandbox/static_vector/doc/html/static_vecto…> <Value> * *>* *class static_vector; Example: // static_vector of ints, fixed capacity: 3 boost::container::static_vector<int,3> three; // size: 0 three.push_back(1); // size: 1 three.push_back(2); // size: 2 three.push_back(3); // size: 3 //three.reserve(4); // no effect, fixed capacity: 3 //three.push_back(3); // size: 4, undefined behavior three.pop_back(); // size: 2 three.shrink_to_fit(); // no effect, fixed capacity: 3 Documentation: https://svn.boost.org/svn/boost/sandbox/static_vector/doc/html/index.html Source: https://svn.boost.org/svn/boost/sandbox/static_vector/ Discussions from boost.devel archive: http://goo.gl/PKEpB [google groups] Changes: - C++11 support - moved to boost::container namespace - strategy based error handling (“strategy” is aka “policy”) - bounds checks are asserts by default but can be switched to exceptions - memory is uninitialized until objects are inserted - internal size is currently the same as Strategy::size_type - expanded documentation and unit tests - optimizations based on type traits - boost::interprocess support ------------------------------------------------ ------------------------------------------------ Major questions from prior list discussions and the related design decisions: ------------------------ Q1: static_vector design *a) combination of fixed capacity vector and adjustable size array b) vector with small size optimization, possibly with configuration of what “small size” means. A1: (a) is implemented by static_vector, leaving the (b) as future work for a separate class. ------------------------ Q2: Is it best to implement push_back() and similar functions with or without bounds check? Main use cases: *a) no bounds check on each insertion because it is an undesirable use of resources b) vector emulation where static_vector is a drop in replacement and optimization so bounds checking is essential to minimize the amount of code that must be changed. A2: (a) no bounds check is the default for static_vector. A vector emulation strategy can be implemented for (b). ------------------------ Q3: Should a failed bounds check trigger an assertion or an exception? Main use cases: a) bounds check is too much overhead, but assert() allows for testing in debug mode b) vector emulation, so bad_alloc should be thrown when the capacity is exceeded c) exceptions are desired when bounds checking, but bad_alloc would cause the wrong behavior because freeing up memory will not allow the possibility of a larger capacity as it would in a vector. A3: (a) failed bounds checks trigger an assertion, and the user can implement the necessary strategy and traits to achieve (b) or (c). ------------------------------------------------ ------------------------------------------------ New/Unanswered Questions: ------------------------ Q4: Should the current static_vector actually be in the detail namespace, with policy specializations providing the actual interface to several classes with different desired functionality? This could be similar to what was suggested by Nate Ridge: On Sat, Oct 15, 2011 at 5:16 PM, Nathan Ridge <zeratul976(a)hotmail.com> wrote: > Now the implementor of these classes can implement them like this: > > typedef boost::detail::static_vector<T, AssertPolicy> capacity_array; > typedef boost::detail::static_vector<T, ThrowPolicy> stack_vector; It also seems to be backed by the fundamental interface differences between the various classes (static_vector, std::vector, AutoBuffer/hybrid_vector) as outlined by Dave Abrahams: On Wed, Oct 19, 2011 at 1:26 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > I see a container that can never store more than N items, for some > reasonably small N, as fundamentally, semantically different from one > that is highly likely to be able to store any M items you have to deal > with, and for which you can't determine a hard limit N ahead of time > (no, max_size() doesn't count—that's typically just > numeric_limits<size_t>::max()). I grant you that we don't have a very > strict way of expressing this difference in a specification, but I think > that's just missing. I wouldn't, except in very special circumstances, > consider one of those containers to be a suitable replacement for the > other, despite the similarity of the specification text. Would you? This would mean that the official interfaces can be specific to various common use cases and a bit simpler. An additional benefit here is that simpler interfaces are more welcoming to a wider range of developers. On the other hand, the current design makes the official interface configurable so they could customize it without being as concerned about changes in the detail implementation. If everyone will want something different for their specific use case, leaving the design as is may make the most sense. Furthermore, a reasonable default provides a simpler interface while permitting advanced configuration for those who need it. ------------------------ Q5: Should the static_vector Strategy concept (a) remain as is (b) add the Capacity as an additional template parameter (c) permit Standard Library Allocators as a strategy Currently, the default traits assume that the Strategy defines types normally defined by Allocator and provides a capacity check failure callback. Also, a different strategy and traits specialization can be used to configure the class as desired, such as modifying the size_type based on the Capacity. Consequently, leaving the Strategy as is (a) remains fairly reasonable. Adding an additional Capacity template parameter (b) to the Strategy concept would take the Strategy further from the Allocator concept, but ensure configuration of size_type based on the capacity is easy and consistent. We believe (c) does not make sense despite allowing static_vector to be more compatible with vector due to the fundamental interface differences discussed in Q4. Option (c) makes more sense for a class like AutoBuffer/hybrid_vector than it does for static_vector. Thus, the question ultimately becomes one concerning the tradeoff between options (a) and (b). ------------------------ Q6: Should static_vector_traits be part of the public interface or remain in the detail namespace? This would make some of the functionality in Q5a part of the official interface, but restrict future changes. In Boost.Container traits are defined in the detail namespace so we were hoping to find out the reasoning for this choice. The direction of the design discussion for Q4 could also make this a moot point. ------------------------ Q7: Does static_vector provide significant benefits over boost::container::vector with a stack Allocator template parameter? This has been discussed previously and we believe the answer is yes for the reasons outlined in Q4 and the documentation, but we wanted to bring it up again in case someone wanted to play devil’s advocate. ------------------------ That covers all the basics of the updated static_vector implementation and some of the biggest outstanding design questions. We appreciate any and all questions, design ideas, or issues you can come up with, so fire away. :-) Regards, Andrew Hundt* Adam Wulkiewicz

7 22

[GitHelp] varray (aka static_vector) to modular boost
by Andrew Hundt 01 Feb '13

01 Feb '13

I'm trying to bring varray over to github with modular boost, but since we just moved it from static_vector to varray the history is split between two directories. I have been able to run git svn on each directory independently and then pull the static_vector one into the varray one on a separate branch. I then want to stack all the versions so that they are continuous, but I am not sure how to do this. my steps so far: git svn clone http://svn.boost.org/svn/boost/sandbox/varray varray git svn clone http://svn.boost.org/svn/boost/sandbox/static_vector varray2 cp -a varray varray3 # backup # git pull command here that brings it into another branch Also, I'd be happy to take suggestions of better ways to accomplish this. I've noticed that all the dates on github.com/boostorgrepository changes are getting old and are up to nearly a month now, have the updates stopped working? Cheers! Andrew Hundt

2 2

[iterator] Constness of counting_iterator
by Claas 01 Feb '13

01 Feb '13

Hi all! I was wondering why the dereference operator of counting_iterator<T> returns a constant reference to T instead of a reference to T. Naively I would expect counting_iterator<T>::reference to be T& and counting_iterator<const T>::reference to be const T&. I suppose however that there was good reason to implement counting_iterator the way it is implemented. Could anyone kindly point this reason out to me? Regards Claas

2 1

Re: [boost] [variant] Please vote for behavior
by Markus Klein 01 Feb '13

01 Feb '13

On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave(a)boostpro.com> wrote: > Yes. IIUC the question here is whether the invariant of variant [;-)] > shall be weakened to accommodate efficient move semantics, thereby > breaking some code, or not, at some cost (the specific costs to be > incurred by various strategies presently under discussion). I'm new to this list, so I won't be offended if you correct me on any rookie mistakes. Concerning the invariant of variant: Why not provide a specialization of boost::optional for variant, which supports move Semantics? Users who don't want their invariant harmed, can use boost::variant as is. Users who need to squeeze out performance could use an optional<variant> and would be explicitly aware of the new null state they introduced for this. Markus www.clean-cpp.org

6 12

[asio] ssl::stream::async_handshake handler not called
by Alex 01 Feb '13

01 Feb '13

Hi guys, If ssl client cannot read data from server (SSL_connect: error in SSLv2/v3 read server hello A), handshake handler is not called. Is this by design? Or, probably, it should be called with error anyway. Thanks in advance. Alex

1 0

Is there any interest in static constructors?
by Alexander Stoyan 01 Feb '13

01 Feb '13

Hello community, I have implemented static constructors for my personal needs. They guarantee construction of static data prior main execution, and allow control the order of static initialization. The code now implemented and tested for VS2012 and GCC. I couldn't find anything like this in the boost library but consider it to be useful for C++ developers. More detailed approach on my blog page: http://alexander-stoyan.blogspot.com/2013/01/static-constructors-in-c.html Feedbacks are very appreciated. Thank you. ______________________________ With best regards, Alexander Stoyan

2 1