Home » Blog » Categories »

C++ User Group Meetings in May

By Meeting C++ | May 4, 2015 03:54 AM | Tags: community

The monthly overview on the current user group meetings:

C++ User Group Meetings in May

by Jens Weller

From the article:

    6.5 C++ UG Saint Louis - DD Part 5 - "Atomic" weapons OR ??
    6.5 C++ UG Munich - What is new in VS2015 for C++ Developers
    6.5 C++ UG Saint Louis - "Atomic weapons" part II
    6.5 C++ UG Austin - Charming Python with C++
    7.5 C++ UG NRW/Aachen - C++ User Gruppe (Mai)
    7.5 C++ UG Dresden - Coding Dojo
    11.5 C++ UG Zentralschweiz - Compile-time computation in C++14" mit Prof. Peter Sommerlad
    13.5 C++ UG Utah - Test-Driven Development in C++
    13.5 C++ UG San Francisco/ Bay area - Presentation and Q&A
    15.5 C++ UG Taipei - monthly meetup
    16.5 C++ UG Pune, India - Mastering C++14
    18.5 C++ UG Austin - North Austin Monthly C/C++ Pub Social
    20.5 C++ UG Düsseldorf - Cooking with C++
    20.5 C++ UG Arhus - Kickoff Meeting
    20.5 C++ UG Northwest/Seattle - STL Concepts and Ranges
    21.5 C++ UG Bristol - Lightning Talks
    27.5 C++ UG San Francisco/ Bay area - Workshop and Discussion Group
    27.5 C++ UG Hamburg - C++ Expression Templates
    27.5 C++ UG Udine (Italy)
    28.5 C++ UG Rhein-Neckar - (C++) build system olympics.

N4494: Multidimensional bounds, offset and array_view, rev. 6 -- Łukasz Mendakiewicz, Herb Sutter

By Blog Staff | May 2, 2015 03:50 PM | Tags: None

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4494

Date: 2015-05-01

Multidimensional bounds, offset and array_view, revision 6

by Łukasz Mendakiewicz and Herb Sutter

Excerpt:

Revision 6 (N4494) incorporates the changes requested by LWG in Cologne meeting, marked as deletions and insertions.

The following suggestions were implemented fully:

  1. Rephrased coord.general avoid references to mathematical entites.
  2. Renamed index to offset.
  3. Changed int Rank template parameter to size_t Rank throughout the document.
  4. Made offset, bounds and bounds_iterator binary operators (apart from @= forms) free functions.
  5. Replaced term "component" with "element" when referring to the individual constituents of offset or bounds.
  6. In coord.bounds.require replaced prose with an equivalent mathematical expression.
  7. In coord.bounds.iterator and coord.bounds.iterator.require removed the requirement on bounds_iterator to represent a random access iterator, replacing with "as-if" phrasing.
  8. In the description of bounds_iterator& operator++() replaced the code snippet with equivalent prose.
  9. In views.general changed the font back to non-monospace.
  10. Removed views.require, duplicating it as arrayview.require and stridedarrayview.require.
  11. Removed redundant assignment operators on array_view and strided_array_view.
  12. Employed "exposition only" data members is the descriptions of array_view and strided_array_view semantics.
  13. Rephrased the first paragraph in arrayview.cons to avoid ambiguity in binding of the token "type".
  14. In constexpr array_view(Viewable&& vw) rephrased the third bullet point.
The following suggestion was implemented partially:
  1. Instead of the array_view(ArrayType& arr) constructor being completely removed, it has been constrained to 1-D case as the Committee indicated that such case does not exhibit the undefined behavior. We believe that the request to remove it completely was a misstatment.

The following suggestion was not implemented:

  1. The semantics of the proposed types were not extended to allow rank-0 cases. We feel that we lack sufficient practical experience in using such cases and we are afraid of some contention points when it comes to defining their detailed semantics. We observe that such an extension can be introduced in future without conflicting with the proposal in the current form.

Bringing Clang to Windows -- Raman Sharma

By Blog Staff | May 2, 2015 09:55 AM | Tags: None

Also announced this week:

Bringing Clang to Windows

by Raman Sharma

From the article:

What if you could use a single compiler for your cross-platform code irrespective of what platform you target? ...

This is now possible with the work we have done. What this enables is a scenario in which you compile ... (2) using Clang and ... the Visual C++ back-end (We call it C2).  All of this while still enjoying the rich end-to-end developer experience within Visual Studio.

CppCon 2014 Lock-Free Programming (or, Juggling Razor Blades), Part I--Herb Sutter

By Adrien Hamelin | May 1, 2015 07:59 AM | Tags: performance efficiency

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Lock-Free Programming (or, Juggling Razor Blades), Part I

by Herb Sutter

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Example-driven talk on how to design and write lock-free algorithms and data structures using C++ atomic -- something that can look deceptively simple, but contains very deep topics. (Important note: This is not the same as my "atomic Weapons" talk; that talk was about the "what they are and why" of the C++ memory model and atomics, and did not cover how to actually use atomics to implement highly concurrent algorithms and data structures.)

Stroustrup: Thoughts on C++17 -- An Interview -- Sergio De Simone, InfoQ

By Blog Staff | Apr 30, 2015 08:49 PM | Tags: None

Yesterday, Bjarne Stroustrup posted a draft note of his thoughts about the next C++ standard currently expect in 2017. In the following interview, Stroustrup answers further questions about his note:

Stroustrup: Thoughts on C++17 -- An Interview

by Sergio De Simone, InfoQ

From the article:

... Look inside most critical systems and gadgets and you’ll find some C++ inside. That, and being able to help science in a small way, through its software systems, motivates me. C++ is a tool meant to be used for building important artifacts.

Template Code Bloat Revisited -- Jason Turner

By Jason Turner | Apr 30, 2015 11:26 AM | Tags: performance

Jason Turner discusses in his recent article the size of instantiated template code.

Template Code Bloat Revisited Smaller Makeshared

by Jason Turner

From the article:

Back in 2008 I wrote an article on template code bloat. In that article I concluded that the use of templates does not necessarily cause your binary code to bloat and may actually result in smaller code!

However, after spending the last few months optimizing and evaluating ChaiScript I've learned that the misuse of templates, particularly when inheritance is involved, can have a huge impact on code size.

Serializing access to Streams -- Marco Foco

By Marco Arena | Apr 30, 2015 12:48 AM | Tags: intermediate concurrency

A new blog post containing runnable code from the Italian C++ Community:

Serializing access to Streams

by Marco Foco

From the article:

Two or more threads were writing to cout using the form:

cout << someData << "some string" << someObject << endl;

And one of the problems was that data sent from one thread often interrupted another thread, so the output was always messed up. [...] I started designing a solution by giving myself some guidelines, here listed in order of importance...

N4487: Constexpr Lambda -- Faisal Vali, Ville Voutilainen, Gabriel Dos Reis

By Blog Staff | Apr 29, 2015 09:10 AM | Tags: None

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4487

Date: 2015-04-28

Constexpr Lambda

by Faisal Vali, Ville Voutilainen, Gabriel Dos Reis

Excerpt:

This proposal suggests allowing lambda-expressions in constant expressions, removing an existing restriction. The authors propose that certain lambda-expressions and operations on certain closure objects be allowed to appear within constant expressions. In doing so, we also propose that a closure type be considered a literal type if the type of each of its data-members is a literal type; and, that if the constexpr specifier is omitted within the lambda-declarator, that the generated function call operator be constexpr if it would satisfy the requirements of a constexpr function (similar to the constexpr inference that already occurs for implicitly defined constructors and the assignment operator functions).