- Boost - lists.boost.org

[Review] UUID review results
by Hartmut Kaiser 12 Jan '09

12 Jan '09

Hi all, Some while ago we have had a lively discussion during the review of Andy Thompkin's UUID library. I counted 11 votes, 10 'yes' votes and one 'no' vote. IMHO the 'no' vote has been superseded by the followup discussion and all issues have been resolved. Almost all reviewers stated the UUID library to be very useful. Given the overwhelming number of 'yes' votes the UUID library is accepted for inclusion into Boost. Before inclusion into the Boost SVN Andy will need to fix a couple of minor issues as discussed during the review, some of which are: - POD-ness - lexical_cast - default construction Congratulations to Andy for his effort related to pushing the UUID library forward. I hope to see active development and maintenance of this library in the future. Regards Hartmut Review Manager

1 0

[iostreams]howto replace ostream buffer?
by Larry Evans 11 Jan '09

11 Jan '09

How can one use iostreams::filtering_streambuf to replace the std::basic_streambuf used by cout. I've tried the code in 1st attachment; however, that code produces the output in 2nd attachment. The desired output is shown in 3ird attachment. How should the code be modified to get the desired output? TIA. -regards, Larry Hello World! is_complete=1 3ird Hello! Hello World! is_complete=1 2ND HELLO! 3ird Hello!

2 3

Proposal: Add Loki Library's SafeFormat to Boost:
by Tom Browder 11 Jan '09

11 Jan '09

The last Loki thread I see here is the one from 2002 discussing adding Loki to Boost. I asked Andrei once about doing that specifically for the Loki SafeFormat functions (FPrint, Printf, and SPrintf) and he said FPrintf wasn't good enough yet. However, I find all of them very useful and would love to see them added to the Boost library I know Boost has Format now, but SafeFormat has some advantages over Boost.Format, one of which is that FPrintf can be output to C++ streams as well as to FILE pointers--very handy when one is gradually converting legacy code to using C++ streams. In addition, I find the SafeFormat family much easier to use than Boost.Format. Andrei's original comments regarding FPrintf's shortcomings are here: https://sourceforge.net/forum/message.php?msg_id=4525195 His "Dr. Dobb's Journal" article describing SafeFormat is here: http://www.ddj.com/cpp/184401987 Thank you for your consideration. Warmest regards, -Tom Tom Browder Niceville, Florida USA

21 96

C++03 unique_ptr emulation
by Howard Hinnant 11 Jan '09

11 Jan '09

I've put up a new version of an C++03 emulated unique_ptr here: http://home.roadrunner.com/~hinnant/unique_ptr03.html This is a "boost-ized" emulation (uses boost tools and is in boost namespace), though I have reason to believe it may not work well on VC+ +05 unless the /Za option is used (I've tested only on gcc 4.0). I'm aware of Ion's interprocess version (http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_sma… ), and thank Ion for his support over the years. This new version is not meant to replace Ion's version. It is simply my current best shot at emulating the unique_ptr behavior as specified in the C++0X CD1 draft. Booster's are welcome to take parts of this implementation and use them in places like interprocess/unique_ptr. Or to just use this unique_ptr directly. It consists of only one header: unique_ptr.hpp, and requires only boost headers, not boost cpp files. Basic documentation is included at the link. -Howard

10 44

[GIL] trouble loading image files
by Kenny Riddile 11 Jan '09

11 Jan '09

This is my first time using GIL and I'm having some difficulty loading jpeg and png files. Here's some code: rgb8_image_t image1; jpeg_read_and_convert_image<rgb8_image_t>( "file.jpg", m_image1 ); rgb8_image_t image2; png_read_and_convert_image<rgb8_image_t>( "file.jpg", m_image2 ); Attempting to load the jpeg causes a crash at jpeg_read_header(&_cinfo,TRUE); in jpeg_io_private.hpp. Attempting to load the png causes a similar crash at png_read_info(_png_ptr, _info_ptr); in png_io_private.hpp. I'm using the libjpeg and libpng builds from these sites: http://gnuwin32.sourceforge.net/packages/jpeg.htm http://gnuwin32.sourceforge.net/packages/libpng.htm

1 1

[Test] documentation inconsistencies
by Thorsten Ottosen 10 Jan '09

10 Jan '09

Hi, I was trying to follow the docs at http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/utf/user-guide/test… I don't want to include everything, so I compile Boost.Test with dynamic linking. In this case I have to include two headers: #define BOOST_TEST_MODULE conditional_cost_experiments #include <boost/test/unit_test.hpp> #include <boost/test/unit_test_suite.hpp> // this one is also needed when linking!!! Maybe it would be better to include the latter header in the first? best regards -Thorsten

2 1

[mp_int] Possible bug in comparison with native types causes overflow_error
by Nathan Kitchen 10 Jan '09

10 Jan '09

I'm getting some strange crashes when I try to compare mp_ints with native types. The code below is sufficient to reproduce it: #include <stdint.h> #include <iostream> #include <boost/mp_math/mp_int.hpp> using namespace boost::mp_math; using namespace std; int main() { mp_int<> a = mp_int<>("0x100000000"); cout << (1 < a) << endl; return 0; } The problem appears to be the definition of integral_ops_impl<..., true>::q (i.e., for signed IntegralT): static const typename MpInt::size_type q = std::numeric_limits<IntegralT>::digits + (MpInt::valid_bits - 1) / MpInt::valid_bits; In the case where IntegralT=int32_t and digit_type=uint32_t, q is 31. Contrast this with the definition for unsigned IntegralT: static const typename MpInt::size_type q = std::numeric_limits<IntegralT>::digits / (MpInt::valid_bits + 1) + 1; When IntegralT=uint32_t and digit_type=uint32_t, q is 1. The overflow of operator< comes because the check that verifies that the MpInt can't fit in an IntegralT is (condition (lhs.size() > q). This fails for q=31. If the definition of q had the first line parenthesized: static const typename MpInt::size_type q = (std::numeric_limits<IntegralT>::digits + MpInt::valid_bits - 1) / MpInt::valid_bits; then q would be 1, and the code branch with the overflow would not be taken. -- Nathan

2 1

[Range] make range_const/mutable_iterator<C>::type non-existent if C is non-range
by Arno Schödl 10 Jan '09

10 Jan '09

Hello, the attached patch makes boost::range_const/mutable_iterator<C>::type non-existent if C does not have the right typedef C::(const_)iterator. For me, this fixed a compilation error in the following situation: template<class Rng, class Val, class BinPred> typename boost::range_const_iterator<Rng>::type lower_bound(Rng const& rng,Val const& x,BinPred pred); // not taken template<class It, class Val, class BinPred> It lower_bound(It itBegin,It itEnd,Val const& x) { // taken return itBegin; // dummy } main() { std::vector<int> vecn; int n=6; lower_bound( vecn.begin(), vecn.end(), n ); } The return type of the overload that is not taken is range_const_iterator< std::vector<int>::iterator >::type. With the old range_const_iterator, this typedef exists, which makes the overload compile, but evaluates to std::vector<int>::iterator::const_iterator, which does not exist and causes a compiler error. With the patch, range_const_iterator< std::vector<int>::iterator >::type already does not exist, and the compiler aborts checking this overload. I don't see a way to fix this without changing or largely reimplementing range_const_iterator, because the mere presence of the "type" typedef in the default case of range_const_iterator causes the problem. Any chance to get this adopted? Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

3 8

BoostCon 2009: Submission deadline extended
by Hartmut Kaiser 10 Jan '09

10 Jan '09

Hi all, The deadline for the submission of session proposals has been extended to January 20th, 2009. No further extensions will be granted. Please find below the original call for participation. Conference registration will be available at http://www.boostcon.com/registration. Regards Hartmut ---------------------------------------------------------------------------- 3rd annual Boost Conference 2009 Aspen CO, USA, May 3-9, 2009, www.boostcon.com ---------------------------------------------------------------------------- Call for participation ---------------------- Promising to be the main face-to-face event for all things Boost (www.boost.org) BoostCon'09 opens the door to your C++ future. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2 and the new C++0x Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- * Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * TR1 and TR2 * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and Developers. Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations ............. Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ...... Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ......... Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ......... Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ............................. These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems boost libraries. Tool Vendors Presentations .......................... We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other * A paragraph or two describing the topic covered, suitable for the conference web site * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half-day, full day * Alternate lengths, if you are willing to make adjustments: 10-20 minute lightning-talks, 45 minutes, 90 minutes, half-day, full day * Audience: users, developers, both * Level: basic, intermediate, advanced * A biography, suitable for the conference web site * Your contact information (will not be made public) Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon09. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted papers will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon CD handed out to attendees. For general information on the BoostCon 2009 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon09(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposals for submissions due: January 20th 2009. Proposals acceptances sent (tentative program available): February 10th, 2009 Fully scheduled program available: March 1st, 2009 Session materials due: April 1st 2009. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[geometry] view_as concept casting
by Simonson, Lucanus J 10 Jan '09

10 Jan '09

There is a clear need for concept casting in a generic geometry type system. Certain geometry concepts imply that an invariant in enforced by a type that models the concept. For some types that invariant is not enforced, but may be true some of the time, and can be checked. Rather than copying the data over to a type that enforces the invariant in order to use a generic API that requires it, it is more convenient to be able to be able view the object as enforcing the invariant. For this purpose, I implemented the view_as function for conceptual casting. //view_of can be specialized or partially specialized as needed template <typename ConceptT, typename T> struct view_of { const T& t_; view_of(const T& t) : t_(t) {} //implements an API that models ConceptT //in terms of T's interface }; template <typename ConceptT, typename T> view_of<ConceptT, T> view_as(const T& obj) { return view_of<ConceptT, T>(obj); } One example of how this could be used is a polygon can be a rectangle, and if so, can be viewed as a rectangle. if(is_rectangle(poly) && equivalent(view_as<rectangle_concept>(poly), rect)) { do_something_with(poly); } else { do_something_else_with(poly); } In the above example, the equivalence check is executed only if the polygon is known to be a rectangle at run time. This is helpful, because while overloads of equivalent that accepts polygon and rectangle as well as rectangle and polygon could be implemented, as the number of types in the system grows, the number of such overloads would grow quadraticly. However, one overload that takes any object that is not a rectangle, checks at runtime if it is a rectangle and views it as a rectangle would suffice for all combinations: template <not_rectangle_type, rectangle_type> //concept checking boilerplate around bool return type goes here equivalent(const not_rectangle_type& obj1, const rectangle_type& obj2) { return is_rectangle(obj1) && equivalent(view_as<rectangle_concept(obj1), obj2); } Another example is that many legacy type systems will have one polygon class that doesn't enforce many invariants and is used everywhere. It depends upon the developer to know (or check) that some invariant (such as rectilinearity) is true when they use it. This polygon type cannot model rectilinear polygon concept, but needs to be conditionally viewed as rectilinear to be used with a generic API that requires type safety wrt. rectilinearity. Is this an issue that the other geometry authors have addressed? Regards, Luke

5 17