- Boost - lists.boost.org

[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

[geometry]
by Paul Blampspied 13 Oct '10

13 Oct '10

I have been looking at the advance version of [boost][geometry]. I think it is very useful and very well worked out. I have a question. Does [geometry] support the idea of a frame of reference ? I believe not, but it may be that I have missed some way of achieving this. By reference frame I mean that some points are not directly comparable if they are in different frames of reference. This is distinct from different coordinate systems (I think). For example we could have two geographic coordinate systems, one referring to lat./long. on earth and another to Mars. the points on these two reference frames should not be comparable and should give a compile error. Can this be done in [geometry] ? More interestingly we could use two distinct reference frames for convenience, even though there is a known relation between them. It would be nice if point conversions between the two frames could be carried out (possibly implicitly). For example, I would like to do something like this: ShiftAndRotateTransform<EgocentricFrame, WorldFrame> EgoFrame_WorldFrame_Transform(10, 20, 90); //Shift by [10,20] and rotate 90deg. WorldFrame Test() { WorldFrame p1 = EgoFrame(0,0); EgocentricFrame p2 = WorldFrame(p1); return p2; //IMPORTANT - p2 is implicitly transformed to WorldFrame when returned from Test function. } I have managed to implement a very simple scheme which allows this to compile and work successfully, but I am not completely satisfied with my homebrew scheme. In particular, I am forced to declare the WorldFrame and EgoFrame classes and provide all the constructors for them. It is necessary to explicitly provide constructors for all the reference frames which can be converted - implying that this is known at the time the class is written. It is more flexible to use overloaded functions, because these can be added as required e.g. //The second argument is the output point which is modified. ChangeReferenceFrame(WorldFrame &p1, EgocentricFrame &p2); ChangeReferenceFrame(EgocentricFrame &p1, WorldFrame &p2); ChangeReferenceFrame(EgocentricFrame &p1, SomeNewFrameType &p2); However the syntactic convenience and possibility of implicit conversion is lost. I wonder if some sleight of template magic could allow the extensibility of the second approach with the usability of the first. The starting point would be to allow a class representing the transform between the two frames of reference to be declared. This should attempt to define as much of the machinery as possible. It seems to me that these facilities have no impact on the existing design of [geometry], but concern an extension to allow reference frames to be defined and related.

2 3

License question
by David Bellot 13 Oct '10

13 Oct '10

Hi guys, I'm working on a new library for some specific A.I and machine learning problems and I will release it as a Free Software of course. However, I wonder if you guys can enlighten me regarding license. This library will be template-based for some parts and compiled for other parts. I don't want to restrict users in what they're doing with the library, I mean they can use it for open-source or closed-source products. However, I want to decently protect my work and because it's template-based and can be used in commercial products, I don't want someone to do closed-source fork of it and all those kind of things... I selected to candidates: Boost and LGPL. So question: - do I have to use a Boost license or a LGPL license ? - and why not using GPL directly or is it too restrictive ? Thanks for your help, David (also boost::ublas maintainer when not doing statistics ;-) ) -- David Bellot, PhD david.bellot(a)gmail.com http://david.bellot.free.fr

5 5

Re: [boost] [function] function wrapping with no exception safety guarantee
by Dave Abrahams 12 Oct '10

12 Oct '10

On Tuesday, October 12, 2010, Emil Dotchevski <emil(a)revergestudios.com> wrote: > On Tue, Oct 12, 2010 at 4:04 PM, Daniel Walker > <daniel.j.walker(a)gmail.com> wrote: >> Formally, boost::function invocation has strong exception safety if >> invoking the target function has strong exception safety. > > This makes no sense at all. Invoking boost::function always has strong > exception safety guarantee. In no way it can make the state of the > boost::function object inconsistent, because it does not modify its > state. Sounds like you're talking about the basic guarantee here. > _____________________________________________ -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

Nightly tests failed with filesystem problem
by Belcourt, Kenneth 12 Oct '10

12 Oct '10

Hi, Tests failed last night for a problem with v3/src/operations.cpp. gcc.compile.c++ /scratch/boost/boost/bin.v2/libs/filesystem/build/ gcc-4.1.2/release/link-static/v3/src/operations.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall - DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/scratch/ boost/ boost" -c -o "/scratch/boost/boost/bin.v2/libs/filesystem/build/ gcc-4.1.2/release/link-static/v3/src/operations.o" "/scratch/boost/ boost/libs/filesystem/v3/src/operations.cpp" /scratch/boost/boost/libs/filesystem/v3/src/operations.cpp: In function ‘boost::filesystem3::file_type<unnamed>::query_file_type(const boost::filesystem3::path&, boost::system::error_code*)’: /scratch/boost/boost/libs/filesystem/v3/src/operations.cpp:467: error: no matching function for call to ‘symlink_status(const boost::filesystem3::path&, boost::system::error_code*&)’ /scratch/boost/boost/boost/filesystem/v3/operations.hpp:209: note: candidates are: boost::filesystem3::file_status boost::filesystem3::symlink_status(const boost::filesystem3::path&) /scratch/boost/boost/boost/filesystem/v3/operations.hpp:211: note: boost::filesystem3::file_status boost::filesystem3::symlink_status(const boost::filesystem3::path&, boost::system::error_code&) Can someone please take a look? Thanks. -- Noel

1 0