Danya🔥
These is no check that unique_ptr is in moved out state because nullptr is not moved out state
Danya🔥
Do you understand that?
MᏫᎻᎯᎷᎷᎬᎠ
Yes I DO
BUT SEEMS LIKE YOU ARE NOT THE ONE GETTING MY IDEA
MᏫᎻᎯᎷᎷᎬᎠ
Manav got it quick
Manav
Danya🔥
There is no idea
You just don't understand the concept of the move semantics
Danya🔥
You don't need additional checks to check if the object in moved-from state
Danya🔥
And there is none in the unique_ptr
Danya🔥
So what is your idea?
MᏫᎻᎯᎷᎷᎬᎠ
And there is none in the unique_ptr
As I said
Unique_ptr is just an example of wide range of resource management types
MᏫᎻᎯᎷᎷᎬᎠ
It could be sockets, file handlers, custom class Foo
Anything
Danya🔥
It doesn't relate in any way to the move semantics, do you understand this?
MᏫᎻᎯᎷᎷᎬᎠ
When you have obj1 = std::move(obj2)
Obj2 dtor still gets called
MᏫᎻᎯᎷᎷᎬᎠ
When you have obj1 = std::move(obj2)
Obj2 dtor still gets called
Which probably has extra check
Which means there is an extra unnecessary performance hit
The obj2 is in moved-from state
Can some compilers avoid adding the extra check or calling its dtor at all if possible?
Danya🔥
There
Is
No
Extra
Check
That
Is
Related
To
Move
Semantics
Danya🔥
Again, you don't need any additional checks for move semantics
MᏫᎻᎯᎷᎷᎬᎠ
There
Is
No
Extra
Check
That
Is
Related
To
Move
Semantics
std::jthread checks if it's join able for example
Danya🔥
It is not related to the move semantics
MᏫᎻᎯᎷᎷᎬᎠ
But we still checked if it's joinable
MᏫᎻᎯᎷᎷᎬᎠ
But we still checked if it's joinable
Because we don't have a compile time guarantee
MᏫᎻᎯᎷᎷᎬᎠ
But compilers are becoming smart
So
Is there any chance to optimize that joinable check for us?
Danya🔥
Being non-joinable is part of the semantics of the jthread, it's not related to the move semantics
MᏫᎻᎯᎷᎷᎬᎠ
Being non-joinable is part of the semantics of the jthread, it's not related to the move semantics
joinable could return false if the std::jthread object is moved
Danya🔥
joinable could return false if the std::jthread object is moved
It doesn't make it related to the move semantics
Danya🔥
Please just remember it if you can't understand
MᏫᎻᎯᎷᎷᎬᎠ
Me: Hey compiler, this jthread object is std::moved, so it's not joinable(), okay?
Compiler: Okay?
Me: So you don't need to even call it's destructor, got it?
Compiler: Why?
Me: ....
Danya🔥
But compilers are becoming smart
So
Is there any chance to optimize that joinable check for us?
Compilers have their euristics for the optimization of the branches. Do not try optimize it yourself. It is not a problem in your code unless you can proof it
Danya🔥
MᏫᎻᎯᎷᎷᎬᎠ
meanwhile, the dtor:
~jthread()
{
if (joinable())
{
.....
}
}
MᏫᎻᎯᎷᎷᎬᎠ
It isn't necessary here
Danya🔥
You don't understand basics of C++
MᏫᎻᎯᎷᎷᎬᎠ
Lol
Danya🔥
And trying to microoptimize
MᏫᎻᎯᎷᎷᎬᎠ
Dtors doesn't make the actual destruction of the stack variable
MᏫᎻᎯᎷᎷᎬᎠ
It's just a function that runs before the stack frame gets destructed or unwind
Danya🔥
Dtors doesn't make the actual destruction of the stack variable
There is no concept of stack in the C++ you're referring to, expect std::stack
MᏫᎻᎯᎷᎷᎬᎠ
edited
MᏫᎻᎯᎷᎷᎬᎠ
So I suppose you don't know what heap and stack are?
Danya🔥
So I suppose you don't know what heap and stack are?
You should suppose that you don't understand the basics of C++
Danya🔥
If you think that there are the stack and the heap in C++, I dare you to find them in the standard.
MᏫᎻᎯᎷᎷᎬᎠ
If you think that there are the stack and the heap in C++, I dare you to find them in the standard.
https://en.cppreference.com/w/cpp/algorithm/ranges/sort_heap
Danya🔥
I'm laughing my ass off right now
MᏫᎻᎯᎷᎷᎬᎠ
Good for you
Danya🔥
https://en.cppreference.com/w/cpp/algorithm/ranges/sort_heap
Can you tell the purpose of this function?
MᏫᎻᎯᎷᎷᎬᎠ
Well it does sort_heap
MᏫᎻᎯᎷᎷᎬᎠ
lol
MᏫᎻᎯᎷᎷᎬᎠ
Anyway, this is becoming OT
Danya🔥
Madhu please help
The
Me: Hey compiler, this jthread object is std::moved, so it's not joinable(), okay?
Compiler: Okay?
Me: So you don't need to even call it's destructor, got it?
Compiler: Why?
Me: ....
Nice now that you're asking these questions.. next find the why, take the plunge into insanity 😁
Anonymous
Me: Hey compiler, this jthread object is std::moved, so it's not joinable(), okay?
Compiler: Okay?
Me: So you don't need to even call it's destructor, got it?
Compiler: Why?
Me: ....
You are confusing move semantics of C++ with ownership semantics in Rust. Rust transfers ownership. C++ transfers the contents of the object (ignoring Ref and other shared ownership concepts in Rust for simplifying the discussion)
So the C++ compiler can't figure out at a random point in your code whether the said object was copied from or moved from. The only thing it can assume is that an object to be destructed is in a valid to be destructed state which is obviously how your move constuctor or move assignment operator must be written
As for your question regarding why there is a check for joinable() in the destructor of std::thread is because the standard mandates it.
If a thread has not been joined then terminate must be called. Your argument that this check is redundant when a std::thread has been moved from is not valid for C++ because there is not a way for the compiler to track the ownership details in C++ the way it is possible in Rust. A similar argument can be made for unsafe code in Rust.
The
At least in cpp you _can_ take the plunge...
The
Ugh speaking of threads.. anyone knows a windows parallel to pthread_cancel?
Any tricks even...
MᏫᎻᎯᎷᎷᎬᎠ
You are confusing move semantics of C++ with ownership semantics in Rust. Rust transfers ownership. C++ transfers the contents of the object (ignoring Ref and other shared ownership concepts in Rust for simplifying the discussion)
So the C++ compiler can't figure out at a random point in your code whether the said object was copied from or moved from. The only thing it can assume is that an object to be destructed is in a valid to be destructed state which is obviously how your move constuctor or move assignment operator must be written
As for your question regarding why there is a check for joinable() in the destructor of std::thread is because the standard mandates it.
If a thread has not been joined then terminate must be called. Your argument that this check is redundant when a std::thread has been moved from is not valid for C++ because there is not a way for the compiler to track the ownership details in C++ the way it is possible in Rust. A similar argument can be made for unsafe code in Rust.
Does the standard restrict the generated optimized code?
Yeah, sure it there in the Dtor implementation, but is it obligated to generate the machine code for it, even if it has no effect?
MᏫᎻᎯᎷᎷᎬᎠ
Or at least: "Can it be optimized out if possible?"
Anonymous
Does the standard restrict the generated optimized code?
Yeah, sure it there in the Dtor implementation, but is it obligated to generate the machine code for it, even if it has no effect?
Why is optimization a concern for you? The compiler if it is smart enough to figure out that the check is redundant can optimize it. The standard just mandates the behavior of your code for the case where joinable is true. If your compiler can optimize away the joinable check and your code behaves the same way then this compiler is standard compliant as is a compiler which makes this redundant check even if it is obvious that the thread was moved from.
Ludovic 'Archivist'
Or at least: "Can it be optimized out if possible?"
If it was demonstrably the case, the "as if" rule allows destructors to be optimized away
MᏫᎻᎯᎷᎷᎬᎠ
auto sum = 0;
for(auto i=0; i<=100; ++i) sum++;
can be optimized to: sum += 100
I find such a smartness is not far from performing such little bit optimization
Ludovic 'Archivist'
but if there is any observable effect of the destructor, then it is not possible to optimize it away
Ludovic 'Archivist'
move semantics do not always match these conditions
Ludovic 'Archivist'
and in particular, it is for optimization reasons that jthread has side-effects whichever part of the destructor you reach, to avoid a branch in the most normal case of worker threads being routinely created and joined. If you want to be particular about what is allowed with your threading implementation, I suggest you implement that yourself
MᏫᎻᎯᎷᎷᎬᎠ
Why is optimization a concern for you? The compiler if it is smart enough to figure out that the check is redundant can optimize it. The standard just mandates the behavior of your code for the case where joinable is true. If your compiler can optimize away the joinable check and your code behaves the same way then this compiler is standard compliant as is a compiler which makes this redundant check even if it is obvious that the thread was moved from.
Well that's what is I looking for
hear that @unterumarmung!!!
Ludovic 'Archivist'
Well that's what is I looking for
hear that @unterumarmung!!!
jthreads joinability check is a side effect, so that cannot be optimized away
MᏫᎻᎯᎷᎷᎬᎠ
If it was demonstrably the case, the "as if" rule allows destructors to be optimized away
What is "as if" rule?
Ludovic 'Archivist'
What is "as if" rule?
Code must run "as if" on the C++ abstract machine, respecting sequence points, but it is not required to be exactly what the C++ abstract machine is if it behave "as if" on the abstract machine
Anonymous
jthreads joinability check is a side effect, so that cannot be optimized away
jthread is different. His question was about std::thread. As-if rule would perfectly apply to optimising out the joinable check. I don't think any implementation does it however
User Md Sakibul Hasan has 1/2 warnings; be careful!
Reason:
offtop
MᏫᎻᎯᎷᎷᎬᎠ
and in particular, it is for optimization reasons that jthread has side-effects whichever part of the destructor you reach, to avoid a branch in the most normal case of worker threads being routinely created and joined. If you want to be particular about what is allowed with your threading implementation, I suggest you implement that yourself
std::jthread and std::unique_ptr were just examples for the question
I only wanted to find out if Dtors can be optimized away generally
Ludovic 'Archivist'
jthread is different. His question was about std::thread. As-if rule would perfectly apply to optimising out the joinable check. I don't think any implementation does it however
Doesn't std::thread also perform a joinability check? as far as I know, this would also lead to OS side effects and hence be a sequence point that must happen
Ludovic 'Archivist'
std::jthread and std::unique_ptr were just examples for the question
I only wanted to find out if Dtors can be optimized away generally
yes, this may often require a noexcept context
Ludovic 'Archivist'
unique_ptr destructors cannot be optimized away if exceptions are allowed
MᏫᎻᎯᎷᎷᎬᎠ
MᏫᎻᎯᎷᎷᎬᎠ
unique_ptr destructors cannot be optimized away if exceptions are allowed
Do you mean allowed in the deleter of unique_ptr?
Anonymous
Doesn't std::thread also perform a joinability check? as far as I know, this would also lead to OS side effects and hence be a sequence point that must happen
If a compiler can guarantee that thread has been moved from, then optimising out the joinable check doesn't affect happens before relationship as the thread is no longer active (like I said am not sure if any compiler is smart enough to figure this out but). jthread is different in that it joins automatically on destruction which requires a joinable check.
Ludovic 'Archivist'
Do you mean allowed in the deleter of unique_ptr?
No I mean that since exceptions may be thrown that would require the deletion of a unique_ptr in an unknown state, the destructor cannot generally be optimized away in presence of exceptions
MᏫᎻᎯᎷᎷᎬᎠ
Do you mean allowed in the deleter of unique_ptr?
I noticed in unique_ptr dtor implementation that it has two overloads, one with noexcept and one without
How should the compiler differentiate which overload to select? Based on the Caller whether it's noexcept or not?