Somehow I don't find this to be a problem in my code. Yes, when using someone else's library you need to know how they handle ownership. But this is basically a problem inherited from C. For example, in the code you posted all the pointer-like handles are named 'p'. In my experience, if we consistently pursue minimal scope and minimal lifetime for our objects, then longer-lived objects are oddballs and we use the typ…
Ever done any enterprise C development? This is a very big problem in enterprise size code basis, specially with the rotation of external developers.
Oh noes. Yeah, C seems very not the thing to rotate external developers around in an enterprise size code base.
s isn't an rvalue. It has a name, and you can refer to it within the body of the constructor.
I understand that, but it's clearly not used in the body. I was hoping it would be a legal and implemented optimization. move calls strike me as ugly and kinda dangerous. What if you do wind up wanting to refer to s in the body later on? It'd be nice if the compiler just handled it.
> What if you do wind up wanting to refer to s in the body later on?
I understand that, but it's clearly not used in the body. I was hoping it would be a legal and implemented optimization. move calls strike me as ugly and kinda dangerous. What if you do wind up wanting to refer to s in the body later on? It'd be nice if the compiler just handled it.
> What if you do wind up wanting to refer to s in the body later on? Then copy s, don't move it.
The point is move makes things that look like values as annoying as pointers. You have to keep track.
The argument here is that in the body of the constructor the developer probably doesn't use s, so a trivial analysis of the function can say "oh, it doesn't matter if I destroy s, so in the one place where it is used I'll just move it". It doesn't then matter if it is obvious it happens or not, because the semantics of the program wouldn't be maintained (and honestly, I'd argue it is never quite obvious when what hap…
There are a number of considerations because the compiler can't prove it in general without augmenting the type system or doing whole-program analysis. Do you allow, but not require, the compiler to do this substitution whenever it can prove a value is never used again? This is unreliable across build options and compilers so it would be unwise to depend on it. There is an opportunity here for a tool that could ident…
You seem to be assuming that optimizations are only of value if they can be depended on happening consistently as a defined property of the language on every single platform for which there exists a compiler: in practice, compilers perform numerous optimizations (such as static branch prediction) that only work probabilistically even for the case of a specific version of a specific compiler on a specific operating system; I know of very few people (maybe you are one of them, however) who consider this to be a detriment. For a more obvious comparison: yes, I could sit around constructing object pools in my Java program to avoid heap allocations and their associated garbage collection penalty, but if rudimentary escape analysis manages to pick up a lot of the value, even if "fragile" or nondeterministic, I might not need to spend the time anymore to worry about that kind of detail in my software as the cost benefit analysis shows that the toolchain is now a more efficient usage of resources towards that issue (I could be spending my energy working on algorithm design, for example, instead of object pools). As long as the semantics of the language support the optimization, and as it doesn't seem to be difficult to implement, it would be useful to have the compiler perform this optimization for the developer, and one would expect such an optimization to either already be there or be "in the works".
There are a number of considerations because the compiler can't prove it in general without augmenting the type system or doing whole-program analysis. Do you allow, but not require, the compiler to do this substitution whenever it can prove a value is never used again? This is unreliable across build options and compilers so it would be unwise to depend on it. There is an opportunity here for a tool that could ident…
You seem to be assuming that optimizations are only of value if they can be depended on happening consistently as a defined property of the language on every single platform for which there exists a compiler: in practice, compilers perform numerous optimizations (such as static branch prediction) that only work probabilistically even for the case of a specific version of a specific compiler on a specific operating sy…
This is a very different kind of optimization than the other things you are talking about. This is something that is operating at a high level and potentially has implications that might not be obvious. You are changing the type of something and effecting the function overloads which are resolved. I think its important for what functions you are calling to be deterministic. My previous post was just touching on what possible value can be gained from allowing this and my conclusion is that it would be very little.
Also, your example of escape analysis is precisely because Java doesn't allow you to express what you are wanting to do, whereas C++ does allow you to express moves.
edit: I would compare this to C++'s copy elision, but that has a very high value and is much less intrusive.
You seem to be assuming that optimizations are only of value if they can be depended on happening consistently as a defined property of the language on every single platform for which there exists a compiler: in practice, compilers perform numerous optimizations (such as static branch prediction) that only work probabilistically even for the case of a specific version of a specific compiler on a specific operating sy…
This is a very different kind of optimization than the other things you are talking about. This is something that is operating at a high level and potentially has implications that might not be obvious. You are changing the type of something and effecting the function overloads which are resolved. I think its important for what functions you are calling to be deterministic. My previous post was just touching on what…
I guess considering a user defined move constructor could do something arbitrarily stupid you have to be consistent.
There are also some things that are powerful but I'm not quite sure if I really like them. For instance, he promotes the use of handles instead of pointers. He goes through these variants: Gadget* p = new Gadget(n); // not exception safe shared_ptr p{new Gadget(n)}; //exception safe unique_ptr p{new Gadget(n)}; //exception safe and less wasteful than shared_ptr if local Gadget g{n}; //his preferred solution My proble…
> My problem with his preferred solution is that I cannot know that Gadget is really a handle to a shared Gadget and not a big fat Gadget value on the stack. The only way of knowing that is to look at the implementation or the documentation. I'd say you do not _need_ to know. If Gadget contains tons of data, it's wiser for it to just put that on the heap, internally. Like std::vector does. As long as Gadget handles (…
I'd also say that using any class without reference to either its documentation or its implementation is a terrible idea in the first place, because who cares where it stores data if you're not using it properly?
I can't count the number of bugs I've fixed due to programmers (myself, sadly, included) using IDE code completion features as a substitute for reading documentation.
This is a very different kind of optimization than the other things you are talking about. This is something that is operating at a high level and potentially has implications that might not be obvious. You are changing the type of something and effecting the function overloads which are resolved. I think its important for what functions you are calling to be deterministic. My previous post was just touching on what…
I guess considering a user defined move constructor could do something arbitrarily stupid you have to be consistent.
Also, any function can be overloaded on rvalue references.
If you've ever wondered what's the deal with C++ and why it's being used in 2013, you might wanna watch this. Stroustrup isn't a very flashy speaker, but he says some incredibly insightful things. C++'s C heritage makes it hard to master and also causes countless misconceptions. Even if you never want to use C++, it's worth looking into some of the unique concepts that, sadly, didn't catch on in other languages so fa…
Const correctness is the essence of all functional languages; RAII is in functional languages too and even java has an interface for it