October 2010 - Boost - lists.preview.boost.org

[network] cpp-netlib 0.7 released!
by Dean Michael Berris 18 Oct '10

18 Oct '10

Hi Everyone! So, I've been busy the past few hours doing a final push to get 0.7 out the door so that starting tomorrow I can start working on the 0.8 branch to improve the server-side HTTP implementation. Now, it's official, 0.7 is out the door and is ready for prime-time. ;-) In case you'd like to try it out, it's header only and you can download the 0.7 release from: http://github.com/cpp-netlib/cpp-netlib/downloads This has numerous improvements and enhancements over the 0.6 version, and has a more robust definition of the concepts included in the library. Now anybody can start extending cpp-netlib with their own protocol implementations using the common message type. If you want your work to integrate cleanly with the project, you can go ahead and fork my repository (as the project's "benevolent dictator for life") and submit pull requests in case you want to get your implementation/fixes/extensions into the main library distribution. As earlier stated, 0.8 will be a server-side focused development effort which will include a lot of cool things not just an improved HTTP server interface. If you'd like to discuss the effort or join the development, please feel free to send email to either the Boost Developer mailing list (because this library will be submitted for review and inclusion in Boost around December 2010) or the cpp-netlib developers mailing list. Thanks to everyone who's expressed interest, and those who have offered suggestions on the improvements to be made to the library. I hope everyone had a great weekend too! -- Dean Michael Berris deanberris.com

3 3

[OT] Calling Overmind
by John Phillips 18 Oct '10

18 Oct '10

Overmind, Would you please either contact me (John Phillips), or Ron Garcia off list? Thanks. John

1 0

3rd- party reliance for upcoming boost.GIL.IO library
by Christian Henning 17 Oct '10

17 Oct '10

Hi there, We are going to submit the Boost.GIL.IO extension for review and the package relies on 3rd-party libraries; can anyone suggest minimum solution for finding those libraries which would be usable for reviewers to build and run tests/examples? The library is pretty much ready for review and can be found here: http://gil-contributions.googlecode.com/files/boost_review.zip or via SVN, here: http://code.google.com/p/gil-contributions/source/browse/#svn/trunk/gil_2 Thanks, Christian

2 2

[unordered] error: template argument required for ‘struct set_extractor’
by Mateusz Loskot 17 Oct '10

17 Oct '10

Hi, I'm experiencing strange problem with unordered_map.hpp file. I'm using Boost 1.44 with GCC 4.2.1 from XCode on Mac OS X. Compiling simple test: $ cat foo.cpp #include <boost/unordered_map.hpp> int main() {} $ g++ -o foo.o foo.cpp In file included from /usr/local/include/boost/unordered/detail/equivalent.hpp:11, from /usr/local/include/boost/unordered/unordered_map.hpp:19, from /usr/local/include/boost/unordered_map.hpp:16, from foo.cpp:1: /usr/local/include/boost/unordered/detail/extract_key.hpp:31: error: template argument required for ‘struct set_extractor’ /usr/local/include/boost/unordered/detail/extract_key.hpp:77: error: template argument required for ‘struct map_extractor’ I've looked at the preprocessed file and there is something that disturbs me - templates of set_extractor and map_extractor are getting "changed". Comparing preprocessed file against source from boost/unordered/detail/extract_key.hpp I see 1) set_extractor a) original code template <class ValueType> struct set_extractor { typedef ValueType value_type; typedef ValueType key_type; b) preprocessed output struct set_extractor { template <class ValueType> struct apply { typedef ValueType value_type; typedef ValueType key_type; 2) map_extractor a) original code template <class Key, class ValueType> struct map_extractor { typedef ValueType value_type; typedef BOOST_DEDUCED_TYPENAME boost::remove_const<Key>::type key_type; b) preprocessed output struct map_extractor { template <class ValueType> struct apply { typedef ValueType value_type; typedef typename remove_const<typename ValueType::first_type>::type key_type; As you can see, the set_exctractor and map_exctractor templates have lost template parameters declarations and some extra nested struct has been generated: template <class ValueType> struct apply Folks on #boost at IRC suggested it may be caused by MPL magic. I haven't noticed any such problem with GCC 4.4 on Linux with Boost 1.43 There has been similar issue reported, but the problem was ALLOC macro defined by RICE library, what rather is not my case: http://lists.boost.org/boost-users/2010/05/59340.php Does anyone have an idea what's happening? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

2 3

[CfP] 5th Annual BoostCon, Aspen (CO, USA), May 15-20, 2011
by Hartmut Kaiser 16 Oct '10

16 Oct '10

Please distribute. ------------------ 5TH ANNUAL BOOST CONFERENCE 2011 Aspen CO, USA, May 15 - 20, 2011, www.boostcon.com CALL FOR PARTICIPATION We invite you to submit session proposals to the 5th Annual Boost Conference: BoostCon 2011 (Aspen CO, USA, May 15 - 20, 2011). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2011 will present leading speakers from the whole C++ community. >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 the new C++ 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 three constituencies: Boost end-users, hard-core Boost library and tool developers, and academics focusing on researcher. The program fosters interaction and engagement within and across those 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 Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it changes life for users and library writers * 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 * Software development tools and their application to C++ and or Boost * 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 in 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 short-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=boostcon2011. 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 (but are not required) 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 proposals 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 website and will be available to attendees. For general information on the BoostCon 2011 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 boostcon2011(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 Proposal submissions due: December 10th, 2011. Proposals decisions sent (tentative program available): January 17th, 2011. Fully scheduled program available: February 7th, 2011. Session materials due: April 15th, 2011. 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

[Pointer Container] Modification of pointer containers to allow const elements
by Gerardo Hernández 16 Oct '10

16 Oct '10

The following code snippet: boost::ptr_vector<const int> v; v.push_back(new int); produces the following error message (Visual C++ 9, boost 1.44): boost\ptr_container\ptr_sequence_adapter.hpp(249) : error C2664: 'std::vector<_Ty,_Ax>::push_back' : cannot convert parameter 1 from 'const int *' to 'void *const &' The problem is that the underlying type of boost::ptr_vector<T> is always vector<void*>, no matter T is const. This prevents push_back() method from maintaining const-correctness. The rest of the pointer containers contain an equivalent problem and this has been a TODO for some time. According to Thorsten Ottosen (library author) ( https://svn.boost.org/trac/boost/ticket/3832 ): "The fix is basically just some meta-functions taking into account that T might be const, and if so, instantiate container<const void*> instead of container<void*>" To the vector problem, this means that the underlying type should be: vector<typename boost::mpl::if_<boost::is_const<T>, const void*, void*> > I have sucessfully applied this approach to the pointer containers that mimic STL counterparts (see attachment) and I guess it should work for the others. I need feedback on whether this is a completely correct approach and if so I would like to contribute a modification. Gerardo.

5 10

[optional] memory use for optional refs and ptrs
by Rutger ter Borg 15 Oct '10

15 Oct '10

Hello, I'm looking into boost::optional<> as a replacement for some of my code which has to deal with optional values. However, it seems that cases which are usually space-efficient optionals (e.g., ptrs in the form of a null-ptr) do not have template specializations. In other words, boost optional templates store a bool and the memory footprint of its template parameter, regardless of type. I.e., optional references and pointers take their space plus the space of an extra bool. Is there a reason for this? Thanks, Rutger

15 42

New Boostcon sessions uploaded
by Marshall Clow 14 Oct '10

14 Oct '10

Michael Caisse: Using Spirit V2: Qi and Karma http://blip.tv/dashboard/episode/4162161 Stephan T. Lavavej: Data Structure Visualizers in Visual Studio 2010 http://blip.tv/dashboard/episode/4162044 Matt Calabrese, Zachary Laine: Instantiations Must Go! http://blip.tv/dashboard/episode/4161957 Jeremy Siek: Generic Programming And the Boost Graph Library http://blip.tv/dashboard/episode/4161923 More to come (I'm shooting for one session every other day)..... -- Marshall

13 24

C++0x trailing return type
by Matt Calabrese 14 Oct '10

14 Oct '10

I'd like to introduce a macro to Boost.Config called BOOST_NO_TRAILING_RETURN_TYPE for checking if a compiler supports 0x trailing return types I.E. auto foo() -> void; Is there general agreement that this is an appropriate name for the macro? Now for a small rant -- in a recent thread, I talked about introducing a simple BOOST_AUTO_FUNCTION macro which I'll request review for shortly, as a way to simulate automatic return type deduction when writing functions and function templates. In experimenting with the macro, I have hit what I believe is either a bug in GCC or what I would consider a huge failing of C++0x trailing return types (someone please aid me in figuring this out). One of the main reasons why trailing return types are helpful is that the arguments to the function or function template you are writing are able to be refered to when forming the return type, however, when dealing with non-static member functions, it seems to me that you are not able to refer to "this" or non-static members. This greatly reduces the usefulness of trailing return types, as all of the reasons why you would want to refer to the parameters apply with the same rationale to why you would want to refer to members and "this". I've skimmed through the standard and see no explicit mention of or examples of using trailing return types in this manner. Perhaps someone here can help parse the standard-ese to clarify? I'd hope that you could refer to non-static members, but I see no evidence of that. One example of why this is frustrating in practice can be seen in the following hypothetical code for a Boost.Variant-style template with an "emplace" member-function that is intended to construct an object in-place similar to the emplace family of member functions of C++0x containers: http://codepaste.net/u5nfis Here, the trailing return type is used almost exclusively for extended SFINAE, though you often wish to refer to members in other cases as well where SFINAE isn't of any concern. The overall goal with the implementation of emplace being as such is to attempt to force substitution to fail if any of the following cases were true: if "Type" does not have a constructor taking the forwarded arguments if "Type" is not one of the types that is able to be stored in the template and possibly even something else I've missed (...which is a good thing...) Essentially we want substitution to fail if the instantiation of the body would fail, giving a very basic equivalent to low-level, syntax-only, automatic concept-checking. The benefit of this speaks for itself. Here, at least in my opinion, such code is very concise, very powerful, and surprisingly readable. Without such functionality of trailing return types we can only do marginally better than we've been doing for the past 10 years. So if someone could help me determine whether or not what I'm trying to do is standard I'd be grateful, and if such functionality is not standard, is it too late for it to be added? It seems to me that the benefits with respect to library development here are too great for a community like Boost to ignore, though I myself am not familiar enough with the standardization process to make an impact. Thanks. It appears this rant has overshadowed the original question, though please don't forget to respond. -- -Matt Calabrese

4 3

Schedule on www.boost.org
by Rene Eng 14 Oct '10

14 Oct '10

Hi all Following the release schedule on www.boost.org, preparations for the release 1.45 are already underway. But I have not read anything here on the mailing list yet. Could somebody please either confirm the intention to keep those release dates, or otherwise adjust the dates in the release schedule? Thank you very much in advance René Eng -- “Dubito ergo cogito; cogito ergo sum. (I doubt, therefore I think; I think therefore I am)” René Descartes

2 1