The pointer literal is the keywordAnd this is from 18.2/9:nullptr. It is a prvalue of typestd::nullptr_t.
Sonullptr_tis defined as follows:
namespace std { typedef decltype(nullptr) nullptr_t; }
nullptr is of type nullptr_t, and nullptr_t is defined to be the type of nullptr.
You can log into Artima with the account you used to purchase the book, click on "Your Settings", and redownload anytime. If you've forgotten your password, you can get a reminder here.It would be a mistake to interpret the greater frequency of updates for the C++11 materials as meaning that I pay less attention to the materials on using C++ in embedded systems. I don't. The simple fact is that C++11 was in a state of flux up until final standardization, and since then compilers have been adding increasing feature support, plus I've been learning more about the features in C++11 and how to use them. There's been a lot happening in the C++11 world, and I've been working hard to keep my training materials current (while at the same time not bombarding you with updates).
class Widget {
public:
template<typename T>
Widget(const T&);
// ...
};
The key thing to recognize was that this template, though it could be instantiated to yield the signature of a copy constructor, is itself not a copy constructor, and that means that the class does not declare one. That being the case, if the copy constructor is needed, the compiler generates one as usual, because that's the rule: if there is no user-declared copy constructor (i.e., constructor taking a const Widget& parameter) and one is needed, the compiler generates one. The fact that such a function could be generated from a user-declared template is irrelevant.class Widget {
public:
template<typename T>
Widget(T&&); // now takes universal reference
// ...
};
Consider now this code:
Widget w; Widget wcopy = w; // copy w to wcopyThis is a request to copy w. Widget has no copy constructor, so the compiler generates one with the default signature. The resulting class looks like this:
class Widget {
public:
Widget(const Widget&); // copy constructor (compiler-generated)
template<typename T>
Widget(T&&); // universal copy constructor
// ...
};
When the compiler see the request to copy w, it knows it can call the copy constructor, just like it could in C++98, but it also knows that it can instantiate the template. Unlike the C++98 template, however, this one lacks a const-qualification on its parameter, so the resulting instantiation also lacks one. After instantiation, the class effectively looks like this:
class Widget {
public:
Widget(const Widget&); // copy constructor (compiler-generated)
Widget(Widget&); // instantiated template
// ...
};
Overload resolution now kicks in to choose from these two candidate functions. (Technically, one is a template function, not a function, and to be really technical about it, it's a template specialization, not a template instantiation, but none of that matters here.)const Widget cw; Widget cwcopy = cw; // copy a const WidgetNow we're back in C++98-land. The compiler-generated copy constructor and the template instantiation have the same signature (both take const Widget& parameters), so the function wins.
#include <iostream>
class Widget {
public:
Widget(){};
Widget(const Widget&) { std::cout << "Widget copy ctor "; }
template<typename T>
Widget(const T&) { std::cout << "Generalized Widget copy ctor "; }
template<typename T>
Widget(T&&) { std::cout << "Universal Widget ctor "; }
};
void endLine() { std::cout << '\n'; }
int main()
{
Widget w;
{
std::cout << "Create Widget from Widget:\n";
std::cout << " Direct init w/parens: "; Widget wcopy1(w); endLine();
std::cout << " Copy init : "; Widget wcopy2 = w; endLine();
std::cout << " Direct init w/braces: "; Widget wcopy3 {w}; endLine();
endLine();
}
const Widget cw;
{
std::cout << "Create Widget from const Widget:\n";
std::cout << " Direct init w/parens: "; Widget wcopy1(cw); endLine();
std::cout << " Copy init : "; Widget wcopy2 = cw; endLine();
std::cout << " Direct init w/braces: "; Widget wcopy3 {cw}; endLine();
endLine();
}
}
gcc 4.7 produces this output:Create Widget from Widget: Direct init w/parens: Universal Widget ctor Copy init : Universal Widget ctor Direct init w/braces: Universal Widget ctor Create Widget from const Widget: Direct init w/parens: Widget copy ctor Copy init : Widget copy ctor Direct init w/braces: Widget copy ctorNothing surprising there, but if I use auto to deduce the type of the copy, gcc's output changes. That is, this source code,
int main()
{
Widget w;
{
std::cout << "Create auto from Widget:\n";
std::cout << " Direct init w/parens: "; auto wcopy1(w); endLine(); // now using auto
std::cout << " Copy init : "; auto wcopy2 = w; endLine();
std::cout << " Direct init w/braces: "; auto wcopy3 {w}; endLine();
endLine();
}
const Widget cw;
{
std::cout << "Create auto from const Widget:\n";
std::cout << " Direct init w/parens: "; auto wcopy1(cw); endLine();
std::cout << " Copy init : "; auto wcopy2 = cw; endLine();
std::cout << " Direct init w/braces: "; auto wcopy3 {cw}; endLine();
endLine();
}
}
produces this output:
Create auto from Widget: Direct init w/parens: Universal Widget ctor Copy init : Universal Widget ctor Direct init w/braces: Universal Widget ctor Universal Widget ctor Create auto from const Widget: Direct init w/parens: Widget copy ctor Copy init : Widget copy ctor Direct init w/braces: Widget copy ctor Universal Widget ctorThis is surprising. Where are those extra constructor calls coming from? (In a comment on my last post, Julain posted results for clang, which did not show such extra calls.)
class Widget {
public:
Widget(){};
Widget(const Widget&) { std::cout << "Widget copy ctor "; }
Widget(Widget&&) { std::cout << "Widget move ctor "; } // added this
template<typename T>
Widget(const T&) { std::cout << "Generalized Widget copy ctor "; }
template<typename T>
Widget(T&&) { std::cout << "Universal Widget ctor "; }
};
then reran the test (using auto-declared variables). The revised results?
Create auto from Widget: Direct init w/parens: Universal Widget ctor Copy init : Universal Widget ctor Direct init w/braces: Universal Widget ctor Create auto from const Widget: Direct init w/parens: Widget copy ctor Copy init : Widget copy ctor Direct init w/braces: Widget copy ctorNo extra constructor calls. Funky, no?
Some of the following analysis is incorrect, but rather than simply edit the post to remove the wrong information and replace it with correct information, I'll add comments like this.gcc is making an extra call to the universal copy constructor only when I use brace initialization. My theory is based on the observation that when brace initialization is used to initialize a std::initializer_list object, the values in the braced list are copied into a temporary rvalue array. There are no std::initializer_list objects in my code, but let's suppose, for reasons I cannot fathom, that the use of auto in the above code somehow prompts gcc to treat a braced initializer as if it were being used with a std::initializer_list.
There are std::initializer_list objects in my code, because, as a prospective guideline for Effective C++11 puts it, "Remember that auto + {} == std::initializer_list." The statement
auto wcopy {w};
creates an object of type std::initializer_list<Widget>, not, as I had thought when I wrote the original post, an object of type Widget.If that were the case, the to-be-copied Widget would be copied into the array, where it would be an rvalue that would then be moved into the object being initialized. That is, given
auto wcopy {w};
w would be copied into an array, and a request would then be made to move this array element into wcopy. But in the code where I declare no move constructor, no move constructor can be generated, because I've declared a copy constructor, and if you declare a copy operation, no move operators are generated. So in the code that requests a move of the rvalue in the array, the move is accomplished by calling a copy operation.const Widget cw;
auto cwcopy {cw};
though cw is const, the copy of cw in the array is not. That means that when the compiler has to choose between the copy constructor (which takes a const Widget& parameter) and the instantiated universal copy constructor (which, in this case, takes a Widget& parameter), the universal copy constructor is the better match.I no longer believe that this is a bug in gcc, because gcc is doing exactly what I'd guessed: initializing a std::initializer_list<Widget> object. I just didn't think it was supposed to. Now I do.Anyway, bottom line: in C++98, copy constructors could not be generated from templates, but in C++11, they can be, practically speaking. At least that's my current understanding. Thanks to Martinho Fernandes for his post that sent me down this particular rabbit hole.
Thanks also to Xeo for pointing out the error in my original post.Scott
In the words of technical support professionals everywhere, it works for me.<pre class="brush: c++">
Your code goes here
</pre>
#include <iostream>
class Widget {
public:
Widget(){};
Widget(const Widget&) { std::cout << "Widget copy ctor "; }
template<typename T>
Widget(const T&) { std::cout << "Generalized Widget copy ctor "; }
template<typename T>
Widget(T&&) { std::cout << "Universal Widget ctor "; }
};
void endLine() { std::cout << '\n'; }
int main()
{
Widget w;
{
std::cout << "Create Widget from Widget:\n";
std::cout << " Direct init w/parens: "; Widget wcopy1(w); endLine();
std::cout << " Copy init : "; Widget wcopy2 = w; endLine();
std::cout << " Direct init w/braces: "; Widget wcopy3 {w}; endLine();
endLine();
}
{
std::cout << "Create auto from Widget:\n";
std::cout << " Direct init w/parens: "; auto wcopy1(w); endLine();
std::cout << " Copy init : "; auto wcopy2 = w; endLine();
std::cout << " Direct init w/braces: "; auto wcopy3 {w}; endLine();
endLine();
}
const Widget cw;
{
std::cout << "Create Widget from const Widget:\n";
std::cout << " Direct init w/parens: "; Widget wcopy1(cw); endLine();
std::cout << " Copy init : "; Widget wcopy2 = cw; endLine();
std::cout << " Direct init w/braces: "; Widget wcopy3 {cw}; endLine();
endLine();
}
{
std::cout << "Create auto from const Widget:\n";
std::cout << " Direct init w/parens: "; auto wcopy1(cw); endLine();
std::cout << " Copy init : "; auto wcopy2 = cw; endLine();
std::cout << " Direct init w/braces: "; auto wcopy3 {cw}; endLine();
endLine();
}
}
Update 10/17/12: Having run across this blog post, I also gave Google's Prettify a try. I don't like the result as well as that of SyntaxHighlighter, but judge for yourself. Here's a prettified version of the Widget class above:
class Widget {
public:
Widget(){};
Widget(const Widget&) { std::cout << "Widget copy ctor "; }
template<typename T>
Widget(const T&) { std::cout << "Generalized Widget copy ctor "; }
template<typename T>
Widget(T&&) { std::cout << "Universal Widget ctor "; }
};
Update 6/12/20: I removed support for SyntaxHighlighter and Google Prettify from the blog, because neither seems to be supported any longer. I did only cursory testing, but I'm hoping that the result will be that code examples in my blog posts continue to look like code, except they won't be syntax-highlighted.
class Widget1 {
public:
Widget1(const std::string& n): name(n) {}
private:
std::string name;
};
The problem here is that if an rvalue is passed to the Widget1 constructor, name is copy-initialized from n instead of being move-initialized. That's easy to fix using perfect forwarding, which is designed to optimize this kind of thing:
class Widget2 {
public:
template <typename T>
Widget2(T&& n): name(std::forward<T>(n)) {}
private:
std::string name;
};
No muss, no fuss, no enable_if, no testing for whether the argument passed to n was an rvalue--none of that stuff. Very nice.class Widget3 {
public:
Widget3(const std::string& n): name(n) {}
Widget3(int id): name(findNameFromID(id)) {}
private:
std::string name;
};
Adding this to the version of Widget with the perfect forwarding constructor, however, leads to grief. But not immediately. The class will compile without any trouble, and simple tests will work as expected:class Widget4 {
public:
template <typename T>
Widget4(T&& n): name(std::forward<T>(n)) { std::cout << "T&&\n"; }
Widget4(int id): name(findName(id)) { std::cout << "int\n"; }
private:
std::string name;
};
Widget4 w1("Hello"); // calls perfect forwarding ctor
Widget4 w2(22); // calls int constructor
But slightly trickier tests fail. For example, if the type of the passed ID isn't exactly int--e.g., a long or a short or an unsigned--the perfect forwarding constructor is a better match, and the code will try to initialize a std::string with a numerical value. This makes no sense, and the compiler will exhibit no reluctance in telling you that. Given
Widget4 w3(22L); // pass a longgcc 4.7 says this:
ctors.cpp: In instantiation of 'Widget4(long int &&)':
ctors.cpp:40:18: required from here
ctors.cpp:18:42: error: invalid conversion from 'long int' to 'const char *' [-
fpermissive]
basic_string.h:487:7: error: init. arg 1 of 'basic_string<
char; _Traits = char_traits<char>; _Alloc = allocator<char>, _Traits
, _Alloc
>::basic_string(
const char; _Traits = char_traits<char>; _Alloc = allocator<char> *
, const _Alloc &
)' [-fpermissive]
In file included from c:\users\scott\apps\mingw\bin\../lib/gcc/i686-pc-
mingw32/4.7.0/../../../../include/c++/4.7.0/string:54:0,
from ctors.cpp:1
The fundamental problem is that perfect forwarding and overloading make very bad bedfellows, because perfect forwarding functions want to take everything. They're the greediest functions in C++.class Widget5 {
public:
template <typename T>
Widget5(T&& n, typename std::enable_if<!std::is_integral<T>::value>::type* = 0)
: name(std::forward<T>(n)) { std::cout << "T&&\n"; }
Widget5(int id): name(findName(id)) { std::cout << "int\n"; }
private:
std::string name;
};
This code behaves as we'd like, assuming (sigh) we'd like to treat a char as a number:
Widget5 w3a("Sally"); // calls perfect fowarding ctor
Widget5 w3b(44); // calls int ctor
Widget5 w3c(44L); // calls int ctor
Widget5 w3d((short)44); // calls int ctor
Widget5 w3e('x'); // calls int ctor
If more constructor overloads are added, or if the constraints on when the perfect forwarding constructor is applicable become more complicated, the enable_if-related code can become, er, unpleasant. Such unpleasantness is presumably the noise that
Sumant Tambe refers to when he rejects perfect forwarding.
Given that rvalue references are declared using “&&”, it seems reasonable to assume that the presence of “&&” in a type declaration indicates an rvalue reference. That is not the case:I hope you find the article both interesting and useful.
Widget&& var1 = someWidget; // here, “&&” means rvalue reference auto&& var2 = var1; // here, “&&” does not mean rvalue reference template<typename T> void f(std::vector<T>&& param); // here, “&&” means rvalue reference template<typename T> void f(T&& param); // here, “&&” does not mean rvalue referenceIn this article, I describe the two meanings of “&&” in type declarations, explain how to tell them apart, and introduce new terminology that makes it possible to unambiguously communicate which meaning of “&&” is intended. Distinguishing the different meanings is important, because if you think “rvalue reference” whenever you see “&&” in a type declaration, you’ll misread a lot of C++11 code.
| Julian Storer (unless he's using a picture of somebody else) |
I did check it out, and not just because he called me a C++ guru hero. Though I had not watched all of Bret Victor's demo, I had watched part of it, so I had some idea what was involved, and the idea that something similar could be done for C++ intrigued me. Also, when people tell me they have done something in C++ that nobody has done before, that tends to catch my attention. Most important, at the time I was trying to figure out what to do with Julian's email, I had much more pressing things to work on that I didn't want to attack yet, so I needed a way to tell myself I was working without actually, you know, working. So I toddled over to the screencast Julian had put together and invested the six minutes and thirty-six seconds it runs.For the last decade I've been running a big C++ cross-platform toolkit called JUCE. Won't attempt to describe it in this email - there's plenty of info about it on my website if you want to learn more.
I've just been making some announcements about a new tool that I'm aiming to release soon, and being proud of what I've managed to cook-up, I thought it'd be worth pestering some of my C++ guru heros to have a look at it. It's something that nobody's managed to do in C++ before, so I think you'll probably find it interesting!
The TL;DR is: I've built an IDE that uses Clang and the LLVM JIT engine to provide real-time interactive execution of C++ GUI code, and to allow GUI editing by automatic refactoring of user-code... Hard to sum it up in a sentence, but if you saw the Bret Victor demo that everyone was talking about a few months ago, you'll get the gist - hewas showing off interactive javascript, and I've managed to do the same trick in C++.
Hope you can spare 10 mins to check it out!
