- Boost - lists.boost.org

Query regarding Boost 1.39.0
by Kumar, Nilesh 14 Jul '11

14 Jul '11

Hi, I have read the Release notes. I wanted to confirm a few things with respect to Boost 1.39.0 : 1. Is RHEL 5.5 supported? 2. Is there a 64-bit support? Thanks and regards, Nilesh ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. By messaging with Sender you consent to the foregoing.

1 0

e_float codes are in the sandbox
by Christopher Kormanyos 14 Jul '11

14 Jul '11

The e_float codes are in the sandbox. I have done my best to prepare these codes for initial submission. * Notes for those familiar with the ACM publication: - The bugs reported in the past have been corrected. - The special functions have been reduced to include only (elementary transcendental + gamma + zeta) for real and complex. - The test suite has been reduced accordingly. - The test program runs in ~1-10 seconds for 100 digits depending on the CPU and selected big-number back-end. - Big-number back-end support for MPFR, GMP and my own EFX are included. - The Fortran-90 REAL*16 back-end support has been removed. - The interfaces to Mathematica, Python and the CLR have been removed. - A partial implementation of a generic functional interface has been added. I am excited to see what refactoring and redesign improvements might be suggested. Please be aware that e_float is high-performance, error-intolerant code. So always remember to run the test suite and pay attention to the results and timing before suggesting any refactoring. Sincerely, Chris.

2 1

[property_tree] parsing XML
by Andrzej Krzemienski 14 Jul '11

14 Jul '11

Hi, I recently discovered that Boost already provides a tool for XML parsing and generation. While it has been there for a long while, I failed to recognize it because it has not been sufficiently advertised and described. Boost.PropertyTree does allow reading and writing of XML files. It does not perform schema validation and is not 100% W3C compliant due to the way of handling white space, but it is sufficient for most of the uses. It has a great framework for customizing user defined types that is not documented. I tried to provide a guide on parsing XML on my blog: http://akrzemi1.wordpress.com/2011/07/13/parsing-xml-with-boost/ But I really believe this guide belongs to the documentation of Boost.PropertyTree. I would be happy to add it there, but I am not familiar with Boost process. Should I just contact the maintainer and discuss the addition? Regards, &rzej

2 1

Boost.Conversion - pre review request
by Vicente Botet 13 Jul '11

13 Jul '11

Hi, I've been reworking the Boost.Conversion library Documentation: http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… Sandbox :http://svn.boost.org/svn/boost/sandbox/conversion/ Description: Boost.Conversion manages with generic extrinsic conversion between unrelated types. These conversion can be seen as implicit or explicit conversions. The conversion operator can not be overloaded with a free function on C++. In the past, there were some request to been able to overload the @c static_cast operator []. The author thinks that the language would be more uniform if this extrinsic overload would be possible. The new operators could take the following form operator Target(const Source& val); explicit operator Target(const Source& val); The assignment operator could also be overloaded by a free function with some limitations as described in [] Target& operator=(Target&, Source const&); Boost.Conversion tries to provide a library emulation for this missing feature and shows some needed workarounds that are needed to take care of the current C++ semantics. In order to provide the needed functionality, two type traits are mandatory is_constructible and is_assignable. The library provide a first implementation of these type traits that works on compilers providing some specific features. The idea is that these type traits should be added to Boost.TypeTraits. John, Joel I would like we work together to have these traits available in as many compilers as we can. When we don't have an automatic way to detect these traits, the library provide specialization for some std and boost types. If you agree the library could provide the specializations for all the standard types and optionally for some Boost types. User working with compilers not supporting the definition of these traits, or users that need to make their code portable, will need to specialize these traits by hand for his types. The review dates are 20th to 29th August. I would like to have some feedback before the review so I can have some time to make the library review ready. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-pre-review-request-tp36… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 24

The last (I think) of the Boostcon videos
by Marshall Clow 13 Jul '11

13 Jul '11

Chris' talk: Why C++0x is the Awesomest Language for Network Programming http://blip.tv/boostcon/why-c-0x-is-the-awesomest-language-for-network-prog… Luke's: Sweep-Line Algorithm for Voronoi Diagrams of Points, Line Segments and Medial Axis of Polygons in the Plane http://blip.tv/boostcon/sweep-line-algorithm-for-voronoi-diagrams-of-points… Boris: Boost.Process: Process management in C++ http://blip.tv/boostcon/boost-process-process-management-in-c-5368233 Joel's: Getting Jiggy with Proto — Hands-on Tutorial on C++ EDSL Design http://blip.tv/boostcon/getting-jiggy-with-proto-hands-on-tutorial-on-c-eds… Boris' other one: A Complete Overview on Boost.Jam and Boost.Build http://blip.tv/boostcon/a-complete-overview-on-boost-jam-and-boost-build-53… I think that this is all the Boostcon videos. I'll be checking later to make sure - but if you know of one that I've missed, then please let me know. BTW, Ruediger asked not to have his "Funding Boost development" talk recorded, and I didn't record any of the workshops. -- Marshall -- 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

3 2

[gsoc] Midterm surveys
by Andrew Sutton 13 Jul '11

13 Jul '11

If you are a GSoC student or mentor, please fill out your midterm evaluation. Yes, students have to fill something out too! No midterm evaluation, no pay. Thanks, Andrew

1 0

[1.47] PDF build of documentation available.
by John Maddock 12 Jul '11

12 Jul '11

The PDF builds of the Boost documentation are now available from: https://sourceforge.net/projects/boost/files/boost-docs/1.47.0/ Note that as ever, only the subset of libraries which use quickbook/boostbook/docbook as their documentation format are included in the build. Regards, John.

1 0

Date_Time previous_weekday() returns the same day
by Klaim - Joël Lamotte 12 Jul '11

12 Jul '11

Hi, We have a bug that seems to comes from boost::date_time::previous_weekday() (probably next_weekday() too) usage in case we want to go from a weekday to another same weekday: #include <iostream>#include <boost/date_time.hpp>#include <boost/date_time/gregorian/gregorian.hpp> int main() { using namespace boost::gregorian; auto today = date( 2011, Jul, 12 ); auto last_tuesday = boost::date_time::previous_weekday( today, greg_weekday(boost::date_time::Tuesday) ); std::cout << today << '\n'; std::cout << last_tuesday; std::cin.ignore(); return 0; } This example runs but return the same date twice instead of giving the tuesday before the given date (that is already a tuesday). Compiled with VS2010SP1 (boost 1.46.1) and GCC4.4(boost 1.44.0 - didn't see the difference in the code) What we first supposed was it will go to the tuesday of the previous week if we already are tuesday. It appears to not work this way. Is it the wanted behaviour? If it is, I suggest the documentation to be enhanced to warn the user about the case when you provide a date that is the same provided weekday. The code of boost::date_time::previous_weekday() (as far as I understand it) suggests that it should go to the previous week's weekday instead of returning the same day: template<class date_type, class weekday_type> inline date_type previous_weekday(const date_type& d, const weekday_type& wd) { return d - days_before_weekday(d, wd); } and then : template<typename date_type, class weekday_type> inline typename date_type::duration_type days_before_weekday(const date_type& d, const weekday_type& wd) { typedef typename date_type::duration_type duration_type; duration_type wks(0); duration_type dd(wd.as_number() - d.day_of_week().as_number()); // 1 if(dd.days() > 0){ // 2 wks = duration_type(7); } // we want a number of days, not an offset. The value returned must // be zero or larger. return (-dd + wks); // 3 } Correct me if I'm wrong : 2. checks if the generated day is the same weekday than the provided one, right? So if I'm correct, there might be a problem in 1 or 3? Thanks for your time. Joël Lamotte

1 0

[btree] In-memory B-tree experimental work
by Beman Dawes 12 Jul '11

12 Jul '11

There was quite a bit of speculation at BoostCon about the performance of an in-memory B-tree based ordered associative container. I've done enough experimental work to report some real numbers for an in-memory B-tree map implementation vs std::map: inserting 10000000 elements... btree: 1985589.4 per sec, 81.7% faster than stl stl: 1092714.3 per sec, 45.0% slower than btree iterating over 6321389 elements... btree: 588200694.1 per sec, 2323.5% faster than stl stl: 24270489.8 per sec, 95.9% slower than btree finding 10000000 elements... btree: 2468384.9 per sec, 109.3% faster than stl stl: 1179177.8 per sec, 52.2% slower than btree erasing 10000000 elements... btree: 2444250.3 per sec, 150.7% faster than stl stl: 974793.1 per sec, 60.1% slower than btree Those timings are a simple map<long, int>, and are probably about the best case for the B-tree implementation. In a similar test of a map<char*, int>, i.e. an indirect map using pointers to strings containing the key, the memory B-tree was only slightly faster than the STL. A typical red-black container has an overhead of something like 3 pointers per node, IIRC, so memory use for the B-tree container is presumably a lot less that the STL container, even if the B-tree container has not been packed. Unlike the disk-resident B-tree implementation, the in-memory tree is much closer to the STL interface. The only significant differences are that insert/emplace/erase always invalidates iterators and Key must be Assignable, not just CopyConstructible. The code can be viewed or downloaded at https://github.com/Beman/memory-btree It is currently C++0x only, and tested only with VC++ 10 and GCC 4.6. Since this is the first time I've used move semantics, I may not be getting full mileage out of r-value references yet. There is no documentation yet. I need to set this work aside for awhile to get on with other projects. But I thought there might be interest in the timings. It would also be interesting to push the same set of random numbers into a std::vector, sort it, then run find, iterate, and erase, then look at those timings. --Beman

1 0

identification versus demangle
by Gordon Woodhull 12 Jul '11

12 Jul '11

Hi all, I want to print and visualize MPL.Graph (and thus MSM) metadata. I'm debating whether to help "Make boost::units::detail::demangle an official utility function" [1] (actually the public function is peacefully called simplify_typename) or to use Joel Falcou's Identification library [2]. It would be annoying to users to have to register every type in their graph/state machine, so I guess I'm wondering if demangle(typeid(T).typename()) is impossible on a lot of compilers. Anyone know this? Thanks, Gordon [1] https://svn.boost.org/trac/boost/ticket/4876 [2] https://github.com/boost-vault/Miscellaneous/blob/master/identification-v0.…

3 4