Is it OK to make a placement new on memory managed by a smart pointer?
Context
For test purpose, I need to construct an object on non-zero memory. This could be done with:
{
struct Type { /* IRL not empty */};
std::array<unsigned char, sizeof(Type)> non_zero_memory;
non_zero_memory.fill(0xC5);
auto const& t = *new(non_zero_memory.data()) Type;
// t refers to a valid Type whose initialization has completed.
t.~Type();
}
Since this is tedious and made multiple times, I'd like to provide a function returning a smart pointer to such a Type
instance. I came up with the following, but I fear undefined behavior lurk somewhere.
Question
Is the following program well defined? Especially, is the fact that a std::byte
has been allocated but a Type
of equivalent size is freed an issue?
#include <cstddef>
#include <memory>
#include <algorithm>
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::make_unique<std::byte>(size);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
return std::shared_ptr<T>(new (memory.release()) T());
}
int main()
{
struct Type { unsigned value = 0; ~Type() {} }; // could be something else
auto t = on_non_zero_memory<Type>();
return t->value;
}
Live demo
c++ language-lawyer c++17 smart-pointers undefined-behavior
|
show 15 more comments
Context
For test purpose, I need to construct an object on non-zero memory. This could be done with:
{
struct Type { /* IRL not empty */};
std::array<unsigned char, sizeof(Type)> non_zero_memory;
non_zero_memory.fill(0xC5);
auto const& t = *new(non_zero_memory.data()) Type;
// t refers to a valid Type whose initialization has completed.
t.~Type();
}
Since this is tedious and made multiple times, I'd like to provide a function returning a smart pointer to such a Type
instance. I came up with the following, but I fear undefined behavior lurk somewhere.
Question
Is the following program well defined? Especially, is the fact that a std::byte
has been allocated but a Type
of equivalent size is freed an issue?
#include <cstddef>
#include <memory>
#include <algorithm>
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::make_unique<std::byte>(size);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
return std::shared_ptr<T>(new (memory.release()) T());
}
int main()
{
struct Type { unsigned value = 0; ~Type() {} }; // could be something else
auto t = on_non_zero_memory<Type>();
return t->value;
}
Live demo
c++ language-lawyer c++17 smart-pointers undefined-behavior
1
There are rules about objects replacing other objects, and rules about trivial objects not needing explicit destruction - I'll let someone find the proper wording to prove you're safe though
– Lightness Races in Orbit
2 days ago
The memory isn't really managed by a smart pointer since yourelease
d it.
– François Andrieux
2 days ago
@FrançoisAndrieux only to let it be managed by another smart pointer though.
– YSC
2 days ago
@LightnessRacesinOrbitType
is not necessarily that simple. Let me correct that... Q fixed.
– YSC
2 days ago
2
The first code snippet is generally incorrect, since you do not care proper alignment for objects of typeType
. Better to usestd::aligned_storage_t<sizeof(Type), alignof(Type)>
thanstd::array
of chars.
– Daniel Langr
2 days ago
|
show 15 more comments
Context
For test purpose, I need to construct an object on non-zero memory. This could be done with:
{
struct Type { /* IRL not empty */};
std::array<unsigned char, sizeof(Type)> non_zero_memory;
non_zero_memory.fill(0xC5);
auto const& t = *new(non_zero_memory.data()) Type;
// t refers to a valid Type whose initialization has completed.
t.~Type();
}
Since this is tedious and made multiple times, I'd like to provide a function returning a smart pointer to such a Type
instance. I came up with the following, but I fear undefined behavior lurk somewhere.
Question
Is the following program well defined? Especially, is the fact that a std::byte
has been allocated but a Type
of equivalent size is freed an issue?
#include <cstddef>
#include <memory>
#include <algorithm>
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::make_unique<std::byte>(size);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
return std::shared_ptr<T>(new (memory.release()) T());
}
int main()
{
struct Type { unsigned value = 0; ~Type() {} }; // could be something else
auto t = on_non_zero_memory<Type>();
return t->value;
}
Live demo
c++ language-lawyer c++17 smart-pointers undefined-behavior
Context
For test purpose, I need to construct an object on non-zero memory. This could be done with:
{
struct Type { /* IRL not empty */};
std::array<unsigned char, sizeof(Type)> non_zero_memory;
non_zero_memory.fill(0xC5);
auto const& t = *new(non_zero_memory.data()) Type;
// t refers to a valid Type whose initialization has completed.
t.~Type();
}
Since this is tedious and made multiple times, I'd like to provide a function returning a smart pointer to such a Type
instance. I came up with the following, but I fear undefined behavior lurk somewhere.
Question
Is the following program well defined? Especially, is the fact that a std::byte
has been allocated but a Type
of equivalent size is freed an issue?
#include <cstddef>
#include <memory>
#include <algorithm>
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::make_unique<std::byte>(size);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
return std::shared_ptr<T>(new (memory.release()) T());
}
int main()
{
struct Type { unsigned value = 0; ~Type() {} }; // could be something else
auto t = on_non_zero_memory<Type>();
return t->value;
}
Live demo
c++ language-lawyer c++17 smart-pointers undefined-behavior
c++ language-lawyer c++17 smart-pointers undefined-behavior
edited 2 days ago
YSC
asked 2 days ago
YSCYSC
21.1k34797
21.1k34797
1
There are rules about objects replacing other objects, and rules about trivial objects not needing explicit destruction - I'll let someone find the proper wording to prove you're safe though
– Lightness Races in Orbit
2 days ago
The memory isn't really managed by a smart pointer since yourelease
d it.
– François Andrieux
2 days ago
@FrançoisAndrieux only to let it be managed by another smart pointer though.
– YSC
2 days ago
@LightnessRacesinOrbitType
is not necessarily that simple. Let me correct that... Q fixed.
– YSC
2 days ago
2
The first code snippet is generally incorrect, since you do not care proper alignment for objects of typeType
. Better to usestd::aligned_storage_t<sizeof(Type), alignof(Type)>
thanstd::array
of chars.
– Daniel Langr
2 days ago
|
show 15 more comments
1
There are rules about objects replacing other objects, and rules about trivial objects not needing explicit destruction - I'll let someone find the proper wording to prove you're safe though
– Lightness Races in Orbit
2 days ago
The memory isn't really managed by a smart pointer since yourelease
d it.
– François Andrieux
2 days ago
@FrançoisAndrieux only to let it be managed by another smart pointer though.
– YSC
2 days ago
@LightnessRacesinOrbitType
is not necessarily that simple. Let me correct that... Q fixed.
– YSC
2 days ago
2
The first code snippet is generally incorrect, since you do not care proper alignment for objects of typeType
. Better to usestd::aligned_storage_t<sizeof(Type), alignof(Type)>
thanstd::array
of chars.
– Daniel Langr
2 days ago
1
1
There are rules about objects replacing other objects, and rules about trivial objects not needing explicit destruction - I'll let someone find the proper wording to prove you're safe though
– Lightness Races in Orbit
2 days ago
There are rules about objects replacing other objects, and rules about trivial objects not needing explicit destruction - I'll let someone find the proper wording to prove you're safe though
– Lightness Races in Orbit
2 days ago
The memory isn't really managed by a smart pointer since you
release
d it.– François Andrieux
2 days ago
The memory isn't really managed by a smart pointer since you
release
d it.– François Andrieux
2 days ago
@FrançoisAndrieux only to let it be managed by another smart pointer though.
– YSC
2 days ago
@FrançoisAndrieux only to let it be managed by another smart pointer though.
– YSC
2 days ago
@LightnessRacesinOrbit
Type
is not necessarily that simple. Let me correct that... Q fixed.– YSC
2 days ago
@LightnessRacesinOrbit
Type
is not necessarily that simple. Let me correct that... Q fixed.– YSC
2 days ago
2
2
The first code snippet is generally incorrect, since you do not care proper alignment for objects of type
Type
. Better to use std::aligned_storage_t<sizeof(Type), alignof(Type)>
than std::array
of chars.– Daniel Langr
2 days ago
The first code snippet is generally incorrect, since you do not care proper alignment for objects of type
Type
. Better to use std::aligned_storage_t<sizeof(Type), alignof(Type)>
than std::array
of chars.– Daniel Langr
2 days ago
|
show 15 more comments
2 Answers
2
active
oldest
votes
This program is not well defined.
The rule is that if a type has a trivial destructor (See this), you don't need to call it. So, this:
return std::shared_ptr<T>(new (memory.release()) T());
is almost correct. It omits the destructor of the sizeof(T)
std::byte
s, which is fine, constructs a new T
in the memory, which is fine, and then when the shared_ptr
is ready to delete, it calls delete this->get();
, which is wrong. That first deconstructs a T
, but then it deallocates a T
instead of a std::byte
, which will probably (undefined) not work.
C++ standard §8.5.2.4p8 [expr.new]
A new-expression may obtain storage for the object by calling an allocation function. [...] If the allocated type is an array type, the allocation function's name is
operator new
.
(All those "may"s are because implementations are allowed to merge adjacent new expressions and only call operator new
for one of them, but this isn't the case as new
only happens once (In make_unique
))
And part 11 of the same section:
When a new-expression calls an allocation function and that allocation has not been extended, the new-expression passes the amount of space requested to the allocation function as the first argument of type
std::size_t
. That argument shall be no less than the size of the object being created; it may be greater than the size of the object being created only if the object is an array. For arrays ofchar
,unsigned char
, andstd::byte
, the difference between the result of the new-expression and the address returned by the
allocation function shall be an integral multiple of the strictest fundamental alignment requirement (6.6.5) of any object type whose size is no greater than the size of the array being created. [Note: Because allocation
functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating
character arrays into which objects of other types will later be placed. — end note ]
If you read §21.6.2 [new.delete.array], you see that the default operator new
and operator delete
do the exact same things as operator new
and operator delete
, the problem is we don't know the size passed to it, and it is probably more than what delete ((T*) object)
calls (to store the size).
Looking at what delete-expressions do:
§8.5.2.5p8 [expr.delete]
[...] delete-expression will invoke the destructor (if any) for [...] the elements of the array being deleted
p7.1
If the allocation call for the new-expression for the object to be deleted was not omitted [...], the delete-expression shall call a deallocation function (6.6.4.4.2). The value returned from the allocation call of the new-expression shall be passed as the first argument to the deallocation function.
Since std::byte
does not have a destructor, we can safely call delete
, as it will not do anything other than call the deallocate function (operator delete
). We just have to reinterpret it back to std::byte*
, and we will get back what new
returned.
Another problem is that there is a memory leak if the constructor of T
throws. A simple fix is to placement new
while the memory is still owned by the std::unique_ptr
, so even if it does throw it will call delete
properly.
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
delete reinterpret_cast<std::byte*>(ptr);
});
The first placement new
ends the lifetime of the sizeof(T)
std::byte
s and starts the lifetime of a new T
object at the same address, as according to §6.6.3p5 [basic.life]
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. [...]
Then when it is being deleted, the lifetime of T
ends by an explicit call of the destructor, and then according to the above, the delete-expression deallocates the storage.
This leads to the question of:
What if the storage class wasn't std::byte
, and was not trivially destructible? Like, for example, we were using a non-trivial union as the storage.
Calling delete reinterpret_cast<T*>(ptr)
would call the destructor on something that is not an object. This is clearly undefined behaviour, and is according to §6.6.3p6 [basic.life]
Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [...], any pointer that represents the address of the storage location where the object will be or
was located may be used but only in limited ways. [...] The program has undefined behavior if: the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression
So to use it like above, we have to construct it just to destruct it again.
The default constructor probably works fine. The usual semantics are "create an object that can be destructed", which is exactly what we want. Use std::uninitialized_default_construct_n
to construct them all to then immediately destruct them:
// Assuming we called `new StorageClass[n]` to allocate
ptr->~T();
auto* as_storage = reinterpret_cast<StorageClass*>(ptr);
std::uninitialized_default_construct_n(as_storage, n);
delete as_storage;
We can also call operator new
and operator delete
ourselves:
static void byte_deleter(std::byte* ptr) {
return ::operator delete(reinterpret_cast<void*>(ptr));
}
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::unique_ptr<std::byte, void(*)(std::byte*)>(
reinterpret_cast<std::byte*>(::operator new(size)),
&::byte_deleter
);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
::operator delete(ptr, sizeof(T));
// ^~~~~~~~~ optional
});
}
But this looks a lot like std::malloc
and std::free
.
A third solution might be to use std::aligned_storage
as the type given to new
, and have the deleter work as with std::byte
because the aligned storage is a trivial aggregate.
Alignment is only needed for over-aligned types though.
– eerorika
2 days ago
2
@eerorika I thought it was UB to access (e.g) anint
with alignment of 4 if it was not on a 4-byte boundary?
– Artyer
2 days ago
3
Since this is a language lawyer question, it would be nice to have some form of authoritative source backing up the claims made.
– François Andrieux
2 days ago
1
@Artyer check virgesmith's comment on the question. I would suggest fixing the exception safety in your answer for a complete example. François's comment after it has the solution.
– eerorika
2 days ago
2
There is no destructor forstd::byte
so no non static member is being called.std::byte
is defined asenum class byte : unsigned char {} ;
so it is just achar
– NathanOliver
2 days ago
|
show 10 more comments
std::shared_ptr<T>(new (memory.release()) T())
Is undefined behavior. The memory that was acquired by memory
was for a std::byte
but the shared_ptr
's deleter is doing to call delete
on a pointer to T
. Since the pointer no longer has the same type you can't call delete on it per [expr.delete]/2
In a single-object delete expression, the value of the operand of delete may be a null pointer value, a pointer to a non-array object created by a previous new-expression, or a pointer to a subobject representing a base class of such an object. If not, the behavior is undefined.
You would have to provide the shared_ptr
with a custom deleter that destroys T
and then casts the pointer back to its source type and call delete
on that.
It should also be noted that new (memory.release()) T()
itself will be undefined if memory
allocated a type that has non trivial destruction. You would have to call the destructor on the pointer from memory.release()
first before you reuse it's memory.
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
yesterday
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54095233%2fis-it-ok-to-make-a-placement-new-on-memory-managed-by-a-smart-pointer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
This program is not well defined.
The rule is that if a type has a trivial destructor (See this), you don't need to call it. So, this:
return std::shared_ptr<T>(new (memory.release()) T());
is almost correct. It omits the destructor of the sizeof(T)
std::byte
s, which is fine, constructs a new T
in the memory, which is fine, and then when the shared_ptr
is ready to delete, it calls delete this->get();
, which is wrong. That first deconstructs a T
, but then it deallocates a T
instead of a std::byte
, which will probably (undefined) not work.
C++ standard §8.5.2.4p8 [expr.new]
A new-expression may obtain storage for the object by calling an allocation function. [...] If the allocated type is an array type, the allocation function's name is
operator new
.
(All those "may"s are because implementations are allowed to merge adjacent new expressions and only call operator new
for one of them, but this isn't the case as new
only happens once (In make_unique
))
And part 11 of the same section:
When a new-expression calls an allocation function and that allocation has not been extended, the new-expression passes the amount of space requested to the allocation function as the first argument of type
std::size_t
. That argument shall be no less than the size of the object being created; it may be greater than the size of the object being created only if the object is an array. For arrays ofchar
,unsigned char
, andstd::byte
, the difference between the result of the new-expression and the address returned by the
allocation function shall be an integral multiple of the strictest fundamental alignment requirement (6.6.5) of any object type whose size is no greater than the size of the array being created. [Note: Because allocation
functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating
character arrays into which objects of other types will later be placed. — end note ]
If you read §21.6.2 [new.delete.array], you see that the default operator new
and operator delete
do the exact same things as operator new
and operator delete
, the problem is we don't know the size passed to it, and it is probably more than what delete ((T*) object)
calls (to store the size).
Looking at what delete-expressions do:
§8.5.2.5p8 [expr.delete]
[...] delete-expression will invoke the destructor (if any) for [...] the elements of the array being deleted
p7.1
If the allocation call for the new-expression for the object to be deleted was not omitted [...], the delete-expression shall call a deallocation function (6.6.4.4.2). The value returned from the allocation call of the new-expression shall be passed as the first argument to the deallocation function.
Since std::byte
does not have a destructor, we can safely call delete
, as it will not do anything other than call the deallocate function (operator delete
). We just have to reinterpret it back to std::byte*
, and we will get back what new
returned.
Another problem is that there is a memory leak if the constructor of T
throws. A simple fix is to placement new
while the memory is still owned by the std::unique_ptr
, so even if it does throw it will call delete
properly.
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
delete reinterpret_cast<std::byte*>(ptr);
});
The first placement new
ends the lifetime of the sizeof(T)
std::byte
s and starts the lifetime of a new T
object at the same address, as according to §6.6.3p5 [basic.life]
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. [...]
Then when it is being deleted, the lifetime of T
ends by an explicit call of the destructor, and then according to the above, the delete-expression deallocates the storage.
This leads to the question of:
What if the storage class wasn't std::byte
, and was not trivially destructible? Like, for example, we were using a non-trivial union as the storage.
Calling delete reinterpret_cast<T*>(ptr)
would call the destructor on something that is not an object. This is clearly undefined behaviour, and is according to §6.6.3p6 [basic.life]
Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [...], any pointer that represents the address of the storage location where the object will be or
was located may be used but only in limited ways. [...] The program has undefined behavior if: the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression
So to use it like above, we have to construct it just to destruct it again.
The default constructor probably works fine. The usual semantics are "create an object that can be destructed", which is exactly what we want. Use std::uninitialized_default_construct_n
to construct them all to then immediately destruct them:
// Assuming we called `new StorageClass[n]` to allocate
ptr->~T();
auto* as_storage = reinterpret_cast<StorageClass*>(ptr);
std::uninitialized_default_construct_n(as_storage, n);
delete as_storage;
We can also call operator new
and operator delete
ourselves:
static void byte_deleter(std::byte* ptr) {
return ::operator delete(reinterpret_cast<void*>(ptr));
}
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::unique_ptr<std::byte, void(*)(std::byte*)>(
reinterpret_cast<std::byte*>(::operator new(size)),
&::byte_deleter
);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
::operator delete(ptr, sizeof(T));
// ^~~~~~~~~ optional
});
}
But this looks a lot like std::malloc
and std::free
.
A third solution might be to use std::aligned_storage
as the type given to new
, and have the deleter work as with std::byte
because the aligned storage is a trivial aggregate.
Alignment is only needed for over-aligned types though.
– eerorika
2 days ago
2
@eerorika I thought it was UB to access (e.g) anint
with alignment of 4 if it was not on a 4-byte boundary?
– Artyer
2 days ago
3
Since this is a language lawyer question, it would be nice to have some form of authoritative source backing up the claims made.
– François Andrieux
2 days ago
1
@Artyer check virgesmith's comment on the question. I would suggest fixing the exception safety in your answer for a complete example. François's comment after it has the solution.
– eerorika
2 days ago
2
There is no destructor forstd::byte
so no non static member is being called.std::byte
is defined asenum class byte : unsigned char {} ;
so it is just achar
– NathanOliver
2 days ago
|
show 10 more comments
This program is not well defined.
The rule is that if a type has a trivial destructor (See this), you don't need to call it. So, this:
return std::shared_ptr<T>(new (memory.release()) T());
is almost correct. It omits the destructor of the sizeof(T)
std::byte
s, which is fine, constructs a new T
in the memory, which is fine, and then when the shared_ptr
is ready to delete, it calls delete this->get();
, which is wrong. That first deconstructs a T
, but then it deallocates a T
instead of a std::byte
, which will probably (undefined) not work.
C++ standard §8.5.2.4p8 [expr.new]
A new-expression may obtain storage for the object by calling an allocation function. [...] If the allocated type is an array type, the allocation function's name is
operator new
.
(All those "may"s are because implementations are allowed to merge adjacent new expressions and only call operator new
for one of them, but this isn't the case as new
only happens once (In make_unique
))
And part 11 of the same section:
When a new-expression calls an allocation function and that allocation has not been extended, the new-expression passes the amount of space requested to the allocation function as the first argument of type
std::size_t
. That argument shall be no less than the size of the object being created; it may be greater than the size of the object being created only if the object is an array. For arrays ofchar
,unsigned char
, andstd::byte
, the difference between the result of the new-expression and the address returned by the
allocation function shall be an integral multiple of the strictest fundamental alignment requirement (6.6.5) of any object type whose size is no greater than the size of the array being created. [Note: Because allocation
functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating
character arrays into which objects of other types will later be placed. — end note ]
If you read §21.6.2 [new.delete.array], you see that the default operator new
and operator delete
do the exact same things as operator new
and operator delete
, the problem is we don't know the size passed to it, and it is probably more than what delete ((T*) object)
calls (to store the size).
Looking at what delete-expressions do:
§8.5.2.5p8 [expr.delete]
[...] delete-expression will invoke the destructor (if any) for [...] the elements of the array being deleted
p7.1
If the allocation call for the new-expression for the object to be deleted was not omitted [...], the delete-expression shall call a deallocation function (6.6.4.4.2). The value returned from the allocation call of the new-expression shall be passed as the first argument to the deallocation function.
Since std::byte
does not have a destructor, we can safely call delete
, as it will not do anything other than call the deallocate function (operator delete
). We just have to reinterpret it back to std::byte*
, and we will get back what new
returned.
Another problem is that there is a memory leak if the constructor of T
throws. A simple fix is to placement new
while the memory is still owned by the std::unique_ptr
, so even if it does throw it will call delete
properly.
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
delete reinterpret_cast<std::byte*>(ptr);
});
The first placement new
ends the lifetime of the sizeof(T)
std::byte
s and starts the lifetime of a new T
object at the same address, as according to §6.6.3p5 [basic.life]
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. [...]
Then when it is being deleted, the lifetime of T
ends by an explicit call of the destructor, and then according to the above, the delete-expression deallocates the storage.
This leads to the question of:
What if the storage class wasn't std::byte
, and was not trivially destructible? Like, for example, we were using a non-trivial union as the storage.
Calling delete reinterpret_cast<T*>(ptr)
would call the destructor on something that is not an object. This is clearly undefined behaviour, and is according to §6.6.3p6 [basic.life]
Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [...], any pointer that represents the address of the storage location where the object will be or
was located may be used but only in limited ways. [...] The program has undefined behavior if: the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression
So to use it like above, we have to construct it just to destruct it again.
The default constructor probably works fine. The usual semantics are "create an object that can be destructed", which is exactly what we want. Use std::uninitialized_default_construct_n
to construct them all to then immediately destruct them:
// Assuming we called `new StorageClass[n]` to allocate
ptr->~T();
auto* as_storage = reinterpret_cast<StorageClass*>(ptr);
std::uninitialized_default_construct_n(as_storage, n);
delete as_storage;
We can also call operator new
and operator delete
ourselves:
static void byte_deleter(std::byte* ptr) {
return ::operator delete(reinterpret_cast<void*>(ptr));
}
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::unique_ptr<std::byte, void(*)(std::byte*)>(
reinterpret_cast<std::byte*>(::operator new(size)),
&::byte_deleter
);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
::operator delete(ptr, sizeof(T));
// ^~~~~~~~~ optional
});
}
But this looks a lot like std::malloc
and std::free
.
A third solution might be to use std::aligned_storage
as the type given to new
, and have the deleter work as with std::byte
because the aligned storage is a trivial aggregate.
Alignment is only needed for over-aligned types though.
– eerorika
2 days ago
2
@eerorika I thought it was UB to access (e.g) anint
with alignment of 4 if it was not on a 4-byte boundary?
– Artyer
2 days ago
3
Since this is a language lawyer question, it would be nice to have some form of authoritative source backing up the claims made.
– François Andrieux
2 days ago
1
@Artyer check virgesmith's comment on the question. I would suggest fixing the exception safety in your answer for a complete example. François's comment after it has the solution.
– eerorika
2 days ago
2
There is no destructor forstd::byte
so no non static member is being called.std::byte
is defined asenum class byte : unsigned char {} ;
so it is just achar
– NathanOliver
2 days ago
|
show 10 more comments
This program is not well defined.
The rule is that if a type has a trivial destructor (See this), you don't need to call it. So, this:
return std::shared_ptr<T>(new (memory.release()) T());
is almost correct. It omits the destructor of the sizeof(T)
std::byte
s, which is fine, constructs a new T
in the memory, which is fine, and then when the shared_ptr
is ready to delete, it calls delete this->get();
, which is wrong. That first deconstructs a T
, but then it deallocates a T
instead of a std::byte
, which will probably (undefined) not work.
C++ standard §8.5.2.4p8 [expr.new]
A new-expression may obtain storage for the object by calling an allocation function. [...] If the allocated type is an array type, the allocation function's name is
operator new
.
(All those "may"s are because implementations are allowed to merge adjacent new expressions and only call operator new
for one of them, but this isn't the case as new
only happens once (In make_unique
))
And part 11 of the same section:
When a new-expression calls an allocation function and that allocation has not been extended, the new-expression passes the amount of space requested to the allocation function as the first argument of type
std::size_t
. That argument shall be no less than the size of the object being created; it may be greater than the size of the object being created only if the object is an array. For arrays ofchar
,unsigned char
, andstd::byte
, the difference between the result of the new-expression and the address returned by the
allocation function shall be an integral multiple of the strictest fundamental alignment requirement (6.6.5) of any object type whose size is no greater than the size of the array being created. [Note: Because allocation
functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating
character arrays into which objects of other types will later be placed. — end note ]
If you read §21.6.2 [new.delete.array], you see that the default operator new
and operator delete
do the exact same things as operator new
and operator delete
, the problem is we don't know the size passed to it, and it is probably more than what delete ((T*) object)
calls (to store the size).
Looking at what delete-expressions do:
§8.5.2.5p8 [expr.delete]
[...] delete-expression will invoke the destructor (if any) for [...] the elements of the array being deleted
p7.1
If the allocation call for the new-expression for the object to be deleted was not omitted [...], the delete-expression shall call a deallocation function (6.6.4.4.2). The value returned from the allocation call of the new-expression shall be passed as the first argument to the deallocation function.
Since std::byte
does not have a destructor, we can safely call delete
, as it will not do anything other than call the deallocate function (operator delete
). We just have to reinterpret it back to std::byte*
, and we will get back what new
returned.
Another problem is that there is a memory leak if the constructor of T
throws. A simple fix is to placement new
while the memory is still owned by the std::unique_ptr
, so even if it does throw it will call delete
properly.
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
delete reinterpret_cast<std::byte*>(ptr);
});
The first placement new
ends the lifetime of the sizeof(T)
std::byte
s and starts the lifetime of a new T
object at the same address, as according to §6.6.3p5 [basic.life]
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. [...]
Then when it is being deleted, the lifetime of T
ends by an explicit call of the destructor, and then according to the above, the delete-expression deallocates the storage.
This leads to the question of:
What if the storage class wasn't std::byte
, and was not trivially destructible? Like, for example, we were using a non-trivial union as the storage.
Calling delete reinterpret_cast<T*>(ptr)
would call the destructor on something that is not an object. This is clearly undefined behaviour, and is according to §6.6.3p6 [basic.life]
Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [...], any pointer that represents the address of the storage location where the object will be or
was located may be used but only in limited ways. [...] The program has undefined behavior if: the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression
So to use it like above, we have to construct it just to destruct it again.
The default constructor probably works fine. The usual semantics are "create an object that can be destructed", which is exactly what we want. Use std::uninitialized_default_construct_n
to construct them all to then immediately destruct them:
// Assuming we called `new StorageClass[n]` to allocate
ptr->~T();
auto* as_storage = reinterpret_cast<StorageClass*>(ptr);
std::uninitialized_default_construct_n(as_storage, n);
delete as_storage;
We can also call operator new
and operator delete
ourselves:
static void byte_deleter(std::byte* ptr) {
return ::operator delete(reinterpret_cast<void*>(ptr));
}
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::unique_ptr<std::byte, void(*)(std::byte*)>(
reinterpret_cast<std::byte*>(::operator new(size)),
&::byte_deleter
);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
::operator delete(ptr, sizeof(T));
// ^~~~~~~~~ optional
});
}
But this looks a lot like std::malloc
and std::free
.
A third solution might be to use std::aligned_storage
as the type given to new
, and have the deleter work as with std::byte
because the aligned storage is a trivial aggregate.
This program is not well defined.
The rule is that if a type has a trivial destructor (See this), you don't need to call it. So, this:
return std::shared_ptr<T>(new (memory.release()) T());
is almost correct. It omits the destructor of the sizeof(T)
std::byte
s, which is fine, constructs a new T
in the memory, which is fine, and then when the shared_ptr
is ready to delete, it calls delete this->get();
, which is wrong. That first deconstructs a T
, but then it deallocates a T
instead of a std::byte
, which will probably (undefined) not work.
C++ standard §8.5.2.4p8 [expr.new]
A new-expression may obtain storage for the object by calling an allocation function. [...] If the allocated type is an array type, the allocation function's name is
operator new
.
(All those "may"s are because implementations are allowed to merge adjacent new expressions and only call operator new
for one of them, but this isn't the case as new
only happens once (In make_unique
))
And part 11 of the same section:
When a new-expression calls an allocation function and that allocation has not been extended, the new-expression passes the amount of space requested to the allocation function as the first argument of type
std::size_t
. That argument shall be no less than the size of the object being created; it may be greater than the size of the object being created only if the object is an array. For arrays ofchar
,unsigned char
, andstd::byte
, the difference between the result of the new-expression and the address returned by the
allocation function shall be an integral multiple of the strictest fundamental alignment requirement (6.6.5) of any object type whose size is no greater than the size of the array being created. [Note: Because allocation
functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating
character arrays into which objects of other types will later be placed. — end note ]
If you read §21.6.2 [new.delete.array], you see that the default operator new
and operator delete
do the exact same things as operator new
and operator delete
, the problem is we don't know the size passed to it, and it is probably more than what delete ((T*) object)
calls (to store the size).
Looking at what delete-expressions do:
§8.5.2.5p8 [expr.delete]
[...] delete-expression will invoke the destructor (if any) for [...] the elements of the array being deleted
p7.1
If the allocation call for the new-expression for the object to be deleted was not omitted [...], the delete-expression shall call a deallocation function (6.6.4.4.2). The value returned from the allocation call of the new-expression shall be passed as the first argument to the deallocation function.
Since std::byte
does not have a destructor, we can safely call delete
, as it will not do anything other than call the deallocate function (operator delete
). We just have to reinterpret it back to std::byte*
, and we will get back what new
returned.
Another problem is that there is a memory leak if the constructor of T
throws. A simple fix is to placement new
while the memory is still owned by the std::unique_ptr
, so even if it does throw it will call delete
properly.
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
delete reinterpret_cast<std::byte*>(ptr);
});
The first placement new
ends the lifetime of the sizeof(T)
std::byte
s and starts the lifetime of a new T
object at the same address, as according to §6.6.3p5 [basic.life]
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. [...]
Then when it is being deleted, the lifetime of T
ends by an explicit call of the destructor, and then according to the above, the delete-expression deallocates the storage.
This leads to the question of:
What if the storage class wasn't std::byte
, and was not trivially destructible? Like, for example, we were using a non-trivial union as the storage.
Calling delete reinterpret_cast<T*>(ptr)
would call the destructor on something that is not an object. This is clearly undefined behaviour, and is according to §6.6.3p6 [basic.life]
Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [...], any pointer that represents the address of the storage location where the object will be or
was located may be used but only in limited ways. [...] The program has undefined behavior if: the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression
So to use it like above, we have to construct it just to destruct it again.
The default constructor probably works fine. The usual semantics are "create an object that can be destructed", which is exactly what we want. Use std::uninitialized_default_construct_n
to construct them all to then immediately destruct them:
// Assuming we called `new StorageClass[n]` to allocate
ptr->~T();
auto* as_storage = reinterpret_cast<StorageClass*>(ptr);
std::uninitialized_default_construct_n(as_storage, n);
delete as_storage;
We can also call operator new
and operator delete
ourselves:
static void byte_deleter(std::byte* ptr) {
return ::operator delete(reinterpret_cast<void*>(ptr));
}
auto non_zero_memory(std::size_t size)
{
constexpr std::byte non_zero = static_cast<std::byte>(0xC5);
auto memory = std::unique_ptr<std::byte, void(*)(std::byte*)>(
reinterpret_cast<std::byte*>(::operator new(size)),
&::byte_deleter
);
std::fill(memory.get(), memory.get()+size, non_zero);
return memory;
}
template <class T>
auto on_non_zero_memory()
{
auto memory = non_zero_memory(sizeof(T));
T* ptr = new (memory.get()) T();
memory.release();
return std::shared_ptr<T>(ptr, (T* ptr) {
ptr->~T();
::operator delete(ptr, sizeof(T));
// ^~~~~~~~~ optional
});
}
But this looks a lot like std::malloc
and std::free
.
A third solution might be to use std::aligned_storage
as the type given to new
, and have the deleter work as with std::byte
because the aligned storage is a trivial aggregate.
edited 2 days ago
answered 2 days ago
ArtyerArtyer
4,151727
4,151727
Alignment is only needed for over-aligned types though.
– eerorika
2 days ago
2
@eerorika I thought it was UB to access (e.g) anint
with alignment of 4 if it was not on a 4-byte boundary?
– Artyer
2 days ago
3
Since this is a language lawyer question, it would be nice to have some form of authoritative source backing up the claims made.
– François Andrieux
2 days ago
1
@Artyer check virgesmith's comment on the question. I would suggest fixing the exception safety in your answer for a complete example. François's comment after it has the solution.
– eerorika
2 days ago
2
There is no destructor forstd::byte
so no non static member is being called.std::byte
is defined asenum class byte : unsigned char {} ;
so it is just achar
– NathanOliver
2 days ago
|
show 10 more comments
Alignment is only needed for over-aligned types though.
– eerorika
2 days ago
2
@eerorika I thought it was UB to access (e.g) anint
with alignment of 4 if it was not on a 4-byte boundary?
– Artyer
2 days ago
3
Since this is a language lawyer question, it would be nice to have some form of authoritative source backing up the claims made.
– François Andrieux
2 days ago
1
@Artyer check virgesmith's comment on the question. I would suggest fixing the exception safety in your answer for a complete example. François's comment after it has the solution.
– eerorika
2 days ago
2
There is no destructor forstd::byte
so no non static member is being called.std::byte
is defined asenum class byte : unsigned char {} ;
so it is just achar
– NathanOliver
2 days ago
Alignment is only needed for over-aligned types though.
– eerorika
2 days ago
Alignment is only needed for over-aligned types though.
– eerorika
2 days ago
2
2
@eerorika I thought it was UB to access (e.g) an
int
with alignment of 4 if it was not on a 4-byte boundary?– Artyer
2 days ago
@eerorika I thought it was UB to access (e.g) an
int
with alignment of 4 if it was not on a 4-byte boundary?– Artyer
2 days ago
3
3
Since this is a language lawyer question, it would be nice to have some form of authoritative source backing up the claims made.
– François Andrieux
2 days ago
Since this is a language lawyer question, it would be nice to have some form of authoritative source backing up the claims made.
– François Andrieux
2 days ago
1
1
@Artyer check virgesmith's comment on the question. I would suggest fixing the exception safety in your answer for a complete example. François's comment after it has the solution.
– eerorika
2 days ago
@Artyer check virgesmith's comment on the question. I would suggest fixing the exception safety in your answer for a complete example. François's comment after it has the solution.
– eerorika
2 days ago
2
2
There is no destructor for
std::byte
so no non static member is being called. std::byte
is defined as enum class byte : unsigned char {} ;
so it is just a char
– NathanOliver
2 days ago
There is no destructor for
std::byte
so no non static member is being called. std::byte
is defined as enum class byte : unsigned char {} ;
so it is just a char
– NathanOliver
2 days ago
|
show 10 more comments
std::shared_ptr<T>(new (memory.release()) T())
Is undefined behavior. The memory that was acquired by memory
was for a std::byte
but the shared_ptr
's deleter is doing to call delete
on a pointer to T
. Since the pointer no longer has the same type you can't call delete on it per [expr.delete]/2
In a single-object delete expression, the value of the operand of delete may be a null pointer value, a pointer to a non-array object created by a previous new-expression, or a pointer to a subobject representing a base class of such an object. If not, the behavior is undefined.
You would have to provide the shared_ptr
with a custom deleter that destroys T
and then casts the pointer back to its source type and call delete
on that.
It should also be noted that new (memory.release()) T()
itself will be undefined if memory
allocated a type that has non trivial destruction. You would have to call the destructor on the pointer from memory.release()
first before you reuse it's memory.
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
yesterday
add a comment |
std::shared_ptr<T>(new (memory.release()) T())
Is undefined behavior. The memory that was acquired by memory
was for a std::byte
but the shared_ptr
's deleter is doing to call delete
on a pointer to T
. Since the pointer no longer has the same type you can't call delete on it per [expr.delete]/2
In a single-object delete expression, the value of the operand of delete may be a null pointer value, a pointer to a non-array object created by a previous new-expression, or a pointer to a subobject representing a base class of such an object. If not, the behavior is undefined.
You would have to provide the shared_ptr
with a custom deleter that destroys T
and then casts the pointer back to its source type and call delete
on that.
It should also be noted that new (memory.release()) T()
itself will be undefined if memory
allocated a type that has non trivial destruction. You would have to call the destructor on the pointer from memory.release()
first before you reuse it's memory.
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
yesterday
add a comment |
std::shared_ptr<T>(new (memory.release()) T())
Is undefined behavior. The memory that was acquired by memory
was for a std::byte
but the shared_ptr
's deleter is doing to call delete
on a pointer to T
. Since the pointer no longer has the same type you can't call delete on it per [expr.delete]/2
In a single-object delete expression, the value of the operand of delete may be a null pointer value, a pointer to a non-array object created by a previous new-expression, or a pointer to a subobject representing a base class of such an object. If not, the behavior is undefined.
You would have to provide the shared_ptr
with a custom deleter that destroys T
and then casts the pointer back to its source type and call delete
on that.
It should also be noted that new (memory.release()) T()
itself will be undefined if memory
allocated a type that has non trivial destruction. You would have to call the destructor on the pointer from memory.release()
first before you reuse it's memory.
std::shared_ptr<T>(new (memory.release()) T())
Is undefined behavior. The memory that was acquired by memory
was for a std::byte
but the shared_ptr
's deleter is doing to call delete
on a pointer to T
. Since the pointer no longer has the same type you can't call delete on it per [expr.delete]/2
In a single-object delete expression, the value of the operand of delete may be a null pointer value, a pointer to a non-array object created by a previous new-expression, or a pointer to a subobject representing a base class of such an object. If not, the behavior is undefined.
You would have to provide the shared_ptr
with a custom deleter that destroys T
and then casts the pointer back to its source type and call delete
on that.
It should also be noted that new (memory.release()) T()
itself will be undefined if memory
allocated a type that has non trivial destruction. You would have to call the destructor on the pointer from memory.release()
first before you reuse it's memory.
edited 2 days ago
answered 2 days ago
NathanOliverNathanOliver
88k15120184
88k15120184
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
yesterday
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
yesterday
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
yesterday
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
yesterday
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54095233%2fis-it-ok-to-make-a-placement-new-on-memory-managed-by-a-smart-pointer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
There are rules about objects replacing other objects, and rules about trivial objects not needing explicit destruction - I'll let someone find the proper wording to prove you're safe though
– Lightness Races in Orbit
2 days ago
The memory isn't really managed by a smart pointer since you
release
d it.– François Andrieux
2 days ago
@FrançoisAndrieux only to let it be managed by another smart pointer though.
– YSC
2 days ago
@LightnessRacesinOrbit
Type
is not necessarily that simple. Let me correct that... Q fixed.– YSC
2 days ago
2
The first code snippet is generally incorrect, since you do not care proper alignment for objects of type
Type
. Better to usestd::aligned_storage_t<sizeof(Type), alignof(Type)>
thanstd::array
of chars.– Daniel Langr
2 days ago