- Boost - lists.preview.boost.org

asio::epoll_reactor::complete_operations_and_timers() - thread saftey
by Hite, Christopher 04 Jun '12

04 Jun '12

I thought I'd take a look at the epoll_reactor implementation. I thinking of using asio proactor style code to use kernel bypass libraries. I wanted to see how you do async IO with a pool of threads. I think I see a bug. None of the operations there done outside of the lock seem thread safe. They unsafely modify linked lists. lock.unlock(); read_op_queue_.complete_operations(); write_op_queue_.complete_operations(); except_op_queue_.complete_operations(); Chris

1 0

[python] run python script from bjam
by lcaminiti 03 Jun '12

03 Jun '12

Hello all, I build a Boost.Python module and install it using bjam as follow: python-extension pydef : deduced_params_pydef.cpp : <library>/boost/python//boost_python <library>/boost/regex//boost_regex <link>shared:<define>BOOST_REGEX_DYN_LINK=1 ; install pydef_install : pydef : <install-dependencies>on <install-type>SHARED_LIB <install-type>PYTHON_EXTENSION <location>. ; I the same dir I have a python script deduced_params_pydef.py which will import the module and test it. How do I run the python script automatically from bjam so to fully compile and test the module that my code generates? Something like (this doesn't work of course): # Make sure pydef target is built first, then runs python deduced_params_pydef.py run-py pydef_install : deduced_params_pydef.py ; Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-python-run-python-script-from-bjam… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

boost.unordered undocumented methods
by niXman 03 Jun '12

03 Jun '12

Hello! In the documentation for boost-1.49.0 the following methods are not documented: https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… -- Regards, niXman ___________________________________________________ Dual-target(i686/x86_64) MinGW compilers for i686/x86_64 hosts: http://sourceforge.net/projects/mingwbuilds/

1 0

Is there interest in copyable type_info that does not require RTTI (was: Is there interest in typeid(TYPE).name() like function that does not require RTTI)
by Antony Polukhin 03 Jun '12

03 Jun '12

Hi, There is a detail/sp_typeinfo.hpp which is not documented, and has some drawbacks. This header provides type_info like class that can be used with RTTI disabled. I am proposing to refactor this header, move it to utility/template_info.hpp and document it as a separate utility. Refactored header will provide classes template_info_ptr, template_info<T>, type_info_ptr and free function get_template_info<T>() Advantages: 1) more portable and reliable than detail::sp_typeinfo (no sp_typeid_<T>::ti_ public static variable) 2) copyable type_info like classes 3) has all the type_info functions + name_demangle 4) works with disabled RTTI 5) better functionality: no need to write macros like: #if defined( BOOST_NO_TYPEID ) # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X)==(Y)) #elif (defined(__GNUC__) && __GNUC__ >= 3) \ || defined(_AIX) \ || ( defined(__sgi) && defined(__host_mips)) # include <cstring> # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) \ (std::strcmp((X).name(),(Y).name()) == 0) # else # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X)==(Y)) #endif 6) user can explicitly chose between template_info+template_info_ptr and type_info+type_info_ptr 7) no macro (get_template_info<T>() instead of &BOOST_SP_TYPEINFO(T) ) Disadvantages: 1) Does not work with variables (but you can still use BOOST_TEMPLATE_INFO_PTR(BOOST_TYPEOF(var))) 2) BOOST_CURRENT_FUNCTION produces long strings, and that could lead to code bloat when RTTI disabled Some usage examples: int main () { // Portable way that works with and without RTTI: copyable_type_info t1 = get_template_info<std::string>(); copyable_type_info t2 = get_template_info<int>(); // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << t1.name_demangled() << '\n'; // int std::cerr << t2.name_demangled() << '\n'; // false std::cerr << (t1 == t2) << '\n'; // true std::cerr << (t1 != t2) << '\n'; copyable_type_info t1_copy = t1; // .?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ std::cerr << get_template_info<std::string>().name() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << get_template_info<std::string>().name_demangled() << '\n'; // explicitly using no-RTTI methods // int>::name_begin(void) std::cerr << template_info<int>::name_begin() << '\n'; // int std::cerr << template_info<int>::name_demangled() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >::name_begin(void) std::cerr << template_info<std::string>::name_begin() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << template_info<std::string>::name_demangled() << '\n'; template_info_ptr p1 = template_info<int>::construct(); template_info_ptr p2 = template_info<std::string>::construct(); std::cerr << (p1 == p2) << '\n'; std::cerr << (p1 != p2) << '\n'; } If there is interest, I can commit code to sandbox and request for review. P.S.: As I know, Boost.Function, Boost.Shared_ptr and Boost.Exception use code similar to what I am proposing. Following libraries use typeid() and can benefit from using proposed classes: Boost.MSM, Boost.Math, Boost.Test, Boost.Graph, Boost.Units, Boost.XPressive, Boost.Any, Boost.Statechart -- Best regards, Antony Polukhin

3 4

[filesystem] Linker error against std::codecvt in VS2012 RC
by Lars Viklund 02 Jun '12

02 Jun '12

Hi list, I foolishly installed the Visual Studio 2012 RC yesterday night and made an overnight build of Boost. It seems like there's something awry, as I'm getting a mysterious linker error in Filesystem's path.obj [1], even in a fresh empty testbed project. I'm linking Boost statically and the CRT dynamically. If I link the CRT statically, the linker error goes away. Has anyone else installed this software and can reproduce this problem? I'm building Boost against trunk, r78785. I dread to think of the horror that I will have go through in actually reporting a bug against the runtime itself :( [1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z) -- Lars Viklund | zao(a)acc.umu.se

4 5

[msm]entry point pseudo states and events (Re: [msm] orthogonal region and event consume)
by Takatoshi Kondo 02 Jun '12

02 Jun '12

Hi Christophe, I changed the subject. Current topic isn't concerned with orthogonal region directly. On Thu, May 31, 2012 at 5:43 AM, Christophe Henry <christophe.j.henry(a)googlemail.com> wrote: > Hi Takatoshi, > > >>> I read your ticket. Note that it's not UML-conform to have 2 transitions >>> originating from Entry1 (11-08-06.pdf §15.3.8 page 551). >>> After reading the Standard again twice, I realized that no example >>> provided >>> there displays any event on both transitions, which is really bad if it's >>> what they mean. I need to have a look at other literature. > > >> I read the section that you mentioned carefully. My interpretation of >> UML specification is different from yours. >> It's really difficult to explain my interpretation. So, I draw the >> diagram. See the attached file. >> Am I misunderstanding? > > > I will not pretend I have the perfect understanding of the Standard. Here's > my take. I also saw the sentence on top of your diagram and didn't fully > understand it when reading the Standard. There is also the following > sentence in the Standard: > > "An entry pseudostate is used to join an external transition terminating on > that entry point to an internal transition > emanating from that entry point". > > Which sounds logical because on your diagram the regions would not be > orthogonal. > > This means you cannot have transitions triggered by different events leading > to the entry point, not can you have different transitions leaving it. You > will need more entry points. > > Caution: I am far from being sure I got it right. That's why I precised my > definition of it in the doc. The implemented solution has the advantage that > you have the normal transition handling, including multiple transitions and > guards, events with data, base events, etc. > What you don't have is entry in multiple regions, which only the fork > currently provides, at the cost of lesser encapsulation. > Correct or not, this is the part of the Standard I chose to implement pseudo > entries. > > To be honest, I'm not of fan of pseudo entries. I prefer the vastly superior > solution of entering a submachine the "normal" way, then letting a > templatized, enable_if'd on_entry of the submachine do something clever with > the event at compile-time. Aha! I completely overlooked such approach. For example, we can choose the initial state in submachine using mpl and initial_state typedef instead of using entry_pseudo_state. I believe that I've understood your design decisions. I also think that following the UML standard blindly is not essential. >> My goal is to improve sub-machines' re-usability. If we want to reuse >> sub-machines in another state machines, sub-machines shouldn't know >> the outside information. > > > I agree but is it the case? I mean, if you send normal events to your > submachine through your outer machine, it also needs to know them, right? > I understand this as: "hi, I'm a submachine and I provide the following > entry points: Entry1 requires Event1, Entry2 requires Event2, etc.". A bit > like function parameters. I wanted to explain that as follows: "hi, I'm a submachine and I provide the following entry points: Entry1 accepts any events. Because I don't care that. " Let me introduce more practical example that requires entry_pseudo_state. ScanFinger.png is a sub-machine. This sub-machine's primary purpose is to scan fingerprint. Before scanning, the sub-machine checks that finger is alive or not. But it's optional. To skip this check procedure, the entry point pseudo state ScanOnly is provided. FingerPrintRegister.png is the parent state machine. It uses ScanFinger as a sub-machine twice. In this scenario, alive checking is not required. So, the parent machine uses ScanOnly enty_pt. In another scenario, not mentioned here, might require the normal entry into ScanFinger to check the finger is alive. ScanFinger machine doesn't care about outer event. In FingerPrintRegister, the states RightScnning and LeftScanning have different incoming events for ScanOnly entry points. But any events are accepted. And then, it's not referred. Based on your suggestion, I introduce the base event class. As long as the incoming event of entry point is not "none", this approach works good. struct AnyEvent {}; struct Completed: public AnyEvent {}; struct StartButtonPressed: public AnyEvent {}; (See 39_FingerPrintExampleBaseEvent.cpp) If the incoming event is "none", the transition is stopped. Sometimes I want to use "none" as incoming event for entry point in the same sub-machine. And it is impossible that msm::front::none inherits user event classes such as AnyEvent. I'm trying to find better approach to solve the above problem. Thanks, Takatoshi >> See my second mail in this thread. My solution using templates >> (entry_pseudo_event_template.cpp) requires the template parameters >> same as the number of entry point pseudo states in sub-machine. It's >> acceptable but if outgoing transition would be able to use none, I >> would remove the template parameters. > > >> In the above case, it is not required to support multiple incoming >> transitions to one entry pseudo state. Because the instances of >> sub-machine are different. > > > In this case, maybe I could interest you in defining a base event class for > Event1 and Event2, then making this base event the event triggering the > inside transition. Your first example would be changed this way: > > struct BaseEvent {}; > struct Event1: public BaseEvent {}; > ... > msmf::Row < Entry1, BaseEvent, State2_2, msmf::none, msmf::none > > > > > Regards, > Christophe > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 6

Interest in double-ended priority queue? (priority_deque)
by Nathaniel McClatchey 02 Jun '12

02 Jun '12

Details: Template-based container adapter. Mimics std::priority_queue interface and requirements. O(1) read and O(log n) delete of either end of queue. O(n) create and merge. Functions for unordered access and mutating of elements. Remaining development: Further optimization. Note: Implementation is similar to but independent from http://lists.boost.org/Archives/boost/2011/12/188848.php

2 2

Standardization of Boost (and other) libraries
by Beman Dawes 01 Jun '12

01 Jun '12

The C++ standards committee has set up a discussion forum (also accessible via email) to help those preparing language and library proposals. Requests for feedback, help, champions, and anything else related to proposals is on topic. https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals Note that this is a different URL than mentioned at C++Now! - language and library proposal groups have since been combined into a single group. After some false starts, discussion has started in earnest. The first two requests for feedback were on proposals for Boost.Any and Boost.Optional. If you are interested in proposing a Boost library for standardization, you probably want to check out std-proposals. --Beman

1 0

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by John Maddock 01 Jun '12

01 Jun '12

>>* What is the type of boost::multiprecision::number_category<B>::type for >>all the provided backends? Could the specialization for >>boost::multiprecision::number_category<B>::type be added in the >>documentation of each backend? and why not add also B::signed_types, >>B::unsigned_types, B::float_types, B::exponent_type? > > OK. On second thoughts, the members of B::signed_types etc are basically implementation details - optimizations if you will. Rather than listing the types explicitly I'd prefer some more weasel wording along the lines of "This type will interoperate natively with any signed or unsigned built in integer type no wider than a long - this means for example that multiplying by a integer literal is more efficient than constructing an mpz_int temporary from the integer and then multiplying. Likewise for the other arithmetic operations." John.

1 0

Re: [boost] [filesystem] Linker error against std::codecvt in VS2012 RC
by Stewart, Robert 01 Jun '12

01 Jun '12

Peter Dimov wrote: > Lars Viklund wrote: > > > [1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : > > error LNK2001: unresolved external symbol "protected: virtual > > int __thiscall std::codecvt<wchar_t,char,int>::do_length(int > > const &,char const *,char const *,unsigned int)const " > > (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z) > > Well, you could start by preparing a simple test program that > calls std::codecvt in the same way path.obj does, to eliminate > Boost as a factor. If do_length is indeed not present in the > dynamic runtime, this would probably be a showstopper bug > against the RC, so it will get noticed. :-) If that's not the problem, verify that you built Boost.Filesystem using the same CRT. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

Re: [boost] [Boost-users] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by Jeffrey Lee Hellrung, Jr. 31 May '12

31 May '12

Just to preempt this, I think it will be more appropriate for any review discussions to take place on the developers' list (boost(a)lists.boost.org) On Wed, May 30, 2012 at 2:38 PM, Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr> wrote: > Le 29/05/12 23:08, Jeffrey Lee Hellrung, Jr. a écrit : > > Hi all, > > > > The review of the proposed Boost.Multiprecision library authored by John > Maddock and Christopher Kormanyos has been scheduled for > > > > June 8th - June 17th, 2012 > > > > and will be managed by myself. > > > > I hope everyone interested can reserve some time to read through the > documentation, try the code out, and post a formal review, either during > the formal review window or before. > > > Hi, > > glad to see that the library will be reviewed soon. > > I have spent some hours reading the documentation. Here are some comments > and a lot of questions. > > * As all the classes are at the multi-precision namespace, why name the > main class mp_number and not just number? > > typedef mp::number<mp::mpfr_float_**backend<300> > my_float; > > * I think that the fact that operands of different backends can not be > mixed on the same operation limits some interesting operations: > > I would expect the result of unary operator-() always signed? Is this > operation defined for signed backends? > I would expect the result of binary operator-() always signed? Is this > operation defined for signed backends? what is the behavior of > mp_uint128_t(0) - mp_uint128_t(1)? > > It would be great if the tutorial could show that it is possible however > to add a mp_uint128_t and a mp_int256_t, or isn't it possible? > I guess this is possible, but a conversion is needed before adding the > operands. I don't know if this behavior is not hiding some possible > optimizations. > > I think it should be possible to mix backends without too much complexity > and that the library could provide the mechanism so that the backend > developer could tell to the library about how to perform the operation and > what should be the result. > > * Anyway, if the library authors don't want to open to this feature, the > limitation should be stated more clearly, e.g in the reference documentation > "The arguments to these functions must contain at least one of the > following: > > An mp_number. > An expression template type derived from mp_number. > " > there is nothing that let think mixing backend is not provided. > > * What about replacing the second bool template parameter by an enum class > expression_template {disabled, enabled}; which will be more explicit. That > is > > typedef mp::mp_number<mp::mpfr_float_**backend<300>, false> my_float; > > versus > > typedef mp::mp_number<mp::mpfr_float_**backend<300>, > mp::expression_template::**disabled> my_float; > > * As I posted in this ML already I think that allocators and precision are > orthogonal concepts and the library should allow to associate one for fixed > precision. What about adding a 3rd parameter to state if it is fixed or > arbitrary precision? > > * Why cpp_dec_float doesn't have a template parameter to give the integral > digits? or as the C++ standard proposal from Lawrence Crow ( > http://www.open-std.org/jtc1/**sc22/wg21/docs/papers/2012/**n3352.html<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html>), > take the range and resolution as template parameters? > > * What about adding Throws specification on the mp_number and backend > requirements operations documentation? > > * Can the user define a backend for fixed int types that needs to manage > with overflow? > > * Why bit_set is a free function? > > * I don't see nothing about overflow for cpp_dec_float backend operations. > I guess it is up to the user to avoid overflow as for integers. what would > be the result on overflow? Could this be added to the documentation? > > * can we convert from a cpp_dec_float_100 to a cpp_dec_float_50? if yes, > which rounding policy is applied? Do you plan to let the user configure the > rounding policy? > BTW, I see in the reference "Type mp_number is default constructible, and > both copy constructible and assignable from: ... Any type that the Backend > is constructible or assignable from. " > I would expect to have this information in some way on the tutorial. I > will appreciate also if section "Constructing and Interconverting Between > Number Types" says something about convert_to<T> member function. > > If not, what about a mp_number_cast function taking as parameter a > rounding policy? > > * Does the cpp_dec_float back end satisfies any of the Optional > Requirements? The same question for the other backends? > > * Is there a difference between implicit and explicit construction? > * On c++11 compilers providing explicit conversion, couldn't the > convert_to function be replaced by a explicit conversion operator? > * Are implicit conversion possible? > > * Do you plan to add constexpr and noexcept to the interface? After > thinking a little bit I'm wondering if this is this possible when using 3pp > libraries backends that don't provide them? > > * Why do you allow the argument of left and right shift operations to be > signed and throw an exception when negative? Why don't just forbid it for > signed types? > > * Why the "Non-member standard library function support" can be used only > with floating-point Backend types? Why not with fixed-point types? > > * What is the type of boost::multiprecision::number_**category<B>::type > for all the provided backends? Could the specialization for > boost::multiprecision::number_**category<B>::type be added in the > documentation of each backend? and why not add also B::signed_types, > B::unsigned_types, B::float_types, B::exponent_type? > > * Why have you chosen the following requirements for the backend? > - negate instead of operator-() > - eval_op instead of operator op=() > - eval_convert_to instead of explicit operator T() > - eval_floor instead of floor > > Optimization? Is this optimization valid for short types (e.g. up to 4/8 > bytes)? > > * As the developer needs to define a class with some constraints to be a > model of backend, which are the advantages of requiring free functions > instead of member functions? > * Couldn't these be optional if the backend defines the usual operations? > * Or could the library provide a trivial backend adaptor that requires the > backend just to provide the usual operations instead of the eval_xxx? > * How the performances of mp_number<this_trivial_**adaptor<float>, false> > will compare with float? > > * And last, I don't see anything related to rvalue references and move > semantics. Have you analyzed if its use could improve the performances of > the library? > > Good luck for the review. A really good work. > Vicente > > > ______________________________**_________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users> >

3 2

[nowide] Easy Unicode For Windows: Request For Comments/Preliminary Review
by Artyom Beilis 31 May '12

31 May '12

Hello all Booster, I comments on a library that I want to submit for a formal review. The library provides an implementation of standard C and C++ library functions such that their inputs are UTF-8 aware on Windows without requiring using Wide API to make program work on Windows. Library: Boost.Nowide Download: http://cppcms.com/files/nowide/nowide.zip Documents: http://cppcms.com/files/nowide/html/ Features: http://cppcms.com/files/nowide/html/index.html#main_the_solution Tested On: OS: Windows 7 32/64 bit, Linux Compilers: GCC-4.6, MSVC-10 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

7 17

Is there interest in typeid(TYPE).name() like function that does not require RTTI
by Antony Polukhin 30 May '12

30 May '12

Hi, Would be there some interest in function for getting class name without RTTI? Such function can be implemented like that: template <class TemplateNameT> std::string template_type(const TemplateNameT& v) { #ifdef _MSC_VER const char* const template_name_begin = strstr(BOOST_CURRENT_FUNCTION, "(const ") + sizeof("(const ") - 1; BOOST_ASSERT(template_name_begin); const char* const template_name_end = template_name_begin + strlen(template_name_begin) - sizeof("&)"); #else // Code for other platforms #endif return std::string(template_name_begin, template_name_end); } If there is some interest, I'll update code to work on other platforms, and change method signature from template_type(instance) to template_type<InstanceTypeT>::name() Usage example: // Function can be compiled with RTTI disabled. template <class T> void foo(const T& val) { std::cerr << template_type<T>::name(); // instead of typeid(T).name(); } -- Best regards, Antony Polukhin

4 7

[msm] orthogonal region and event consume
by Takatoshi Kondo 30 May '12

30 May '12

Hello Christophe, I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked. I think the event isn't consumed correctly. If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed. What do you think? Thanks, Takatoshi

4 9

Memory upgrade of wowbagger
by DongInn Kim 30 May '12

30 May '12

Dear all, My name is DongInn Kim, systems administrator of the current boost server machine, wowbagger. I am sorry for this short notice but we would like to upgrade wowbagger's memory at 2:00pm (E.T.) May 30, 2012. We need to reboot wowbagger and It should not take more than 10 mins to upgrade RAMs. During the memory upgrade, the following services would not be available. - mailing list - mail archives - trac - subversion - official websites Please let me if you have any issues or questions about the outage. Regards, -- - DongInn --------------------------- CREST System administrator dikim(a)cs.indiana.edu Indiana University Bloomington, IN

1 1

[1.50.0] Beta closing; planning to build Beta RC tomorrow
by Beman Dawes 30 May '12

30 May '12

Per the schedule, building a release candidate for the beta will begin tomorrow. There are still a few hours left for merging emergency bug fixes that are stable in trunk, with a release manager's permission. But that's being charitable. We need to let tests cycle overnight and move forward. This is a beta, after all, and not the final release. branches/release will reopen for bug fixes as soon as the beta ships. See the calendar at http://www.boost.org/community/index.html for the release schedule. --Beman

1 0

Status of Boost.Atomic?
by Sean Chittenden 30 May '12

30 May '12

Does anyone know what the status of Boost.Atomic is? I remember hearing that Boost.Atomic was to be committed by the end of March, but now that we're backed up against the release, it doesn't look like Boost.Atomic is going to make it in to 1.50.0. Is there any chance that someone can push Boost.Atomic along and commit it to trunk so that it can finally get some exposure and possibly make it in to a release? -sc PS CLang 3.1 was released recently with with support for atomics, but the current version of XCode ships a dated version of CLang 3.1 with atomics disabled. This compatibility shim is going to be very useful during the C++11 transition. >>>> Where can I find the latest version of boost.lockfree ? There's nothing >>>> in >>>> the sandbox or the vault (it seems). The latest commit on Tim's public >>>> git >>>> repo was done more than 6 month ago. >>>> >>>> Now that atomic has been accepted, are there any roadblocks to have >>>> boost.lockfree released ? >>> >>> boost.atomic has been accepted, but it hasn't been merged into trunk, yet >>> ... helge, do you have any timeline? >> >> I will package it up before the end of march, this should suffice? > > great! -- Sean Chittenden sean(a)chittenden.org

2 1

Release notes for 1.50
by Daniel James 30 May '12

30 May '12

Hello everyone, It's time to fill in the release notes, they're at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/boost… Note that from now on, that this is on the live site, not the beta site. If you don't know quickbook syntax, don't worry, I'll clean it up before regenerating the page. You can see the html output at: http://www.boost.org/users/history/version_1_50_0.html It isn't automatically updated, so you'll only see your changes when I update it. But if that's too much for you, you can email me and I'll sort it out. It's probably better for you if do it yourself, as there's always the chance that an email will slip through the cracks, and it will be easier for you to fix typos and link errors later on. Also, please don't link to changesets in the history, if you don't have something to link to, just create a ticket, accept it and close it with a message like: "Fixed in trunk in [1234]. fixed in release in [5678]". It's also a good idea to add a more detailed change log to your library's documentation and link to that. There are a few outstanding things to do, which I should sort out before posting this, but this is at shorter notice than normal. I'll deal with them in the next day or two, so please have a little patience. thanks, Daniel

7 10

Status of GIT and BOOST
by Marshall Clow 29 May '12

29 May '12

[ reposted in its own thread so that it is less easily missed ] Synopsis: ========= The Boost Steering Committee has agreed IN PRINCIPLE to move ahead with the migration to Git and to a modular repository structure. What? ===== Development of Boost will move from a monolithic subversion repository to the much-discussed Git repository structure consisting of one super-module that points (via submodules) to other repositories, each containing an individual Boost library. The Git repositories will be hosted on github. Although Boost will move to a distributed development model, it will still be tested and released as a unified whole. There will be scripts to reassemble the monolithic Boost from its constituents. The development work flow need not change for contributors. They have the option to check out boost super-module and all the submodules, execute the script to make a monolithic whole, and develop and test as usual. It is currently an open question what to do about issue tracking once we move to modularized repos. Both Github and Redmine have been suggested as possible solutions that would give users a unified way to search for bugs across all of boost. The migration will NOT take place before this issue is settled. Why? ==== Boost is big and getting bigger. We've been experiencing scalability problems with our tools and with our release and testing procedures for a while now. The problem is bigger than "subversion commands are slow". Moving a large, diverse library collection forward in lock-step slows down progress. Our solutions to the scalability problems have themselves caused problems. We don't branch from trunk for our releases. Changes languish on trunk because people forget to merge them. Trunk is a wild west where test results for any one library are often broken due to requirements shifting from under it, causing confusion about whether a change can be safely merged to release. And the converse is also true: just because tests are green on trunk is no assurance that a change won't cause problems on release. The solution is to free each library to evolve independently within its own repository. Boost is a collection of the last stable releases of each of its constituent libraries. Library maintainers develop and test against this latest stable library collection and issue rolling releases on their own timetable. Release managers pick which versions of each library to include and have the option to temporarily fork a library to correct integration issues to get a release out, issuing pull requests to get the fixes upstream. The result is a more dynamic, loosly-coupled ecosystem where both the individual libraries and Boost as a whole can move forward more quickly. How? ==== The modular git repositories have already been created along with a script to populate them automatically. At some point, the old svn repo will be locked permanently and the modular git repos will be re-populated from svn. John Wiegley has worked on a script to do the conversion with perfect fidelity. A separate git repo with all of Boost's history will be created such that it can be grafted on to each submodule if desired. That way, each submodule can share history with all the others (a significant space win). The test and release scripts and the website will be updated to account for the new development model. From that point forward, all development will take place in the git repos. The old Trac will eventually be locked and archived. Whatever issue tracking solution we come up with, tickets must be migrated. The plan is still coming together here. Bear with us. When? ===== The approval is IN PRINCIPLE and not IN FACT at this point because the necessary pieces are not yet all in place. In particular, issues such as trac integration and testing are not yet settled. Also, we want a script in hand that verifies that no changesets are lost or munged in the svn->git migration. Once the steering committee is satisfied that all the pieces are in place, we'll give a final go-ahead, the dates will be announced, and the transition will take place. An ETA is hard to predict at this point, but we are aiming for making the switch in the next few months. Possibly after 1.50 or 1.51. Comments: ========= The Boost Steering Committee understands that there is general but not universal support in the Boost community for this migration. The committee came this to decision after long analysis of the ongoing problems facing Boost, and of the merits of the proposed migration. It is the role of the Steering Committee to make difficult decisions like this, even when the wider community is unable to reach universal consensus. We will do everything to make this transition as painless as possible, and to give those not comfortable with git the support they need. We all appreciate your understanding. THANKS: ======= Thanks are due to the many people who have worked over the past few years to make this transition happen, including: Dave Abrahams Daniel Pfeifer John Wiegley Beman Dawes Eric Niebler Troy Straszheim Thanks, guys! Here's to making Boost better, faster and stronger. --Your friendly neighborhood steering committee Beman Dawes Dave Abrahams Hartmut Kaiser Jeff Garland Jon Kalb Marshall Clow Robert Stewart Steven Wantanabe -- 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

Revelations at C++Now!?
by Lars Viklund 29 May '12

29 May '12

Hi list. Rumor has it that C++Now! is now over, and people are slowly returning to reality. What I wonder is if anything relevant to our lives was discussed or revealed at the conference. I know how easy it is at a conference or workshop to completely forget about the people out there that are not present when things are discussed or presented. If I recall correctly, there were to be some modularisation/VCS presentation from the Steering Committee, and I'm sure that you lads all had some lovely brainstorms and fistfights over beer and pizza. Come on, spill the beans. What did you all decide that will have an influence on the lives of us mortals going forward? -- Lars Viklund | zao(a)acc.umu.se

8 10

[filesystem] Create poisoned directory?
by Beman Dawes 29 May '12

29 May '12

Ticket #6932 identifies error reporting bugs in the filesystem create_directories() function. To run test cases I'd like to create a directory is OK to delete, but is poisoned against as many other operations as possible. How can this be done via the POSIX API? How can this be done via the Win32 API? Thanks, --Beman

2 1

[Spirit] Possible regression (certainly a behavioural change) regarding sequential-or with optional rhs
by adam.butcher＠selexelsag.com 29 May '12

29 May '12

Hi Hartmut, Joel, It seems that the new optional-collapsing behaviour in Spirit 2.5.1 overly simplifies the attributes of certain productions, transforming a tristate 'optionality' (optional<optional<S>>) into a simple boolean (optional<S>). This effectively flattens the two 'omitted' states into one -- in some cases (the use case below for example) they need to be distinguished (unless there is a better way to specify the rule). Ref our previous discussion on this ( http://lists.boost.org/Archives/boost/2009/12/159680.php) (in fact it is exactly this example that is causing us the problem with the latest version). Adam Butcher wrote on 2009-12-04 at 13:19:51: > [snip] > The [array subscript] grammar spec is > > (start || (':' >> -start)) > > and not > > (start || (':' >> start)) > > I would expect optional<S> for both only in the latter case. > In the former I am deliberately allowing the specifier to the right of > the colon to be omitted -- within the already optional right-hand-side > of the sequential-or. This allows for input such as > > (1) $x // $x (assume it references a sequence) > (2) $x[7] // element 7 of $x > (3) $x[7:] // a slice of $x beginning at element 7 > (4) $x[:7] // a slice of $x up to element 7 > (5) $x[2:7] // a slice of $x beginning at 2 ending at 7 > (6) $x[:] // equivalent to $x (unspecified bounds) > > In the action function, wrt to right-hand-side of the sequential-or, I > need to determine: > a) whether a range specifier has been provided at all > (given by (bool) at_c<1>(access_spec)) > b) whether the range specifier includes an explicit bound > (given by (bool) *at_c<1>(access_spec)) > > The left-hand-side of the sequential-or is either an (optional) > 'range_begin' index if a range specifier is given or a lone 'index' > specifier if no range specifier is given. > > If the two optionals on the right-hand-side were collapsed would I not > lose the ability to distinguish between (2) and (3)? The attached program demonstrates the issue. With boost 1.47 (2.5) it works fine, with 1.48 (2.5.1) it breaks. I've attached the source file but included the comment at the top in this mail for convenience. Kind regards, Adam // Change of behaviour in Spirit 2.5.1 regarding collapsing optionals // in sequential-or productions. // // Previous discussion from 2009 related to this: // http://lists.boost.org/Archives/boost/2009/12/159680.php // // // Given the STDIN // // s[:] // // the program below is expected to produce the following output: // // Have range spec... // No begin specified, using container begin. // No end specified, using container end. // Got: 'Range[B:E)' // // However, with 2.5.1, it produces the following: // // Have range spec... // No begin specified, using container begin. // Have range end '' // Got: 'Range[B:)' // // 2.5.1 also fails with the simpler STDIN: // // s[7] // // the program is expected to output: // // Have plain index 7 // Got: 'Index[7]' // // but with 2.5.1 it outputs: // // Have range spec... // Have range begin '7' // No end specified, using container end. // Got: 'Range[7:E)' // // This can be remedied to an extent by switching the #if 1 below // to be #if 0 enabling the collapsed optional code; however this // makes the presence of range-end indistinguishable from the // presence of a range-spec. // ----------------------------------------------- This email and any attached files contains company confidential information which may be legally privileged. it is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel.

1 0

[bind][phoenix] unified placeholders, yea or nay?
by Eric Niebler 29 May '12

29 May '12

I'm considering taking on as a side project the unification of the bind and phoenix placeholders, a perennial source of confusion and annoyance. I hesitate before beginning because it necessarily introduces some complexity into boost.bind, a very small, simple, and light-weight library. In particular, the unification would: 1) Cause boost.bind to depend on boost.proto. (I would do what I could to keep that dependency as slight as possible.) 2) Could not be supported on all platforms; e.g. not on borland or (gcc < 4) where the placeholders are actually static inline functions(!). (Peter, is this an ODR thing?) 3) Would introduce Phoenix behaviors into Bind, insofar as _1 is a lambda such that _1(42) evaluates to 42. At this point, it's not obvious to me that the benefits outweigh the costs. Opinions? Peter, I'd especially like to hear your thoughts. -- Eric Niebler BoostPro Computing http://www.boostpro.com

9 13

Re: [boost] [Intrusive] Cleaning up trailing white space
by Brian Wood 29 May '12

29 May '12

Olaf van der Spek <ml(a)vdspek.org> On Thu, May 17, 2012 at 1:12 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> >> This is probably the easiest way to improve Boost. ?I hope authors will > Really? Why? It can be done with a simple sed script and applied either to individual libraries or all of Boost. It's a small detail, but I hope it gets some attention. I brought it to Ion's attention as I use the Intrusive library and take a number of steps to reduce the need for new hardware. I won't stop using the library if he doesn't do this, but the squeaky wheel gets the oil. Cheers, Brian Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

10 16

[bind]bind question
by Max 28 May '12

28 May '12

Hi, I have the following code: bool do_something_conditional(int *handle, const boost::function<bool(int)> &pred); bool pred_a(int handle); bool pred_b(int handle, int n1, int n2); bool do_something(int *handle, int n1, int n2) { return do_something_conditional(handle, boost::bind(std::logical_and<bool>(), boost::not1(&pred_a), boost::bind(&pred_b, _1, n1, n2))); } But it does not compile. I have been not playing with bind stuff for some time. But I've reviewed the doc and some of my old 'bind' code, it seems correct to me. The error message, you know, is quite complicated for me to find a direct answer. Could anybody please help me? Thanks in advance. I'm using 1.39 with MS VS2008SP1 Best regards Max

4 6