mjhjmtu

C++17 adds std::destroy_at, but there isn't any std::construct_at counterpart. Why is that? Couldn't it be implemented as simply as the following?

template <typename T, typename... Args>
T* construct_at(void* addr, Args&&... args) 
 return new (addr) T(std::forward<Args>(args)...);

Which would enable to avoid that not-entirely-natural placement new syntax:

void* ptr = ::operator new(sizeof(int));
int* pi = construct_at<int>(ptr, 1); // instead of 'new (ptr) int(1);'
std::cout << *pi;
std::destroy_at(pi);
::operator delete(ptr);

std::destroy_at provides two objective improvements over a direct destructor call:

1. 
   

   It reduces redundancy:

   
   
   

   T *ptr = new T;
   //Insert 1000 lines of code here.
   ptr->~T(); //What type was that again?
   

   
   
   

   Sure, we'd all prefer to just wrap it in a unique_ptr and be done with it, but if that can't happen for some reason, putting T there is an element of redundancy. If we change the type to U, we now have to change the destructor call or things break. Using std::destroy_at(ptr) removes the need to change the same thing in two places.

   
   
   

   DRY is good.

   
   


2. 
   

   It makes this easy:

   
   
   

   auto ptr = allocates_an_object(...);
   //Insert code here
   ptr->~???; //What type is that again?
   

   
   
   

   If we deduced the type of the pointer, then deleting it becomes kind of hard. You can't do ptr->~decltype(ptr)(); since the C++ parser doesn't work that way. Not only that, decltype deduces the type as a pointer, so you'd need to remove a pointer indirection from the deduced type. Leading you to:

   
   
   

   auto ptr = allocates_an_object(...);
   //Insert code here
   using delete_type = std::remove_pointer_t<decltype(ptr)>;
   ptr->~delete_type();
   

   
   
   

   And who wants to type that?

   
   

By contrast, your hypothetical std::construct_at provides no objective improvements over placement new. You have to state the type you're creating in both cases. The parameters to the constructor have to be provided in both cases. The pointer to the memory has to be provided in both cases.

So there is no need being solved by your hypothetical std::construct_at.

And it is objectively less capable than placement new. You can do this:

auto ptr1 = new(mem1) T;
auto ptr2 = new(mem2) T;

These are different. In the first case, the object is default-initialized, which may leave it uninitialized. In the second case, the object is value-initialized.

Your hypothetical std::construct_at cannot allow you to pick which one you want. It can have code that performs default initialization if you provide no parameters, but it would then be unable to provide a version for value initialization. And it could value initialize with no parameters, but then you couldn't default initialize the object.

There is such a thing, but not named like you might expect:

• uninitialized_copy
  copies a range of objects to an uninitialized area of memory




• uninitialized_copy_n
  (C++11)
  copies a number of objects to an uninitialized area of memory
  (function template)




• uninitialized_fill
  copies an object to an uninitialized area of memory, defined by a range
  (function template)



• 
  uninitialized_fill_n
  copies an object to an uninitialized area of memory, defined by a start and a count
  (function template)


• 
  uninitialized_move
  (C++17)
  moves a range of objects to an uninitialized area of memory
  (function template)


• 
  uninitialized_move_n
  (C++17)
  moves a number of objects to an uninitialized area of memory
  (function template)


• 
  uninitialized_default_construct
  (C++17)
  constructs objects by default-initialization in an uninitialized area of memory, defined by a range
  (function template)


• 
  uninitialized_default_construct_n
  (C++17)
  constructs objects by default-initialization in an uninitialized area of memory, defined by a start and a count
  (function template)


• 
  uninitialized_value_construct
  (C++17)
  constructs objects by value-initialization in an uninitialized area of memory, defined by a range
  (function template)


• 
  uninitialized_value_construct_n
  (C++17)
  constructs objects by value-initialization in an uninitialized area of memory, defined by a start and a count

There is std::allocator_traits::construct. There used to be one more in std::allocator, but that got removed, rationale in standards committee paper D0174R0.

construct does not seem to provide any syntactic sugar. Moreover it is less efficient than a placement new. Binding to reference arguments cause temporary materialization and extra move/copy construction:

struct heavy
 unsigned char[4096];
 heavy(const heavy&);
;
heavy make_heavy(); // Return a pr-value
auto loc = ::operator new(sizeof(heavy));
// Equivalently: unsigned char loc[sizeof(heavy)];

auto p = construct<heavy>(loc,make_heavy()); // The pr-value returned by
 // make_heavy is bound to the second argument,
 // and then this arugment is copied in the body of construct.

auto p2 = new(loc) auto(make_heavy()); // Heavy is directly constructed at loc
 //... and this is simpler to write!

Unfortunately there isn't any way to avoid these extra copy/move construction when calling a function. Forwarding is almost perfect.

On the other hand, construct_at in the library could complete the standard library vocabulary.