Practical constexpr - Jason Turner
Jason Turner about using constexpr in his own codebase:
Practical constexpr
by Jason Turner
By Meeting C++ | Feb 21, 2018 05:56 AM | Tags: meetingcpp constexpr c++17 c++14 c++11
Jason Turner about using constexpr in his own codebase:
Practical constexpr
by Jason Turner
By Adrien Hamelin | Feb 20, 2018 08:48 AM | Tags: advanced
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.
By Adrien Hamelin | Feb 20, 2018 08:44 AM | Tags: intermediate
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])
By Adrien Hamelin | Feb 20, 2018 08:40 AM | Tags: c++11 advanced
Quick A: Delete the move assignment.
Recently on SO:
Most concise way to disable copy and move semantics
According to this chart (by Howard Hinnant):
The most concise way is to =delete move assignment operator (or move constructor, but it can cause problems mentioned in comments).
Though, in my opinion the most readable way is to =delete both copy constructor and copy assignment operator.
By Meeting C++ | Feb 20, 2018 03:00 AM | Tags: tools meetingcpp efficiency clang-tidy clang
New video from Meeting C++ 2017
Advanced Tools for Better Productivity
by Gábor Horváth
By JoCool | Feb 18, 2018 11:06 AM | Tags: None
Following the success of our first webinar on 'Measuring software quality', we are pleased to announce the second in our series:
Demystifying C++ Lambdas
by Glennan Carnie
About the webinar:
Lambdas are one of the features of Modern C++ that seem to cause considerable consternation amongst many programmers.
In this 45 minute webinar, Feabhas Technical Consultant Glennan Carnie, will have a look at the syntax and underlying implementation of lambdas to try and put them into some sort of context.
The Webinar runs twice
10am GMT
4pm GMT
Choose a webinar and reserve a free place on our website:
By Nico Josuttis | Feb 18, 2018 10:58 AM | Tags: c++17
The next German public training for Modern C++ and C++17 will be in Cologne.
Public training for Modern C++ and C++17
by Nicolai Josuttis
About the training:
The training will be in Cologne/Köln on 24.-27. April 2018 given by Nicolai Josuttis, the author of "The C++ Standard Library", "C++17 - The Complete Guide", and co-author of "C++ Templates - The Complete Guide".
By Meeting C++ | Feb 18, 2018 06:38 AM | Tags: tools meetingcpp intermediate debug advanced
A great introduction into the inner workings of a compiler:
How C++ Debuggers work
by Simon Brand
By Meeting C++ | Feb 17, 2018 05:16 AM | Tags: meetingcpp intermediate functional experimental
Ivan Cukic continues his series of talks about functional programming:
Functional Programming: data
by Ivan Cukic
By robwirving | Feb 16, 2018 09:13 AM | Tags: None
Episode 138 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Mathieu Ropert to discuss C++ API & ABI compatibility issues and Modern CMake.
CppCast Episode 138: API & ABI Versioning with Mathieu Ropert
by Rob Irving and Jason Turner
About the interviewee:
Mathieu is a french C++ expert with an eclectic background. He's worked in various fields including kernels, virtualization, web development, databases, REST microservices, build systems and package management, all those in (or about) C or C++. He is presently awaiting his next challenge in the video game industry that should come up next May in Stockholm, Sweden. Until then, Mathieu lives and works in Paris, France where he is also host of the C++ French User Group.