C++ User Group Meetings in March
The monthly overview on upcoming C++ User Group Meetings
C++ User Group Meetings in March
by Jens Weller
Articles & Books
optional in a possible C++20 future--Barry Revzin
Lots of proposals:
optional<T> in a possible C++20 future
by Barry Revzin
From the article:
C++17 gave us std::optional which is, in the words of a friend of mine, one of those really simple, ultra complex types — in the sense that it’s very easy to understand and use properly, even for relatively inexperienced programmers… but extremely difficult to implement correctly, even for experts (another such is std::pair). Today, it’s well over a thousand lines of code, most of which is critical to support even its most basic functionality. optional<T> is the simplest sum type, and it appears in lots of different languages (and even has special syntax in Swift) under various related names — Maybe, Option, etc. — but in the languages I’m even nominally familiar with, it’s about as simple to implement as it is to use.
But that’s the state of affairs today. What does tomorrow bring?
How if constexpr simplifies your code in C++17--Meeting C++
Very useful.
How if constexpr simplifies your code in C++17
by Meeting C++
From the article:
So, yesterday we had a little live coding session at my C++ User Group Düsseldorf. I want to recreate some of this code, to show how C++17 actually does help quite a bit with making code shorter and more expressive. Since I don't have a local C++17 compiler installed, I use godbolt and wandbox to test some of the examples...
Quick Q: What's the difference between std::move and std::forward?
Quick A: One is used to forward parameters, one to move an object.
Recently on SO:
What's the difference between std::move and std::forward?
std::move takes an object and allows you to treat it as a temporary (an rvalue). Although it isn't a semantic requirement, typically a function accepting a reference to an rvalue will invalidate it. When you see std::move, it indicates that the value of the object should not be used afterwards, but you can still assign a new value and continue using it.
std::forward has a single use case: to cast a templated function parameter (inside the function) to the value category (lvalue or rvalue) the caller used to pass it. This allows rvalue arguments to be passed on as rvalues, and lvalues to be passed on as lvalues, a scheme called "perfect forwarding."
To illustrate:
void overloaded( int const &arg ) { std::cout << "by lvalue\n"; } void overloaded( int && arg ) { std::cout << "by rvalue\n"; } template< typename t > /* "t &&" with "t" being template param is special, and adjusts "t" to be (for example) "int &" or non-ref "int" so std::forward knows what to do. */ void forwarding( t && arg ) { std::cout << "via std::forward: "; overloaded( std::forward< t >( arg ) ); std::cout << "via std::move: "; overloaded( std::move( arg ) ); // conceptually this would invalidate arg std::cout << "by simple passing: "; overloaded( arg ); } int main() { std::cout << "initial caller passes rvalue:\n"; forwarding( 5 ); std::cout << "initial caller passes lvalue:\n"; int x = 5; forwarding( x ); }As Howard mentions, there are also similarities as both these functions simply cast to reference type. But outside these specific use cases (which cover 99.9% of the usefulness of rvalue reference casts), you should use static_cast directly and write a good explanation of what you're doing.
C++ Tips on Initialization
C++ initialization is tricky. Check out Abseil's C++ Tips on initialization, which we've published over the past two weeks:
From Tip of the Week #142:
"Prior to C++11, theexplicitkeyword was meaningful only for constructors that could be called with a single argument, and our style guide required its use for such constructors so that they did not act as 'converting constructors.' That requirement was not applied for multi-parameter constructors. Indeed the style guide used to discourage use ofexplicitfor multi-parameter constructors as it had no meaning. That’s no longer the case."
A cake for your cherry: what should go in the C++ standard library? -- Corentin Jabot
A reply to Guy Davidson’s article “Batteries not included: what should go in the C++ standard library?”.
A cake for your cherry: what should go in the C++ standard library?
by Corentin Jabot
From the article
Over the past few years there has been a push to include a graphics library into the C++ standard. It would be something a bit like cairo. Or SDL.
I do think this is a path that should not be pursued. Let me tell you why...
Bjarne Stroustrup receives Draper Prize, engineering's top U.S. honor
A few months ago, Bjarne Stroustrup received one of the most distinguished engineering prizes in the world: the Faraday medal.
Last night, the U.S. National Academy of Engineering (NAE) presented Stroustrup with the United States' top engineering honor, the Charles Stark Draper Prize, for his work designing and implementing the C++ programming language. (Note: This is the second Draper prize awarded for a programming language; the first was to John Backus for Fortran, awarded in 1993.)
Please join us in congratulatating Dr. Stroustrup! He is the reason we are all here, and able to do what we do every day as C++ developers.
From the announcement:
Stroustrup’s development of C++ has helped bridge the gap between a problem and its computing elements through the use of visualization for engineers and members of varying disciplines, such as biologists, medical doctors, mathematicians, economists and politicians.
Stroustrup, a visiting professor in computer science at Columbia University, was elected to the National Academy of Engineering in 2004. He is a fellow of IEEE, the Association of Computing Machinery, the Computer History Museum and Churchill College, Cambridge, and is managing director in the technology division of Morgan Stanley in New York City.
The Charles Stark Draper Prize is a $500,000 biannual award that honors engineers whose accomplishments have significantly benefited society. It is considered the Nobel Prize of engineering.
C++ revolutionized the software industry by enabling a variety of software development techniques, including object-oriented programming, generic programming and general resource management, to be deployed at industrial scale. According to industry analysts, C++ is one of the most widely used programming languages in the world, with applications in communications, computer graphics, games, user interfaces, embedded systems, financial systems, medical systems, avionics, scientific computation and many other areas.
Batteries not included: what should go in the C++ standard library?
With the next standardisation meeting coming up, now is a good time to consider what the limits of the standard library should be.
Batteries not included: what should go in the C++ standard library?
By Guy Davidson
From the article:
About forty Christmases ago I was absolutely delighted to open a slot car racing set from my parents. I feverishly set everything up, created a track reminiscent of Brands Hatch, and went to plug everything in, only to discover that I needed batteries to operate the controllers. This was Great Britain in the 1970s...
Quick Q: How can a class template store either reference or value?
Quick A: This happen by default.
Recently on SO:
How can a class template store either reference or value?
You already wrote it (minus the required template <typename T>). The deduction rules for a forwarding reference preserve value category as follows:
- If t is bound to an lvalue of type T2, then T = T2&.
- If t is bound to an rvalue of type T2, then T = T2.
It's those deduction rules that std::forward relies on to do its job. And why we need to pass the type to it as well.
The above means that you instantiate holder directly with T2 in the rvalue case. Giving you exactly what you want. A copy is made.
As a matter of fact, two copies are made. Once to create the constructor argument t, and the other copy is to initialize obj_m from it. But we can get rid of it with some clever use of type_traits:
template <class T> class holder { T obj_m; // should be a reference if possible... public: holder(std::add_rvalue_reference_t<T> t) :obj_m { std::forward<T>(t) } {} }; template<typename T> auto hold_this(T && t) { return holder<T>(std::forward<T>(t)); }See it live. We use add_rvalue_reference_t to make t be of the correct reference type in each case. And "simulate" the argument deduction which would make obj_m { std::forward<T>(t) } resolve to initializing obj_m from the correct reference type.
I say "simulate" because it's important to understand the constructor argument for holder cannot be a forwarding reference because the constructor itself is not templated.
By the way, since you tagged c++17, we can also add a deduction guide to your example. If we define it as follows (with the feedback from T.C. incorporated):
template <class T> class holder { T obj_m; // should be a reference if possible... public: holder(T&& t) :obj_m { std::forward<T>(t) } {} }; template<typename T> holder(T&&) -> holder<T>;Then this live example shows you can define variables as hold h1{t}; and hold h2{test()};, with the same deduced types as the function return values from before.
Quick Q: In C++ are static member functions inherited? If yes why ambiguity error does not arise?
Quick A: Yes, and there are no ambiguity with static members.
Recently on SO:
In C++ are static member functions inherited? If yes why ambiguity error does not arise?
It's fine according to the lookup rules. You see, when you write member access (obj.display();), the member display is looked up not just in the scope of the class and its base classes. Base class sub-objects are taken into consideration as well.
If the member being looked up is not static, since base class sub-objects are part of the consideration, and you have two sub-objects of the same type, there's an ambiguity in the lookup.
But when they are static, there is no ambiguity. And to make it perfectly clear, the C++ standard even has a (non-normative) example when it describes class member lookup (in the section [class.member.lookup])