- Boost-announce - lists.preview.boost.org

Boost.Align review begins today
by Ahmed Charles 12 Apr '14

12 Apr '14

Hi all, The review of Boost.Align by Glen Fernandes commences today, Friday, 11 April, and concludes Sunday, 20 April. Boost.Align provides: 1. Function align() to align a pointer, for implementations which do not provide C++11's std::align(). 2. Functions aligned_alloc() and aligned_free() for dynamic allocation with specified alignment. { For use in place of ::operator new() and ::operator delete(). } 3. Class template aligned_allocator as an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of std::allocator. } 4. Class template aligned_allocator_adaptor to turn any existing allocator into an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of any existing allocator type. } 5. Function is_aligned() to test the alignment of a pointer. Rationale: C++11 added the ability to specify increased alignment (over-alignment) for class types. Unfortunately, ::operator new allocation functions, new expressions, and the default allocator, std::allocator, do not support dynamic memory allocation of over-aligned data. Notes: This library also meets needs in existing Boost libraries. - Boost.Smart_Ptr has its own implementation of align(). - Boost.Interprocess and Boost.Log each have their own implementation of aligned_alloc() and aligned_free(). Source: doc: http://glenfe.github.io/align git: http://github.com/glenfe/align zip: http://github.com/glenfe/align/archive/master.zip Please always state in your review whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Ahmed Charles Review Manager

1 0

Boost.Align review announcement
by Ahmed Charles 28 Mar '14

28 Mar '14

Hi everyone, The review of Boost.Align by Glen Fernandes is scheduled from Friday, April 11th to April 20th. Source: http://github.com/glenfe/align Documentation: http://glenfe.github.io/align Description: This library provides function align for implementations which do not have the C++11 standard library align function available.It provides allocation functions aligned_alloc and aligned_free as their functionality is not yet available in the C++ standard library. They use platform specific functions, if available, or use standard library functions in conjunction with align.It provides C++ allocators, class templates aligned_allocator and aligned_allocator_adaptor, which respect alignment. The first uses aligned_alloc and aligned_free while the second uses the allocator in conjunction with align.It also provides function is_aligned to test the alignment of a pointer. Rationale: C++11 added the ability to specify increased alignment (over-alignment) for class types. Unfortunately, ::operator new allocation functions, new expressions, and the default allocator, std::allocator, do not support dynamic memory allocation of over-aligned data. The aligned_alloc function can be used in place of ::operator new to specify the alignment of the memory allocated.The aligned_allocator class template can be used in place of std::allocator as an alignment-aware default allocator.The aligned_allocator_adaptor class template can be used to adapt any allocator into an alignment-aware allocator. Notes: The functionality provided by this library addresses needs in existing Boost libraries as well. Boost.SmartPtr has its own implementation of align, and Boost.Log and Boost.Interprocess have their own implementations of aligned_alloc and aligned_free. Boost List Discussion: http://lists.boost.org/Archives/boost/2014/02/211723.php Review Manager: Ahmed Charles

1 0

[GSoC 14] Request community to rank proposals
by Niall Douglas 24 Mar '14

24 Mar '14

Dear Boost Community, The Google Summer of Code 2014 proposals for Boost are in, and we would deeply appreciate the community's help in ranking the proposals according to merit before the 1st of April. To vote, the process is easy: 1. Go to this page https://www.google-melange.com/gsoc/homepage/google/gsoc2014 and click the "Log in" button under Mentors and Administrators. 2. Now click "Create Profile" on the same page. Note that even if you registered last year, you must register again in 2014. Fill in the form. Note that after submitting it drops you at "Edit Profile", which is confusing. 3. Click "My Dashboard", then "Connect with organisations". 4. Choose "Boost C++ Libraries". 5. In the message box, write this: "I am a member of the Boost community and the email(s) I normally post to boost mailing lists with is <email>" filling in the email address(es) you normally use to post to boost mailing lists. This lets us verify that you are indeed a long standing member of the Boost community. 6. Once we approve your request, you will get an email with the subject "Welcome as organisation member". You can now return to the Dashboard on the GSoC website where there will be a new item "Proposals". 7. Work your way through as many of the 42 proposals as you can. You can score them using the stars at the bottom of each proposal page, taking care to read any comments by the mentors and students if present. PLEASE try to rank some of the lowest scored proposals, every year we get a lot of people who only rank the top five and don't bother with the rest. Try to score on the basis of (i) proposal quality and your best estimate of the student's capability (ii) if the student came early to the mailing lists to ask for help writing the proposal (the mentors who helped them with their proposals have usually indicated this in the private comments) (iii) usefulness/appropriateness of the feature or work being proposed. Remember a good GSoC is more about getting promising new engineers into Boost and C++ than necessarily getting code to pass Boost peer review in a single summer. 8. Optional: If a proposal looks especially great to you and you feel able to mentor a student this year, please slide the "wish to mentor" button. Just because a proposal already has willing mentors does NOT mean you should not add yourself - we have at least two mentors with many attached very highly ranked proposals and we really don't want to have to reject an outstanding proposal just because we can't find the mentors for it as no mentor can realistically mentor more than two projects simultaneously. As you know, Google Summer of Code is usually worth $35,000 - $50,000 to Boost each year, and a successful GSoC raises our visibility and reputation in the wider open source community. Our thanks to you in advance for taking the time to vote. Niall Douglas Boris Schäling --- Boost C++ Libraries Google Summer of Code 2014 admin https://svn.boost.org/trac/boost/wiki/SoC2014

1 0

NT² 3.0 and Boost.SIMD - Stable release
by Joel Falcou 15 Feb '14

15 Feb '14

The first stable release of the 3.x series of MetaScale’s open-source software is available: NT² 3.0. It also includes its spin-off project, Boost.SIMD (not yet a Boost library). Many Issues have been closed since last beta. The main focus of this release cycle was to fix performances issues and to stabilize some parts of the API. Next step will be to separate NT2 and Boost.SIMD into separate repositories, thus making one more step toward Boost.SIMD submission into review. [ http://www.metascale.org/nt%C2%B2-3-0-and-boost-simd ] *Changes & Bug Fixes:* - Major performance improvements in both libraries - Added experimental support for the HPX runtime for parallelization on shared memory systems - Optimizations of many elemental functions, in particuler log/ex, frexp/ldexp and cbrt - More advanced shuffle pattern recognition for SIMD - Fixed issues with Visual Studio 2013 - More functions are force-inlined to ensure good performance - New functions for conversion between types and mixing of vectors of different sizes - Demo applications usable as benchmarks - Better handling of errors when an unsupported function is called - New API for custom memory allocators Full changelog is available at https://github.com/MetaScale/nt2/releases/tag/3.0.0. *How to get it ?* - Source and binary packages can be downloaded here: http://nt2.metascale.org/downloads - The release is also available on Github : https://github.com/MetaScale/nt2/releases - The main master branch is still under development : https://github.com/MetaScale/nt2

1 0

Attn: We need GSoC 2014 mentors for Boost!
by Niall Douglas 08 Feb '14

08 Feb '14

Dear Boost community, We are now just five days away from the closing date for Google Summer of Code 2014 registration. Last year's GSoC was a huge success, with Google funding work on Boost to the tune of $35,000 and paying over $8,000 in costs for three representatives of Boost to attend the GSoC mentor's summit at Google HQ. As part of filling in our application for 2014, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2014. We do NOT want a repeat of 2012 when our application was rejected due to an insufficiently long list of prospective mentors and projects! At the time of writing, we have just *eight* prospective mentors, and we need more to be sure of being approved by Google! Therefore, if you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list at https://svn.boost.org/trac/boost/wiki/SoC2014. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org. Thank you in advance for your time. Niall Douglas (Boost Google Summer of Code admin) Boris Schäling (Boost Google Summer of Code backup admin)

1 0

Fwd: [boost] Boost.Fiber review January 6-15
by Nat Goodspeed 23 Jan '14

23 Jan '14

SUMMARY The review of the proposed Boost.Fiber library ended on January 15, 2014. The verdict is: not in its present form. The lively discussions during the course of the review indicate considerable interest in this library, however, and every submitted review can be read as: perhaps, if certain changes are made. This produced a long list of suggestions, which constitutes the bulk of this report. On behalf of the Boost community, I would like to commend Oliver Kowalke for the work he has put into the Fiber library so far. I encourage him to continue to evolve this library and to bring it back for a mini-review. Rather than considering the subject library as a whole, a Boost mini-review zooms in on particular issues. That seems an appropriate tool to use for further evaluation of the Fiber library -- always subject, of course, to the approval of the Review Wizards. I received seven formal votes, abbreviated here: Niall Douglas: YES, IF Eugene Yakubovich: YES, AND Antony Polukhin: YES, IF Vicente J. Botet Escriba: NO, UNTIL Agustín K-ballo Bergé: NO, IN CURRENT STATE Hartmut Kaiser: NO, IN CURRENT FORM Thomas Heller: NO, IN CURRENT FORM I thank each of these reviewers, and indeed everyone who investigated the Fiber library and participated in the discussions. If you feel that I have misrepresented your position, or have omitted or garbled an important point, please respond: the archived mail thread should accurately reflect the will of the community, even if this message does not. >From the long list of suggestions, a few key themes emerged. PERFORMANCE Many respondents requested performance tests (specifics below). There were a number of suggestions about possible performance pitfalls in the current implementation, such as use of STL containers (with consequent heap allocations) and locks for thread safety. Several people suggested implementing performance tests *before* starting any such optimizations, which seems like sensible advice. Niall Douglas pointed out that picking some fixed number of fibers is less interesting than showing how resource consumption rises with the number of fibers: "I think it isn't unreasonable for a library to enter Boost if it has good performance *scaling* to load (e.g. O(log N)), even if performance in the absolute or comparative-to-near-alternatives sense is not great. "Absolute performance can always be incrementally improved later, whereas poor performance scaling to load usually means the design is wrong and you're going to need a whole new library with new API. "This is why I really wanted to see performance scaling graphs. If they show O(N log N) or worse, then the design is deeply flawed and the library must not enter Boost. Until we have such a graph, we can't know as there is no substitute for empirical testing." Given the truth of that last observation, I have recast certain suggested optimizations as requests for measured performance cost. Performance requests include: - empty function (create, schedule, execute, delete one fiber) - same with one yield - overhead of using a future object - tests as described in [1]; such tests should allow comparing with TBB, qthreads, openmp, HPX - construct and join a single fiber vs. construct and join a single thread (empty function) - construct and join several fibers vs. construct and join several threads (empty function) - construct and detach a single fiber vs. construct and detach a single thread (empty function) - cost of STL containers (std::vector, std::map, std::deque) - cost of fiber interruption support (same as next bullet?) - cost of thread safety: intra-thread fibers vs. inter-thread fibers - cost of round_robin_ws vs. round_robin scheduler - cost of building on Coroutine vs. building on Context Once Fiber performance tests are available, I trust the community will assist Oliver in running them on systems otherwise unavailable to him. There was some disagreement on whether it is essential for the Fiber library to attain a certain level of performance before it should be accepted. Respondents fall into two broad camps. Some see fibers as lightweight threads (without the overhead of kernel context switching). They assert that since the API is that of std::thread, the only reason to accept a separate library would be astounding performance. They note that on some hardware it is already plausible to run hundreds of thousands of concurrent std::threads. Others see fibers as a tool for organizing code based around asynchronous operations (rather than chains of callbacks). They assert that for such purposes, eliminating the kernel from context switching is sufficient performance guarantee. I myself maintain that cooperative context switching provides important functionality you cannot reasonably get from std::thread. The Fiber library attempts to address both use cases. (It was suggested that if its primary target were code organization, perhaps it should be renamed something other than "Fiber.") In any case, the community clearly wants to see Fiber performance data. Some requested CPU cycles to eliminate clock speed differences, also memory consumption. ARMv7 data was requested for "extra bonus points." DOCUMENTATION Many respondents requested additional documentation, or clarifications. Requests include: - Rationale page explaining what's there, what's not and why. Explain distinction between Coroutine library and Fiber library. If certain Fiber functionality is intended to support yet another library (rather than being complete in itself), call out what would need to be added. - A section on how to install and run the tests and examples. The need to embed in a Boost tree is implied but not stated. Mention the need to build the library and link with it. - Explain synchronization between fibers on different threads. Must the code take more care with this than with synchronizing fibers on the same thread? - Clarify that an exception raised by a fiber function calls std::terminate(), as with std::thread, rather than being consumed. - More clearly explain migrating a fiber from one scheduler to another. - Document async() in a way compatible with the C++ standard. - Clarify thread-local effect of set_scheduling_algorithm(). There was a request to put this function in a this_thread nested namespace to further clarify. - Move algorithm class documentation to "Extension" or "Customization" section. Clarify that it's not part of the baseline library functionality, but a customization point. - Document fiber::id. - Better document promise/future for void and R& (per C++ standard). - Document thread safety of each support class (or method, if it varies by method). - Document complexity guarantees per API. - Document exception safety per API. - Document supported architectures (perhaps link to Coroutine library's list); state minimum compiler versions. - Document the get/set overloads of thread_affinity() and priority() separately. Perhaps rename setters to set_thread_affinity() and set_priority(). - Explain how portable is fiber priority, if it's specific to a scheduler. What does priority mean when you migrate a fiber from one thread (one scheduler instance) to another? - Document the library's ASIO support. Link to Coroutine's ASIO yield functionality; ensure that ASIO yield is adequately explained. In particular, distinguish it from this_fiber::yield. - Better explain (and/or comment) publish-subscribe example, also other existing examples. In addition to the documentation requests above, there were requests for additional examples: - Simple example of ASIO callback implementation vs. the same logic using Fiber's ASIO support, a la [4]. - Example of a fiber pool. - Example of an arbitrary thread B filling a future on which a fiber in thread A is waiting. - Example of an arbitrary thread B posting to an asio::io_service running fibers in thread A. - Either defend fibers::condition_variable from spurious wakeups in existing examples, OR document the stronger condition_variable guarantee. - Example of M:N threading with ASIO. That might involve either one io_service per CPU, with fiber migration; or a single io_service with run() calls from each CPU, grouping fibers for each CPU into strands. - Example of one thread with many fibers making service requests on a pool of worker threads performing blocking calls. - Example of using thread_specific_ptr to manage lifespan of user-specified scheduler. - Example of the owner of a fiber changing the fiber's thread affinity vs. the fiber itself. When would you use each tactic? - Load example programs into an Examples appendix so that Google searches can turn up library documentation. LIBRARY API - Four people overtly approved the close parallel with std::thread and its support classes. - Allocating a default scheduler object, rather than specifying a default template param, was praised. - Three people called out the set difference between Boost.Thread features and Fiber (e.g. future::get_exception_ptr()). One wants these implemented immediately; another says they can be added later; the third simply requests that they be documented, with rationale. - Two people frowned on introducing operator bool methods not found in std::thread or Boost.Thread. - C++11 support was mentioned, notably Boost macros such as BOOST_RV_REF and BOOST_EXPLICIT_OPERATOR_BOOL. Also mentioned were: C++11 idioms; C++11 std::thread patterns; move construction; initializer lists; rvalue this overloads; deleting operators. - The fiber constructor and async() should accept a move-only callable. - At least for a C++11 compiler, fiber constructor and async() should accept variadic parameters. These should support move-only types, like Boost.Thread. C++03 support for variadic parameters would be nice, but is less important. - Every API involving time point or duration should accept arbitrary clock types, immediately converting to a canonical duration type for internal use. - Queues should support value_pop() returning item by value. This supports an item type without a default constructor. - Nested scoped_lock typedef has been deprecated in thread library. Remove in Fiber library. - Align the return type of shared_future::get() with the standard. In general, ensure that parameter types and return types are aligned with the standard. - A couple of people were bothered by the use of types in the detail namespace as parameters or return values in the algorithm API. (I note, however, that extending e.g. Boost.Range can involve touching its detail namespace. A customization point for a library may be a bit of a gray area.) - There was a suggestion to rename algorithm to scheduler. In that case, presumably set_scheduling_algorithm() could be renamed set_scheduler(). - There was a request to rename round_robin_ws to round_robin_work_stealing. - A couple of people consider the algorithm API too monolithic, pointing to redundancies in the round_robin, round_robin_ws and asio round_robin implementations. They suggested teasing out distinct classes, so that (for instance) a user-coded scheduler might be able to override a single method to respect fiber priority. In fact Eugene Yakubovich offered to experiment with refactoring the algorithm class this way. - There was a request for set_scheduling_algorithm() to return the previous pointer. (It might be useful for the requester to explain the anticipated use case. An earlier iteration of set_scheduling_algorithm() did return the previous pointer; Oliver intentionally changed that behavior.) - fiber_group got one thumbs-up and two thumbs-down. Options: retain; improve to use move support rather than fiber*; discard. There is an opportunity to improve on thread_group; naturally there is risk in diverging from thread_group. - Request deferred futures for lazy evaluation. - There was a suggestion to introduce a global object to coordinate thread-specific fiber schedulers, in the hope that the global object could perform all relevant locking and the thread-specific fiber schedulers could themselves be thread-unsafe. - There was a request to unify steal_from() and migrate_to() into a single method. I infer that this is predicated on the previous suggestion. - Request future::then() et al, per [5]. (Someone please clarify the present status of N3784?) - Request enriched barrier support per [6] and [7]. (Someone please clarify the present status of N3817?) - There are two fiber properties specific to particular schedulers: thread_affinity (used only by round_robin_ws) and priority (as yet unused by any scheduler). What if a user-coded scheduler requires a fiber property that does not yet exist? Is there a general approach that could subsume the present support for thread_affinity and priority, in fiber and this_fiber? Could the initial values for such properties be passed as part of the fiber constructor's attributes parameter? - One use case was surfaced that may engage the previous bullet: the desire to associate a given fiber with any of a group of threads, such as the set of threads local to a NUMA domain or physical CPU. IMPLEMENTATION - Replace std::auto_ptr with boost::scoped_ptr. The former produces deprecation warnings on GCC. - Reduce redundancy between try_lock() and lock(). - boost::fibers::asio::detail::yield_handler::operator()() calls algorithm::spawn() before algorithm::run(). Does this allow the scheduler to choose the next fiber to run, e.g. a user-coded scheduler that respects fiber priority? - Add memory transaction support to spinlock a la [8]. - Intel TSX lock avoidance would be nice. LINKS [1] https://github.com/STEllAR-GROUP/hpx/tree/master/tests/performance [2] http://stellar.cct.lsu.edu/pubs/isc2012.pdf [3] http://stellar.cct.lsu.edu/pubs/scala13.pdf [4] https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AFIO_Do… [5] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3784.pdf [6] http://www.boost.org/doc/libs/1_55_0/doc/html/thread/synchronization.html#t… [7] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3817.html#barrier_… [8] https://github.com/BoostGSoC/boost.afio/blob/master/boost/afio/detail/ Nat Goodspeed Boost.Fiber Review Manager ________________________________

1 0

Boost.Fiber review January 6-15
by Nat Goodspeed 06 Jan '14

06 Jan '14

Hi all, The review of Boost.Fiber by Oliver Kowalke begins today, Monday January 6th, and closes Wednesday January 15th. ----------------------------------------------------- About the library: Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack. A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiber internally uses coroutines from Boost.Coroutine; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time. docs: http://olk.github.io/libs/fiber/doc/html/ git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip The documentation has been moved to another site; see the link above. If you have already downloaded the source, please refresh it; Oliver has added some new material. --------------------------------------------------- Please always state in your review whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Nat Goodspeed Boost.Fiber Review Manager ________________________________

1 0

Fwd: Forthcoming Boost.Fiber review
by Nat Goodspeed 18 Dec '13

18 Dec '13

Hi all, The review of Boost.Fiber by Oliver Kowalke is scheduled from Monday, January 6th to January 12th. ----------------------------------------------------- About the library: Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack. A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiberinternally uses coroutines from Boost.Coroutine <http://ok73.funpic.de/boost/libs/coroutine/index.html>; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time. docs: http://ok73.funpic.de/boost/libs/fiber/doc/html/index.html<http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/> git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip<http://ok73.ok.funpic.de/boost.coroutine.zip> --------------------------------------------------- Naturally, you need not wait until the review formally opens to start reviewing the Fiber library. Please always state in your review whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Nat Goodspeed Boost.Fiber Review Manager ------------------------------

1 0

C++Now 2014: Call for Submissions, Updated deadlines
by Hartmut Kaiser 09 Dec '13

09 Dec '13

Updated submission dates! Please see below! ============================================== C++ Now Conference 2014 Aspen CO, USA, May 12-17, 2014, www.cppnow.org ============================================== For the full announcement online, please see here: http://cppnow.org/2013/10/21/2014-call-for-submissions/ Call for Submissions -------------------- We invite you to submit session proposals to the 3rd annual C++Now Conference (Aspen CO, USA, May 12-17, 2014). Building upon the resounding success of C++Now 2013 and five years of BoostCon, C++Now 2014 will present leading speakers from the whole C++ community. The C++Now Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. At C++Now 2014 we would like to focus on the now established C++11 standard and the new, upcoming C++14 and how those standards are and will shape C++'s future. However, by no means is this intended to restrict the topics of proposals we hope to see. Any other topic related to C++ as outlined below is perfectly fine for submission. Important dates --------------- New proposal submissions due: December 22th, 2013. Proposals decisions sent (tentative program available): February 15th, 2014. Fully scheduled program available: February 28th, 2014. Best Presentation Awards ------------------------ We know how much effort it takes to prepare talks for our conference. For this reason we will award the best The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now website for that year and a plaque containing all the C++Now conference information. Session topics -------------- Topics of interest include, but are not restricted to, the following: * C++11/14 and how it changes life for users and library writers * General tutorial sessions on C++11/14, the C++11/14 Standards library, and one or more Boost libraries * Parallelism in the new C++11/14 standard * Parallel, distributed and GPGPU topics relating to C++ * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * 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 C++ users and developers Interactive and collaborative sessions are encouraged, as this is 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 C++11 or C++14, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 or C++14 and 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 skills relevant to C++11 or C++14 and Boost. 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 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. * A photo of about 150 x 150 * Your public contact information (twitter handle, blog, website, google plus, etc.) * Your contact information (will not be made public). Submission details ------------------ All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2014. 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 C++ Now website and will be available to attendees. For general information on the C++ Now 2014 paper submission or the scope of technical papers solicited; please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2014(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 C++ Now. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Joel Falcou, email: joel.falcou(a)lri.fr (Program Committee Co-Chair) Jon Kalb, , email: jon(a)kalbweb.com (Conference Chair) Dave Abrahams, dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
by Niall Douglas 24 Nov '13

24 Nov '13

Please let me know as soon as possible any errata, missing credits etc. Niall Boost Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013 This report is the first edition, dated Sunday 24th November 2013. The review manager was Niall Douglas http://www.nedprod.com/. Source: https://github.com/apolukhin/type_index/zipball/master Documentation: http://apolukhin.github.com/type_index/index.html Peer review discussion detail: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-library… My thanks to the Boost members whose peer review makes up this report: Robert Ramey, Vicente J. Botet Escriba, Gavin Lambert, Andrey Semashev, Steven Watanabe, pfultz2, Mathieu Champlon, Joël Lamotte Klaim, Rob Stewart, Jan Herrmann, Tony Van Eerd. Contents: · Summary of consensus from peer review ......................................................................................................... 1 · My recommendation to the library author and the Review Wizards ................................................................ 3 Summary of consensus from peer review: The consensus feedback was to accept TypeIndex after substantial modifications. There were two recommendations of rejection due to how substantial such modifications would need to be (i.e. a request for a second round of peer review with a new implementation). Note that my personal opinion based on post-review reflection is written in [square bracketed italics]. · Many seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical compile-time effects. This implied that missing member function APIs, or other compile time errors for missing or incomplete functionality, would be okay but if name() returns some const char *, then any const char * so long as it meets the C++ standard is okay. [I think there are three use cases for a type_info like substitute: (i) as a lightest possible weight, non-RTTI requiring minimal type_info which can have any API it likes and ought to not be directly substitutable for std::type_info or std::type_index (ii) as a compile-time substitute for std::type_info in that it will compile without third party code modification, but may not produce reliable code due to not returning exactly the same values as std::type_info (iii) as a runtime substitute for std::type_info in that it will require code to be “ported” to it due to having a breaking API, but thereafter produces reliable code. I’ll be very blunt in saying that (ii) is a bad idea in my opinion, and (iii) is valuable but out of scope enhancement which could be added as a separate class after peer review. In my opinion, (i) is where we ought to focus, and I would recommend that the lightest possible weight type_info replacement be deliberately compile-time incompatible with std::type_info (where output is not identical to std::type_info) to force porting code to it so authors are not lazy.] · A large minority seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical run-time outcomes. Most specifically, this would mean that member functions e.g. name() would return exactly what std::type_info’s name() does, even if for example name() returns a std::string instead of a const char * as would be necessary in pre-C++11 compilers. [This is really use case (iii) in the previous item.] · It was mentioned that it should be possible to optionally specialise std::hash<> for type_info for optional seamless use in hash taking containers. · Some felt that implementation-specific std::type_info quirks ought to be replicated. Others felt they should not, and a portable interface which works identically on all platforms is preferred. [This is really use case (iii) in the previous item.] · boost::type_info is currently initialised via a static cast from a std::type_info when RTTI is available. This is undefined behaviour, and some felt this to be a showstopper. I (Niall Douglas) looked into this more deeply due to its seriousness, and found that because most STL implementations define std::type_info with a virtual function table, the undefined behaviour static cast would cause dynamic_cast on a boost::type_info instance to misoperate. [I believe the RTTI induced misoperation to indeed be a showstopper, and that this use of undefined behaviour to reduce code bloat is an unsafe optimisation. A much lighter weight non-direct-substitute for std::type_info ought to be as code bloat parsimonious as is possible, while its lack of non-explicit interoperation ability with std::type_info ought to allow avoidance of needing any UB tricks.] · Some felt that any use of implied boost::type_info ought to be explicitly written as boost::type_info instead of relying on namespace lookup, as the name similarity to std::type_info may introduce confusion. [I agree] · It was mentioned that some function-local static data members are initialised in a thread unsafe way. [For information I have to hand a very lightweight BOOST_BEGIN_MEMORY_TRANSACTION() implementation ideal for this purpose. We could submit it to Boost.Detail and then everyone could use it?] · Magic macros such as __PRETTY_FUNCTION__ ought to not be referenced outside of a function as they don’t technically exist there. Checks for their existence ought to be within a function. · It was requested that a boost::type_id<> which takes some unknown variable instance as a parameter and therefore allows the compiler to deduce the type of the variable as the boost::type_index<T> type would be valuable. · A mechanism for programming compile-time logic with class inheritance trees such that inheritance can be determined at compile-time with RTTI disabled was requested. My recommendation to the library author and the Review Wizards: · In my opinion Antony ought to make TypeIndex v3 quite literally a very lightweight container of some unknown, but known to be uniquely identifying for some type, static const char * string. I think its class type and its list of member functions ought to be deliberately compile-time incompatible with std::type_info to force authors to upgrade their code. A conversion member function ought to be able to synthesise a corresponding std::type_info using typeid() from some boost::type_index<T>, but that’s about it. I would even, personally speaking, go so far as to only provide a boost::type_index and no corresponding boost::type_info, especially if the boost::type_id<T>() function can return a const boost::type_index<T>& and therefore can be used as a static const lref, or copy constructed from it etc. A suggested name() member function replacement which correctly breaks out the multiple confounding uses of std::type_info::name() into each of their three use cases (and which intentionally causes any use of name() to fail to compile) might be: Text Box: /*! Returns a static const char string of unknown format uniquelyidentifying this type.The only guarantee is that this string will beunique to the type within this process lifetime. */const char *unique_name() const noexcept;/*! Returns a representation of this type suitable for printing.This call may take some time as its storage may not be cached. */std::string pretty_name() const;class enum mangling{Native, //!< Whatever the native mangling used by this toolset isMSVC, //!< The Microsoft C++ mangling formatItanium //!< The Itanium C++ mangling format};/*! Returns the mangled form of the string representation of the type.After the calculation the value is cached statically such that the c_str()function can be used to convert the returned string to a const char *format identical to what may be returned by std::type_info::name() (orraw_name() on MSVC).This function may throw an exception if it does notsupport mangled type string calculation, including when mangling=Native onsome Bear in mind that user code can always subclass boost::type_index and add their own name() implementation based on one or more of the above new member functions. · In other words, here I think “less is more” in every way you look at it. I think a slimmer less heavy TypeIndex would be a superior solution. · I request the Review Wizards to allow Antony some time to make the changes to produce a v3 of the library, and then to allow TypeIndex v3 a Fast Track Review of five days to ensure the Boost community is happy and that its feedback has been incorporated. It was asked during peer review that such a five day period please include a weekend. I would be happy to serve as review manager again if requested. Niall Douglas Waterloo, Canada, November 2013

1 0