Should std::unique_ptr be permitted

Question

This is a very simple question. Consider the following code:

#include <iostream>
#include <memory>

typedef std::unique_ptr<void> UniqueVoidPtr;

int main() {
    UniqueVoidPtr p(new int);
    return 0;
}

Compiling with cygwin (g++ 4.5.3) with the following command g++ -std=c++0x -o prog file.cpp works just fine. However, compiling with the microsoft compiler (either VS 2010 or 2013) I get this error:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\memory(2067) : error C2070: 'void': illegal sizeof operand
        C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\memory(2066) : while compiling class template member function 'void std::default_delete<_Ty>::operator ()(_Ty *) const'
        with
        [
            _Ty=void
        ]
        C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\type_traits(650) : see reference to class template instantiation 'std::default_delete<_Ty>' being compiled
        with
        [
            _Ty=void
        ]
        C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\memory(2193) : see reference to class template instantiation 'std::tr1::is_empty<_Ty>' being compiled
        with
        [
            _Ty=std::default_delete<void>
        ]
        foo1.cpp(7) : see reference to class template instantiation 'std::unique_ptr<_Ty>' being compiled
        with
        [
            _Ty=void
        ]

Is this expected? I'm writing a class where I wanted to have a unique pointer in the in the class. While trying to work out the semantics of a move constructor for the class, I ran into this (I assume because I finally got my move constructor coded correctly: i.e. the other errors were fixed).

The default deleter in `std::unique_ptr` will call `delete` on the pointer, what do you expect to happen when you call delete on a `void*`? — David Rodríguez - dribeas, Nov 07 '13 at 16:16
@DavidRodríguez-dribeas: Actually, the `default_delete` shall not call `delete` on a `void*` (see ixSci's answer). In addition, if it did call delete on a `void*`, then that would be UB (see Nevin's answer) in which case one could expect anything (not necessarilly an error). — Cassio Neri, Nov 07 '13 at 17:42
related: https://stackoverflow.com/questions/39288891/why-is-shared-ptrvoid-legal-while-unique-ptrvoid-is-ill-formed — Ciro Santilli OurBigBook.com, Oct 26 '18 at 13:47

score 23 · Accepted Answer · edited Oct 27 '16 at 22:59

23

MSVC is right while GCC is wrong:

Standard(3.9/5):

Incompletely-defined object types and the void types are incomplete types

Standard(20.7.1.1.2/4):

If T is an incomplete type, the program is ill-formed

edited Oct 27 '16 at 22:59

Ryan Haining

35,360
15
114
174

answered Nov 07 '13 at 16:40

ixSci

13,100
5
45
79

22

+1 Having this behavior be ill-formed instead of undefined, was an intentional design goal of `unique_ptr`. Doing the same thing with the deprecated `auto_ptr` is undefined behavior. The big differences is that ill-formed requires a diagnostic. Undefined behavior can do anything, silently. All this being said, `unique_ptr` is perfectly valid if your `custom_deleter` can handle the disposal of the `void*`. – Howard Hinnant Nov 07 '13 at 18:25

Jonathan Wakely · Answer 2 · 2016-01-30T11:50:40.633

GCC actually has code to prevent it, but it didn't work until recently.

GCC's unique_ptr has a static assertion in default_deleter::operator() that should reject incomplete types:

    static_assert(sizeof(_Tp)>0,
                  "can't delete pointer to incomplete type");

However, as an extension GCC supports sizeof(void), so the assertion doesn't fail, and because it appears in a system header doesn't even give a warning (unless you use -Wsystem-headers).

I discovered this problem myself recently so to fix it I added this 10 days ago:

    static_assert(!is_void<_Tp>::value,
                  "can't delete pointer to incomplete type");

So using the latest code on trunk your example fails to compile, as required by the standard.

score 8 · Answer 3 · answered Nov 07 '13 at 16:31

8

The question boils down to:

void* p = new int;
delete p;

Looking at n3797 5.3.5 Delete, I believe the delete p is undefined behavior because of mismatched types, so either compiler behavior is acceptable as the code is buggy.

Note: this differs from shared_ptr<void>, as that uses type erasure to keep track of the original type of pointer passed in.

answered Nov 07 '13 at 16:31

Nevin

4,595
18
24

How shared_ptr differs? It uses type erasure for deleter, not a pointer type – ixSci Nov 07 '13 at 16:34
2

@ixSci Look at an implementation? The deleter is templated on the original pointer type. – gx_ Nov 07 '13 at 16:45
3

You're right by saying that your code snippet above yields UB. However, the `default_delete` should not call `delete` if the pointed type is incomplete otherwise the program is ill-formed (See ixSci's answer). – Cassio Neri Nov 07 '13 at 17:31

score 3 · Answer 4 · answered Mar 28 '16 at 03:27

Don't delete variables of void *。

If you want to work with something like Win32 Handles, please provide a custom deleter.

For example:

void HandleDeleter(HANDLE h)
{
    if (h) CloseHandle(h);
}

using UniHandle = unique_ptr<void, function<void(HANDLE)>>;

Then:

UniHandle ptr(..., HandleDeleter);

Should std::unique_ptr be permitted

4 Answers4

Linked

Related