May 2012 - Boost - lists.preview.boost.org

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by Marc Glisse 09 Jun '12

09 Jun '12

(sorry for the broken thread, I wasn't subscribed yet) A few quick comments: * gmpxx != mpfr_class * the version of gmpxx in the repository hasn't used any temporary for the example given in the introduction for a while, it is only because of a slow release cycle that you haven't seen it yet (will be in 5.1). * the example about using 0 vs 11 temporaries doesn't mention what happens to the boost package if we disable expression template. Does it use a single temporary (using rvalue-references) or plenty? * having an implicit narrowing conversion from double to bigint is a bad idea, it should be explicit (it isn't completely obvious from the doc if that is the case). * you could get good results with a backend that uses gmp's mpn_* functions but not the mpz_t type. * what about infinite precision floats? By that I mean something like bigint*2^n, where operations + - * are computed exactly. It can be quite a bit faster than rationals, when it is sufficient. * if I want reference-counting, I guess that should be done in a back-end. -- Marc Glisse

5 22

status of sp_counted_base_solaris.hpp
by Graham Bennett 07 Jun '12

07 Jun '12

Hi all, I'm interested in getting boost::shared_ptr to use atomic ops on Solaris. I notice there is an implementation using the OS-provided atomics in boost/detail/sp_counted_base_solaris.hpp, but it doesn't seem to be included. According to this thread: http://lists.boost.org/Archives/boost/2006/07/107144.php, it seems the reason might be that it wasn't possible to come up with a proper preprocessor condition to include it on the right versions of Solaris. I'm considering modifying my boost installation to include this header on Solaris - does anyone know of any issues with the code, or can they confirm that it has been well tested? Are there any other reasons for its omission? Thanks, Graham -- Graham Bennett

4 7

[review] Multiprecision review scheduled for June 8th - 17th, 2012
by Jeffrey Lee Hellrung, Jr. 07 Jun '12

07 Jun '12

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. >From the Introduction: -------- "The Multiprecision Library provides *User-defined* integer, rational and floating-point C++ types which try to emulate as closely as practicable the C++ built-in types, but provide for more range and precision. Depending upon the number type, precision may be arbitrarily large (limited only by available memory), fixed at compile time values, for example 50 decimal digits, or a variable controlled at run-time by member functions. The types are expression-template-enabled for better performance than naive user-defined types." -------- And from the original formal review request from John: -------- Features: * Expression template enabled front end. * Support for Integer, Rational and Floating Point types. Supported Integer backends: * GMP. * Libtommath. * cpp_int. cpp_int is an all C++ Boost licensed backend, supports both arbitrary precision types (with Allocator support), and signed and unsigned fixed precision types (with no memory allocation). There are also some integer specific functions - for Miller Rabin testing, bit fiddling, random numbers. Plus interoperability with Boost.Rational (though that loses the expression template frontend). Supported Rational Backends: * GMP * libtommath * cpp_int (as above) Supported Floating point backends: * GMP * MPFR * cpp_dec_float cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher Kormanyos' e_float code (published in TOMS last year). All the floating point types, have full std lib support (cos sin exp, pow etc), as well as full interoperability with Boost.Math. There's nothing in principal to prevent extension to complex numbers and interval arithmetic types (plus any other number types I've forgotten!), but I've run out of energy for now ;-) Code is in the sandbox under /big_number/. Docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… -------- 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. I expect to conduct the review in the "traditional" manner, i.e., entirely within the regular boost developers' mailing list (boost(a)lists.boost.org) I will send a reminder of review process details closer to the review window. Thanks! - Jeff

4 23

[1.50.0] Beta 1 release candidates available for testing
by Beman Dawes 06 Jun '12

06 Jun '12

Release candidate files for 1.50.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

16 43

[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

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

[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

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