This SO post seems to suggest that language indeed supports accepting temporaries only for arguments.
Why is then unique_ptr designed to accepted aliased pointers, like this:
auto ptr = new Widget{};
auto uptr = std::unique_ptr<Widget>(ptr);
Why not just restrict to:
auto uptr = std::unique_ptr<Widget>(new Widget{});
Because this doesn't help.
It's required that the pointer is created by a suitable allocation function for the given deleter, which is different to it being temporary.
You can't distinguish pointers created by a new expression, function call and by & operator by a value category - they are all rvalues.
There is no good reason as far as I know, I think it this an underexploitation of the C++ language from the library.
I asked the same question Why is raw pointer to shared_ptr construction allowed in all cases?
I still don't find a good reason for not making the constructor of std::unique_ptr accepting only r-value references, either from new or from a factory. Here I put it as answer and not as a comment to put it in at the same level of the other answer with which I don't agree.
If you really need to accept an existing pointer, you can always cast, that is use std::move. So it is not an excuse, because that is not the norm.
Related
I have read a few (pesudo) implementions of std::move(). And all are just casting away the reference of the parameter and then returning it as a rvalue reference.
It doesn't do anything more than that.
However, I am curious:
1. whether it does more than that.
2. whether standard explicitly states that so that the caller should be aware the side effect.
In the book The C++ Programming Language 4th edition, it states "move(x) marks x for destruction so that move(x) should be used with care".
Does it mean that there is a side effect imposed by the standard and so compiler can do certain optimization?
Thanks in advance.
Yes, that's exactly as it is described in the standard. In N4659 (which is last draft I found)
it says in §23.2.5
template <class T> constexpr remove_reference_t<T>&& move(T&& t) noexcept;
Returns: static_cast<remove_reference_t<T>&&>(t)
It doesn't mark anything for destruction, and it doesn't change the object but object may be changed in function that accepts rvalue (such as move constructor, move assignment operator)
Yes, std::move is a bit of a misnomer as it doesn't actually move anything. It is used to indicate that an object may be "moved from".
It does this by casting the object to a T&&. cppreference states the return value is static_cast<typename std::remove_reference<T>::type&&>(t). (btw, that is exactly what VS2017 does)
I don't know precisely what the standard says on the matter.
I know that std::vector<T>::push_back() has move semantics support. So, when I add a named temporary instance to a vector, I can use std::move().
What are the other common places in the STL that I should grow the habit to add std::move()
I know that std::vector<T>::push_back() has move semantics support.
The support that push_back has is simply an additional overload that takes an rvalue reference, so that the new value T inside the vector can be constructed by invoking T(T&&) instead of T(const T&). The advantage is that the former can be implemented way more efficiently because it assumes that the passed rvalue reference is never going to be used afterwards.
Most Standard Library containers have added similar overloads to their push/enqueue/insert member functions. Additionally, the concept of emplacement has been added (e.g. std::vector<T>::emplace_back), where the values are constructed in place inside the container in order to avoid unnecessary temporaries. Emplacement should be preferred to insertion/pushing.
So, when I add a named temporary instance to a vector, I can use std::move().
"Named temporary" doesn't really make much sense. The idea is that you have an lvalue you don't care about anymore, and you want to turn it into a temporary by using std::move. Example:
Foo foo;
some_vector.emplace_back(std::move(foo));
// I'm sure `foo` won't be used from now on
Just remember that std::move is not special: it literally means static_cast<T&&>.
What are the other common places in the STL that I should grow the habit to add std::move?
This is a really broad question - you should add std::move everywhere it makes sense, not just in the context of the Standard Library. If you have a lvalue you know you're not going to use anymore in a particular code path, and you want to pass it/store it somewhere, then std::move it.
Matrix<T, Dynamic, Dynamic>::InnerIterator doesn't seem to use the standard way (operator *) to dereference it.
It has a member function value().
I am rather surprised, as this would not interface well with third party algorithms, like STL algorithms.
Why it doesn't declare operator *? Even worse is that value() does not return by reference, so you can't change the underlying value of the pointed element. What is the proper way to use it?
This is because most of the times, the value alone in useless without the respective inner/row/column indices, as returned by index()/row()/col(). In other cases, you only care about the indices. Anyway, you can easily write a little wrapper to make it compatible with STL if needed.
Finally, if you want to modify the value, there is a valueRef() method returning by non const reference.
I'm a C++ senior programmer. I'm currently doing some Go programming. The only feature I really miss is the const qualifier. In go, if you want to modify an object, you pass its pointer. If you don't want to modify it, you pass it by value. But if the struct is big, you should pass it by pointer, which overrides the no-modification feature. Worse, you can pass an object by value, but if it contains a pointer, you can actually modify its contents, with terrible race condition dangers. Some language types like maps and slices have this feature. This happens in a language that's supposed to be built for concurrency. So the issue of avoiding modification is really non-existent in Go, and you should pass small objects that do not contain pointers (you must be aware that the object does not contain a pointer) by value, if they aren't gonna be modified.
With const, you can pass objects by const pointer and don't worrying about modification. Type-safety is about having a contract that allows speed and prevents type-related bugs. Another feature that does this too is the const qualifier.
The const type qualifier in C/C++ has various meanings. When applied to a variable, it means that the variable is immutable. That's a useful feature, and one that is missing from Go, but it's not the one you seem to be talking about.
You are talking about the way that const can be used as a partially enforced contract for a function. A function can give a pointer parameter the const qualifier to mean that the function won't change any values using that pointer. (Unless, of course, the function uses a cast (a const_cast in C++). Or, in C++, the pointer points to a field that is declared mutable.)
Go has a very simple type system. Many languages have a complex type system in which you enforce the correctness of your program by writing types. In many cases this means that a good deal of programming involves writing type declarations. Go takes a different approach: most of your programming involves writing code, not types. You write correct code by writing correct code, not by writing types that catch cases where you write incorrect code. If you want to catch incorrect code, you write analyzers, like go vet that look for cases that are invalid in your code. These kinds of analyzers are much much easier to write for Go than for C/C++, because the language is simpler.
There are advantages and disadvantages to this kind of approach. Go is making a clear choice here: write code, not types. It's not the right choice for everyone.
Please treat it as an expanded comment. I'm not any programming language designer, so can't go deep inside the details here, but will present my opinion as a long-term developer in C++ and short-term developer in Go.
Const is a non-trivial feature for the compiler, so one would have to make sure whether it's providing enough advantage for the user to implement it as well as won't sacrifice the simplicity of syntax. You might think it's just a const qualifier we're talking about, but looking at C++ itself, it's not so easy – there're a lot of caveats.
You say const is a contract and you shouldn't be able to modify it at any circumstances. One of your arguments against using read only interfaces is that you can cast it to original type and do whatever you want. Sure you can. The same way you can show a middle finger to the contract in C++ by using const_cast. For some reason it was added to the language and, not sure I should be proud of it, I've used it once or twice.
There's another modifier in C++ allowing you to relax the contract – mutable. Someone realised that const structures might actually need to have some fields modified, usually mutexes protecting internal variables. I guess you would need something similar in Go in order to be able to implement thread-safe structures.
When it comes simple const int x people can easily follow. But then pointers jump in and people really get consfused. const int * x, int * const x, const int * const x – these are all valid declarations of x, each with different contract. I know it's not a rocket science to choose the right one, but does your experience as a senior C++ programmer tell you people widely understand these and are always using the right one? And I haven't even mentioned things like const int * const * * * const * const x. It blows my mind.
Before I move to point 4, I would like to cite the following:
Worse, you can pass an object by value, but if it contains a pointer,
you can actually modify its contents
Now this is interesting accusation. There's the same issue in C++; worse – it exists even if you declare object as const, which means you can't solve the problem with a simple const qualifier. See the next point:
Per 3, and pointers, it's not so easy to express the very right contract and things sometimes get unexpected. This piece of code surprised a few people:
struct S {
int *x;
};
int main() {
int n = 7;
const S s = {&n}; // don't touch s, it's read only!
*s.x = 666; // wait, what? s is const! is satan involved?
}
I'm sure it's natural for you why the code above compiles. It's the pointer value you can't modify (the address it points to), not the value behind it. You must admit there're people around that would raise their eyebrow.
I don't know if it makes any point, but I've been using const in C++ all the time. Very accurate. Going mental about it. Not sure whether is has ever saved my ass, but after moving to Go I must admit I've never missed it. And having in mind all these edge cases and exceptions I can really believe creators of a minimalistic language like Go would decide to skip on this one.
Type-safety is about having a contract that allows speed and prevents
type-related bugs.
Agreed. For example, in Go, I love there're no implicit conversions between types. This is really preventing me from type-related bugs.
Another feature that does this too is the const qualifier.
Per my whole answer – I don't agree. Where a general const contract would do this for sure, a simple const qualifier is not enough. You then need a mutable one, maybe kind of a const_cast feature and still – it can leave you with misleading believes of protection, because it's hard to understand what exactly is constant.
Hopefully some language creators will design a perfect way of defining constants all over in our code and then we'll see it in Go. Or move over to the new language. But personally, I don't think C++'s way is a particularly good one.
(Alternative would be to follow functional programming paradigms, which would love to see all their "variables" immutable.)
I found in documentation that matrix.swap(other) is defined in Eigen.
Is std::swap(matrix, other) specialized using the swap method?
I'm asking this because if not, I'd like to specialized it myself.
std::swap does not work on Eigen's objects and it cannot really be specialised because std::swap has only one template parameter. Both arguments must be of the same type.
You can still implement your own swap free function in your own namespace. See for instance this discussion.