m
Size: a a a
2020 June 22
AT
он так-то знает, время жизни какого объекта в том куске памяти начинается. и еще стандарт говорит, что время жизни подобъектов, которые принадлежат к implicit-lifetime типам, начинается вместе с самим объектом. (указатели к этим типам относятся)
> время жизни объекта в куске памяти
А тип объекта ему известен? Мне кажется, что нет.
А тип объекта ему известен? Мне кажется, что нет.
VS
> время жизни объекта в куске памяти
А тип объекта ему известен? Мне кажется, что нет.
А тип объекта ему известен? Мне кажется, что нет.
как у такого объекта потом вызвать нужный деструктор в таком случае
A
struct S {
void* p;
};
S* s = reinterpret_cast<S*>(calloc(sizeof(int))); // note this memory guaranteed to be filled with zeros
assert(s->p == nullptr);
Такой код был UB. В 20ом стандарте UB нет, но срабатывание assert'а зависит от битового представления nullptr.Почему не UB, что поменялось? Разве алиасинг разрешили?
ПК
struct S {
void* p;
};
S* s = reinterpret_cast<S*>(calloc(sizeof(int))); // note this memory guaranteed to be filled with zeros
assert(s->p == nullptr);
Такой код был UB. В 20ом стандарте UB нет, но срабатывание assert'а зависит от битового представления nullptr.Ну то есть сломался невалидный код, не страшно :)
ПК
(при том сломался на экзотической архитектуре)
AT
как у такого объекта потом вызвать нужный деструктор в таком случае
Как я понял, в этом случае деструктор должен быть тривиален.
S
как у такого объекта потом вызвать нужный деструктор в таком случае
p->~T()
VS
Как я понял, в этом случае деструктор должен быть тривиален.
Scalar types, implicit-lifetime class types ([class.prop]), array types, and cv-qualified versions of these types are collectively called implicit-lifetime types.
A class S is an implicit-lifetime class if it is an aggregate or has at least one trivial eligible constructor and a trivial, non-deleted destructor.
A class S is an implicit-lifetime class if it is an aggregate or has at least one trivial eligible constructor and a trivial, non-deleted destructor.
VS
коротко: да
ПК
Почему не UB, что поменялось? Разве алиасинг разрешили?
Там нет юрисдикции алиасинга, потому что функции типа malloc якобы под капотом создают объект нужного типа, а тогда алиасинга никакого нет
VS
Как я понял, в этом случае деструктор должен быть тривиален.
но это не отменяет того факта, что тип компилятору известен
A
Там нет юрисдикции алиасинга, потому что функции типа malloc якобы под капотом создают объект нужного типа, а тогда алиасинга никакого нет
Понял, спасибо. Давно ещё смотрел на этот PR, но потом потерял его из виду. Полезное и нужное нововведение.
AT
но это не отменяет того факта, что тип компилятору известен
Но и не подтверждает его, так?
VS
Но и не подтверждает его, так?
An object has a type
VS
вот и подтверждение
m
если placement new, то зачем calloc()?, и malloc() достаточно
calloc становится почти бесполезным
calloc становится почти бесполезным
Наверное, достаточно написать
static_assert((uintptr_t)nullptr == 0); и тогда можно инициализировать указатели битовым нулем. То есть мне кажется, перевели из UB в implementation defined.