A traits class for (compound) pointers - beyond what std::pointer_traits offers

Question

This is a percolation of ideas which originated this SO question:

Compound pointer traits class with method generalizing make_shared and make_unique?

The std::pointer_traits class offers the following traits, basically:

Types: pointer, element_type, difference_type, and rebind (given a pointer-like type for pointing to T, get a pointer-like type for pointing to U)

Static methods:

• to_address - get the plain vanilla T* from some fancy pointer-to-T-like class, if possible
• pointer_to - opposite of to_address. This is a fishy method, since it's not clear what it means with respect to resource ownership.

I think it's useful to add at least two methods - for creating a pointer to a new object / array of objects, a-la std::make_shared and std::make_unique, and one for releasing ownership + getting the raw address. Here's my implementation:

#pragma once
#ifndef EXTRA_POINTER_TRAITS_HPP_
#define EXTRA_POINTER_TRAITS_HPP_

#include <memory>

template <typename Ptr>
struct extra_pointer_traits;

template <typename T>
struct extra_pointer_traits<T*>
{
    using ptr_type = T*;
    using element_type = T;

    static ptr_type make(size_t count) { return new T[count]; }
    static ptr_type make()             { return new T;        }
};

template <typename T>
struct extra_pointer_traits<T[]>
{
    using ptr_type = T[];
    using element_type = T;

    static T* make(size_t count) { return new T[count]; }
    static T* make()             { return new T;        }
};

template <typename T, class Deleter>
struct extra_pointer_traits<std::unique_ptr<T[], Deleter>>
{
    using ptr_type = std::unique_ptr<T[], Deleter>;
    using element_type = T;

    static T* release(ptr_type& ptr) { return ptr.release(); }
    static std::unique_ptr<T[], Deleter> make(size_t count)
    {
        return std::make_unique<T[]>(count);
    }
};


template <typename T, class Deleter>
struct extra_pointer_traits<std::unique_ptr<T, Deleter>>
{
    using ptr_type = std::unique_ptr<T, Deleter>;
    using element_type = T;

    static T* release(ptr_type& ptr) { return ptr.release(); }
    static std::unique_ptr<T, Deleter> make()
    {
        return std::make_unique<T>();
    }
};


template <typename T>
struct extra_pointer_traits<std::shared_ptr<T>>
{
    using ptr_type = std::shared_ptr<T>;
    using element_type = typename std::pointer_traits<ptr_type>::element_type;

    // No release()
    static std::shared_ptr<element_type[]> make(size_t count)
    {
        return std::make_shared<element_type[]>(count);
    }
    static std::shared_ptr<element_type> make()
    {
        return std::make_shared<element_type>();
    }
};

#endif // EXTRA_POINTER_TRAITS_HPP_

I'm considering suggesting something like this as an addition to the existing traits class the standards committe, but for now I've implemented it as a separate class.

Note: To clarify - these are not all possible template specializations for pointer-like classes in the standard library, there would be a few more.

Answer 1

First, size_t should be std::size_t everywhere.

Why don't the raw pointer/array cases have release()? Granted, it won't really change any ownership in reality, but it could conceptually.

static ptr_type make(size_t count) { return new T[count]; }
static ptr_type make()             { return new T;        }

I'm not sure this interface is a good idea as is. This only supports Ts with default constructors. What about constructor arguments:

template <typename... Args>
static ptr_type make(Args&&... args)
{
    return new T{std::forward<Args>(args)...};
}

But of course, if you do that, it conflicts with the make(std::size_t) overload. So you'd need a different name for that, like make_n() or something, maybe with an interface like:

template <typename... Args>
static ptr_type make_n(std::size_t count, Args&&... args)
{
    return new T[count]{std::forward<Args>(args)...};
}

However, what about the difference between T{...} and T(...)? Now you need overloads for those cases, too.

Now, as for the overall idea, I'm not a committee member, but I can tell you with absolute certainty that this will never be accepted.

First, what actual problem in use is this supposed to solve? What is an actual use case where this is necessary and offers a significant improvement? I can't think of any situation where this will be useful. Certainly not one that's generalizable, which is mandatory for a standard library addition.

Generally speaking, memory management should be handled by containers, and containers use allocators, and this has no allocator support whatsoever.

Even worse, it hides the allocation method from client code... which is disastrous because you need to know how something was allocated to know how to DEallocate it. As it is, your interface offers a "handy" way to allocate memory, but no way to free it, and in fact goes out of its way to make code less safe by stripping ownership from smart pointers with the release() function.

In summary, I see no general gain from this, and plenty of dangerous drawbacks.

Answer 2

I'm with you that std::pointer_traits and C++ standard library smart pointers in general have some drawbacks (e.g. ownership semantics of pointer_to) that might need to be addressed.

That said, I don't think that this implementation is working towards that goal:

• Memory management: Different forms of extra_pointer_traits<T>::make acquire pointers to memory, but most specializations have no way to release said memory (and the std::unique_ptr one only releases ownership, not the backing memory).

  This is no "trivial" problem, either: When given a T* (allocated using one of the overloads of extra_pointer_traits<T*>::make), do you know whether to call delete or delete[] on it?

  And this is just the tip of the iceberg: Once allocators enter the picture there is no general way of keeping track how to delete every pointer without somehow storing a reference to the allocator with each pointer.

• Uniformity: There's no clear standard feature set. Some specializations provide make(), others provide make(size_t), some provide release() - but there is no easy way (other than failure of compilation) to query which operations are actually available.

  For example: You cannot simply call make(), as extra_pointer_traits<std::unique_ptr<T[], Deleter>> doesn't provide it.

• Trait deduction: Most standard library traits have an ability to deduce traits from any type as long as said type adheres to some interface (e.g. std::iterator_traits automatically gives the correct traits if a class implements value_type, pointer, reference, difference_type and iterator_category).

  There doesn't seem to be an easy way to generally deduce make() or similar for any custom pointer-like type.

• Object construction: Ignoring the memory release problems mentioned above, some types simply don't have a default constructor (or any public constructors, for that matter), which means extra_pointer_traits<PointerType>::make overloads now compile conditionally not only on the pointer type itself, but also on the pointees type. This seems counter-intuitive on a trait that should be as general as possible.

  Yes, some of these problems (non-default constructors) could be overcome with perfect forwarding of parameters, but others (non-public constructors, T(...) vs T{...}) are unsolvable (without modifying the pointee) or require additional design space (e.g. special functions for make_array, make_with_braces, make_with_parens, ...).

  Then you'd again need special handling for some cases, e.g. if the pointee is of type void (possibly cv-qualified). This means you get an combinatorial explosion of specializations (number of pointer-like types times types requiring soecial handling).

• Ownership semantics: extra_pointer_trais<T>::make overloads always create a new owning pointer - even for pointer types (e.g. raw pointers) that don't have any concrete ownership semantics associated with themselves. This is just waiting for ownership conflicts (and all the surrounding problems, e.g. memory leaks, use-after-free, dangling pointers, ...) to happen.

• Incomplete specializations: std::weak_ptr as another standard library pointer-like type is missing, as are std::shared_ptr<T[]> (which might be different from std::shared_ptr<T>) and T[N].

  Also, specializations for const and volatile qualified pointer-like types are missing. What specialization would be used for a const std::unique_ptr<T>? What about const volatile T* const volatile?

• Allocator support: Most of the time, the standard library goes out of its way to allow users to bring their own allocators, which allows for some cool features that would otherwise be unavailable (e.g. control over memory allocations at an overarching level, relocatable heaps or tracing object collection). There is currently no support for allocators inside extra_pointer_traits.

As glimpsed from this overview, the implementation introduces more problems than it solves (and the latter would have to be defined more clearly, as it currently is far too vague and open to interpretation).

As long as these points remain unaddressed (no pun intended), I can't see any committee approving of this.

Food for thoughts:

There are several orthogonal concerns that pointers have to deal with:

• Allocation: How is memory acquired and released?

• Lifetime: What object is at that pointer referring to?

• Ownership: When does the memory get acquired/released and who is responsible for doing so?

• Representation (aka address model): How is the pointer value represented in memory? Examples: An address (raw pointer), an offset (e.g. boost::offset_ptr) or segmented (16 bit far pointers).

Some of my personal gripes with the standard library arise from the fact that these concerns are not cleanly separated, e.g.

• allocators have to deal with types instead of just managing memory (mixing of allocation and lifetime concerns). This makes it hard to reuse allocators for different types, and tightly couples them to the implementation of the type that might be placed in the allocated memory.

• std::shared_ptr by itself is only usable with raw pointer representation (mixing ownership, representation and lifetime). There's no way to have a shared_ptr contain a boost::offset_ptr internally, or to know whether the object being pointed to is actually initialized.

• std::unique_ptr is slightly better off: It can be used with arbitrary pointer representations (via Deleter::pointer), but it is hard to do so. It still mixes ownership and lifetime, though: There will be problems with a std::unique_ptr<T> (with T not being void) referring to uninitialized memory upon assignment/destruction.

The extra_pointer_traits implementation goes beyond that: It mixes allocation, ownership and lifetime concerns, and does so in a fashion that none of those concerns are fully realized.