Skip to content

Bug in either C++17 (maybe 20?) spec, or llvm implementation, shared_ptr #54365

@timprepscius

Description

@timprepscius

Hey there,

I'm not sure where to post this, I feel like I should be posting to some spec committee. Not sure.

In the Xcode 12.5.1 std memory, there is the snippet:

 template <class _Tp, class _Alloc> void __shared_ptr_emplace<_Tp, _Alloc>::__on_zero_shared() _NOEXCEPT { __data_.second().~_Tp(); } 

What this snippet does, is when a control block of a shared_ptr detects that there are no more references, it destructs/destroys the object.

Right now the code snippet calls the destructor explicitly, which leaves out the exciting things the allocator might do before destructing the object.

I believe this code snippet should be something like this (writing off the top of my head):

using value_allocator = _Alloc::template rebind<the_value_type>::other; value_allocator allocator; allocator.destroy(&__data_.second()); 

Or using allocator_traits, or what not. But in the end, not calling the destructor, but rather using the allocator to call the destructor.


If this were the case I could write an allocator which might do something like:

void destroy(T *p) { object_is_about_to_be_destroyed_template_function(p); other_allocator.destroy(p); } 

Should I take this issue somewhere else? Does anyone know who I might talk to about this.


There is, of course, a work around, but it isn't pretty, and uses classes which I probably should be using.

Metadata

Metadata

Assignees

No one assigned

    Labels

    libc++libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions