Timeline for C++ UniquePtr Implementation
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2023 at 2:11 | comment | added | jdav22 |
Revisiting this a few months later, one quick note on Microsoft's compiler not supporting [[no_unique_address]] - we can do [[msvc::no_unique_address]] to make it work :)
|
|
| Jul 26, 2023 at 17:20 | comment | added | jdav22 | Thanks @chrysante, all makes sense! Again appreciate the help | |
| Jul 26, 2023 at 7:53 | comment | added | chrysante |
3. By requiring our deleters to be convertible, we make them sign a contract. By making Deleter<U> be convertible to Deleter<T>, the author of Deleter promises that Deleter<T> can delete pointer of type U* after being converted to T*. And the fact that DefaultDeleter<T> is empty does not mean that all possible deleters are empty. 4. It doesn't matter here if we inherit privately or publicly. I just did it because data hiding is generally a good habit, but in this case it doesn't really change anything.
|
|
| Jul 26, 2023 at 7:40 | comment | added | chrysante |
@jdav22 1. I assume it might be to prevent accidental copies of the deleter, but I don't really know. I was just following the standard here. 2. There is no point in calling std::move, since argument and parameter are both the same l-value-reference type. std::move would cast to rvalue-reference and that be implicitly be converted to lvalue again.
|
|
| Jul 26, 2023 at 0:27 | comment | added | jdav22 | 3. Why do we need a conversion constructor for the deleter if it's an empty type? 4. why does the DeleterHolder specialization for classes need to inherit privately from Deleter? Is this to ensure DeleterHolder has access to it, but not UniquePtr itself? | |
| Jul 26, 2023 at 0:27 | comment | added | jdav22 |
Thanks for the time and effort to review! Couple questions: 1. In the enable_if call for the non-reference deleter, you have the condition std::is_convertible_v<E, Deleter>, but for the reference deleter the condition is std::is_same_v<E, Deleter>. Why can't the reference deleter also check if the deleter is convertible? Why the tighter constraint here? 2. Why should the non-reference version call std::move() on the deleter, but the reference version shouldn't? (continued in next comment)
|
|
| Jul 25, 2023 at 14:40 | history | edited | chrysante | CC BY-SA 4.0 |
added 29 characters in body
|
| Jul 25, 2023 at 14:30 | comment | added | Deduplicator | One implementation for empty non-final class types, one for the rest... | |
| Jul 25, 2023 at 14:16 | comment | added | chrysante | @Deduplicator Thanks for pointing this out, I hoped there was a way to do it without two implementations for class types and non-class types. | |
| Jul 25, 2023 at 14:15 | history | edited | chrysante | CC BY-SA 4.0 |
Fixed use of empty base class optimization
|
| Jul 25, 2023 at 14:04 | comment | added | Deduplicator |
DeleterHolder is not empty, as it has a (though empty) member which is not a base. Still, you are on the right track for using EBO where [[no_unique_address]] is not honored.
|
|
| Jul 25, 2023 at 9:21 | history | answered | chrysante | CC BY-SA 4.0 |