Reactive Equations - André Bergner
A new talk from Meeting C++ 2017:
Reactive Equations
by André Bergner
Outcome accepted into the Boost C++ Libraries
It continues to grow.
Outcome accepted into the Boost C++ Libraries
From the article:
The prime motivation for acceptance is:
- Reviewers have real-world use cases today for which they found Outcome to be an effective and best available alternative; and which is consistent with current-need and expectations; and which is consistent with ongoing C++ Standard evolution efforts...
Fantastic Algorithms and Where To Find Them - Nicholas Ormrod
New Video from Meeting C++ 2017!
Fantastic Algorithms and Where To Find Them
by Nicholas Ormrod
Quick Q: Direct initialization with empty initializer list
Quick A: If there is an initializer list contructor, it will choose it.
Recently on SO:
Direct initialization with empty initializer list
When an argument is an initializer list ([dcl.init.list]), it is not an expression and special rules apply for converting it to a parameter type.
If the parameter type is std::initializer_list or “array of X” and all the elements of the initializer list can be implicitly converted to X, the implicit conversion sequence is the worst conversion necessary to convert an element of the list to X. This conversion can be a user-defined conversion even in the context of a call to an initializer-list constructor.
Otherwise, if the parameter is a non-aggregate class X and overload resolution per [over.match.list] chooses a single best constructor of X to perform the initialization of an object of type X from the argument initializer list, the implicit conversion sequence is a user-defined conversion sequence. If multiple constructors are viable but none is better than the others, the implicit conversion sequence is the ambiguous conversion sequence. User-defined conversions are allowed for conversion of the initializer list elements to the constructor parameter types except as noted in [over.best.ics].
Quick Q: Uses of destructor = delete;
Quick A: If you have an object which should never, ever be deleted or stored on the stack (automatic storage), or stored as part of another object, =delete will prevent all of these.
Recently on SO:
Uses of destructor = delete;
struct Handle { ~Handle()=delete; }; struct Data { std::array<char,1024> buffer; }; struct Bundle: Handle { Data data; }; using bundle_storage = std::aligned_storage_t<sizeof(Bundle), alignof(Bundle)>; std::size_t bundle_count = 0; std::array< bundle_storage, 1000 > global_bundles; Handle* get_bundle() { return new ((void*)global_bundles[bundle_count++]) Bundle(); } void return_bundle( Handle* h ) { Assert( h == (void*)global_bundles[bundle_count-1] ); --bundle_count; } char get_char( Handle const* h, std::size_t i ) { return static_cast<Bundle*>(h).data[i]; } void set_char( Handle const* h, std::size_t i, char c ) { static_cast<Bundle*>(h).data[i] = c; }Here we have opaque Handles which may not be declared on the stack nor dynamically allocated. We have a system to get them from a known array.
I believe nothing above is undefined behavior; failing to destroy a Bundle is acceptable, as is creating a new one in its place.
And the interface doesn't have to expose how Bundle works. Just an opaque Handle.
Now this technique can be useful if other parts of the code need to know that all Handles are in that specific buffer, or their lifetime is tracked in specific ways. Possibly this could also be handled with private constructors and friend factory functions.
Meltdown And Spectre--Matt Godbolt
If you missed it:
Meltdown And Spectre
by Matt Godbolt
From the article:
A presentation on my understanding of the Meltdown and Spectre hardware exploits.
ACCU 2018 Schedule has been published -- ACCU conference committee
The schedule for the upcoming ACCU 2018 conference in Bristol, UK from 2018-04-11 to 2018-04-14 has been published.
ACCU 2018 Schedule
by ACCU conference committee
About the conference:
Again we have three C++ tracks this year!We will have keynotes by Gen Ashley, Hadi Hariri, Lisa Lippincott and Seb Rose.
Four full day tutorials take place the day before the conference, three with C++ content.
So don't forget to register.
CppCast Episode 136: foonathan/type_safe and more with Jonathan Müller
Episode 136 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Jonathan Müller to talk about his experience at University and some of his recent projects.
CppCast Episode 136: foonathan/type_safe and more with Jonathan Müller
by Rob Irving and Jason Turner
About the interviewee:
Jonathan is a CS student passionate about C++. In his spare time he writes libraries like foonathan/memory which provides memory allocator implementations. He is also working on standardese which is a documentation generator specifically designed for C++. Jonathan tweets at @foonathan and blogs about various C++ and library development related topics at foonathan.net.
Fantastic Algorithms and Where To Find Them - Nicholas Ormrod
A great introduction to some lesser known algorithms:
Fantastic Algorithms and Where To Find Them
by Nicholas Ormrod
N4720: Working Draft, Extensions to C++ for Modules -- Gabriel Dos Reis
A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.
Document number: N4720
Date: 2018-01-29
Working Draft, Extensions to C++ for Modules
by Gabriel Dos Reis
Excerpt:
As approved between meetings as a current working draft base for further proposal discussion in Jacksonville.