Do I need to port std::move to my kernel?

Question

I'm concerned that in kernel land I will not have access to things like std::move, std::forward, std::initializer_list, etc. While some of these features are built into the language, they still require the appropriate headers and library implementation. Is the following sufficient to take advantage of move semantics, or do I need to go the full nine yards and port a C++ library?

template <typename T>
typename remove_reference<T>::type&& move(T&& arg)
{
  return static_cast<typename remove_reference<T>::type&&>(arg);
}

Carlicarlick

Freestanding implementations should still have <initializer_list> (and it's not something that you can code up yourself since it's intimately tied to the compiler implementation). std::move and std::forward you may have to code up yourself, but they are just prettified casts. Move semantics needs (1) compiler support and (2) move-aware types. If you are using a C++03 std::vector implementation, you won't get move semantics even with std::move and a C++11 compiler. – Oversew

+1 for os-dev, as I do >o< – Pigeontoed

I feel that a huge number of std::... – Affirm

What kernel are you referring to? If you're referring to the Linux kernel, the correct answer is that the kernel is written C, not C++. For your own, self-education, you are free to do anything, of course, but prior proposals to include C++ code into the Linux kernel have been met with howls of laughter, and I don't think this will ever change. – Unexceptional

If the kernel is Linux, then using C++ is a bad idea. C++ is used in some OS kernels, for example the Apple IO Kit in OS X, where e.g. inheritance is used to make writing device drivers easier. But Linus Torvalds and others in the Linux kernel community are openly hostile to C++. – Doehne

You really need to put more meat on the question: what is your environment, are you writing an OS from scratch, are you writing a linux kernel module, other os driver, are you writing code for an embedded system? – Quarterage

Answer 1

That should do it, assuming no typos. The complete definition is given in the standard (two actually; old and new), and I've done exactly that: just copy the official version into my own header, and then address my special requirements and/or support old gnu std lib but compiler groks rvalue references.

To address @T.C.'s concern, it is still useful to be able to write my own move-only types and be able to use them e.g. return from functions, even if the supplied containers don't know about it. The Boost container classes do, and you can override the configuration to tell Boost you have &&, if you supply all the std::move, std::forward, and whatnot that it needs. I've also gotten a hybrid approach using native rvalue references and Boost move emulation working at the same time, for compatibility with code compiled with Boost as normally configured.

Wicketkeeper