- Boost - lists.boost.org

[Who's Using Boost?] FaceBook
by Dave Abrahams 04 Jun '12

04 Jun '12

as noted in https://www.facebook.com/notes/facebook-engineering/folly-the-facebook-open… -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 4

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