Можно ли Конструктор и Деструктор вызывать как метод класса?

Собственно вопрос:
можно ли Конструктор и Деструктор вызывать вручную, как обычный метод класса?
Например, я хочу управлять очередностью вызовов. См. пример:

0

Сообщение от hoggy если по стандарту, то поведение становится неопределённым уже по факту применения операции new placement. а не по факту чтения из константного поля.

Интересно, а согласно какому пункту это так?
Это же приведет к противоречию в стандарте... потому что:

Сообщение от hoggy если же как ты пишешь: по факту чтения (к тому же зависит от способа обращения), тогда сам по себе new placement неопределенного поведения не возбуждает.

ну да, сам по себе placement new в данном случае не приводит к UB
иначе стандарт противоречил бы сам себе позволяя читать актуальные данные из const поля в обход оптимизации (применяя std::launder)
потому что смысла бы в таком чтении бы не было т.к уже настало UB, еще до std::launder, там где placement new...
тогда дальше ничего нельзя было бы гарантировать. Но как мы видим, гарантии все же есть, и такие поля можно читать

Сообщение от hoggy но уверен ли ты в этом? не получится ли так, что процесс крашнется уже на этапе исполнения new placement?

в реализации компиляторов я не уверен и вполне возможен краш в таком случае
но думаю это все же не проблема исходящая из стандарта
а проблема несоответствующей стандарту реализации и головная боль пользователей этой реализации

0

Сообщение от Undisputed согласно какому пункту это так?

ты ж сам привел ссылку на 6.8 Object lifetime,
где описывается в каких случаях можно реюзать объект.

и сам же выше писал: логично предположить, что во всех остальных случаях это UB.

и вроде как, мы уже разобрались почему нельзя реюзать классы,
которые содержит константно/ссылочные поля.

что это это связанно с тем, что нельзя модифицировать объект,
рожденный константным.

6.8 Object lifetime 10. Creating a new object within the storage that a const complete object with static, thread, or automatic storage duration occupies, or within the storage that such a const object used to occupy before its lifetime ended, results in undefined behavior C++ 1 2 3 4 void h() { b.~B(); new (const_cast<B*>(&b)) const B; // undefined behavior }

8.2.11 Const cast Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data member resulting from a const_cast that casts away a const-qualifier may produce undefined behavior

10.1.7.1 The cv-qualifiers Except that any class member declared mutable (10.1.1) can be modified, any attempt to modify a const object during its lifetime (6.8) results in undefined behavior.

Сообщение от Undisputed ну да, сам по себе placement new в данном случае не приводит к UB иначе стандарт противоречил бы сам себе позволяя читать актуальные данные из const поля в обход оптимизации (применяя std::launder)

хочешь сказать,
стандарт не противоречит сам себе,
когда объявляет, что модификация константного объекта - это UB.
а затем, позволяет легально читать актуальные данные из const поля
в обход оптимизации (применяя std::launder) ?

Сообщение от Undisputed т.к уже настало UB, еще до std::launder, там где placement new...

насчет std::launder.
это такой костыль, навроде volatile,
который позволяет дотянуться до данных подвинув оптимизатор в сторонку.

там есть занимательный экземпел:

21.6.4 Pointer optimization barrier [Example: C++ 1 2 3 4 5 6 struct X { const int n; }; X *p = new X{3}; const int a = p->n; new (p) X{5}; // p does not point to new object (6.8) because X::n is const const int b = p->n; // undefined behavior const int c = std::launder(p)->n; // OK — end example ]

обрати внимание на строчку:
это они так в этом пункте мягко обозвали ситуацию с UB.

перевожу на простой русский:
"указатель P - это не то, что вы подумали.
он не указывает на объект,
как обычно указывают все прилично воспитанные указатели
в цивилизованных программах.
нет. в условиях UB, такой указатель - шашка с динамитом,
и фитиль уже горит.
ещё чуть чуть и будет больно.
но есть лайф-хак.
пока этот говнокод ещё не крашнулся,
через указатель можно дотянуться до данных"

Сообщение от Undisputed Но как мы видим, гарантии все же есть, и такие поля можно читать

не уверен насчет гарантий.
скажем так: используя std::launder,
можно прочитать константное поле.
если конечно процесс ещё раньше где нибудь не крашнулся
(на этапе new placement, например)

а вот как класс в целом будет работать:
например, что вернёт return this->const_field; - вопрос остается открытым.

Добавлено через 2 минуты

Сообщение от Undisputed думаю это все же не проблема исходящая из стандарта а проблема несоответствующей стандарту реализации

в чем не соответствие?

0

hoggy, что касается констант и ссылок то причины порождающие неоднозначность более-менее ясны. Однако если пользователь обеспечивает реинициализацию тем же значением для констант времени выполнения и даже тем же адресом для констант со статическим классом хранения, разве это может стать причиной проблем?
И отдельный вопрос как ветка темы.
Не вдаваясь в современные рассказы определения типа. Пусть семантикой типа считается вся информация об объекте не связанная с его состоянием и адресом.
Тогда кроме типа (в старом понимании - формат, операции, размер) в данное определение стучатся нестатические данные со статическим классом хранения. Например вот такой указатель инициализированный вот так:
И получается, что данная статическая нестатичность, делает объекты ns1 и ns2 объектами разных типов если не ограничиться тем что считается типом С++ и обозначается именем типа. Ведь такой указатель нельзя изменить (корректно, по крайней мере) и стало быть он не принадлежит состоянию.
То есть, беда в том, что если в старое понятие типа добавить, то что указано в старте вопроса:
Пусть семантикой типа считается вся информация об объекте не связанная с его состоянием.
Тогда, это учитывает такие неизменяемые данные как константы статического класса хранения но не статического способа владения (то есть полей объекта). Проблема в том, что язык не выражает такое различие в типах явно. Он даже не явно этого не выражает. С точки зрения языка ns1 и ns2 принадлежат одному типу.
Я думаю, данное внутреннее противоречие неразрешимо на сегодняшний день и это возможная причина по которой стройное и точное определение заменено жидким рассказом. Но разрежение определение всегда ведёт к разжижению мозгов. Неудивительно, что у него достаточно много защитников.
зы я не против порядка вообще и стандарта, в частности. Просто, интересно порассуждать о логике и фактах. Они упрямы (как гласит мудрость) и не укладываются в плохие термины, определения.

0

Сообщение от hoggy хочешь сказать, стандарт не противоречит сам себе, когда объявляет, что модификация константного объекта - это UB. а затем, позволяет легально читать актуальные данные из const поля в обход оптимизации (применяя std::launder) ?

я бы сказал что это правило для которого есть свои исключения...

Сообщение от hoggy в чем не соответствие?

в том что если было бы

Сообщение от hoggy оптимизирующий компилятор видит, что данные не изменяемые, и размещает их в более быстрой секции read-only. и уже на этапе new placement, из-за попытки записи в read-only, процесс словит access violation

тогда было бы несоответствие
потому что это нарушало бы гарантии стандарта (это в случае если используется std::launder)

Сообщение от hoggy не уверен насчет гарантий. скажем так: используя std::launder, можно прочитать константное поле. если конечно процесс ещё раньше где нибудь не крашнулся (на этапе new placement, например)

я просто не могу понять почему ты не уверен насчет гарантий
если в коде выше написано что
а еще выше этого есть placement new... если написано ОК, значит гарантии есть
другое дело как сильно будет болеть голова у тех кто будет отслеживать подобное что бы обеспечить эти гарантии

Сообщение от hoggy например, что вернёт return this->const_field; - вопрос остается открытым.

Интересный вопрос. Я думаю по стандарту это выражение должно вернуть данные нового объекта, потому что:

21.6.4 Pointer optimization barrier ... If a new object is created in storage occupied by an existing object of the same type, a pointer to the original object can be used to refer to the new object unless the type contains const or reference members; in the latter cases, this function can be used to obtain a usable pointer to the new object

если присмотреться, то нам говорят что результат std::launder это указатель на новый объект.
то есть это рабочий указатель на байтики с обновленными данными
this->const_field это ничто иное как часть нового объекта
а раз у нас есть рабочий указатель на обновленные байтики
то полагаю что return this->const_field должен вернуть то, что в его область памяти было записано последним
то есть думаю исходя из этого можно сделать вывод

0

Сообщение от Undisputed если присмотреться, то нам говорят что результат std::launder это указатель на новый объект. то есть это рабочий указатель на байтики с обновленными данными this->const_field это ничто иное как часть нового объекта

Я думаю, это о оптимизации возможны в некотором внешнем контексте (скоупе). То есть:
Если новая константа не равна старой, то без launder мы не можем быть уверены, что вместо ссылки extern_ref далее по коду не будет встроено старое значение.
А в методах объекта (там где this) такая опасность не должна присутствовать. Иначе нужно допустить, что для разных объектов компилятор может заинлайнить разный код (ведь константы времени выполнения у разных объектов могут отличаться).

0

IGPIGP,
Пусть инлайнит, какие проблемы если это допустить?)

Добавлено через 1 минуту
Там где будет launder, гарантии же есть

0

Сообщение от Undisputed IGPIGP, Пусть инлайнит, какие проблемы если это допустить?)

Проблема в том, что любое обращение к константе - члену может получить старое значение. Обращение через launder запрещает встраивание и заставляет обращаться к константе по адресу. То есть, я говорю не о том. Может не слишком понятно говорю. Есть такой грех.

Добавлено через 3 часа 49 минут

Сообщение от Undisputed IGPIGP, Пусть инлайнит, какие проблемы если это допустить?)

Кажется понял ваш вопрос.
Я не уверен, но сомневаюсь, что методы класса могут встраиваться по разному в зависимости от значения полей констант времени компиляции. Я пытался сказать, что для ситуаций с внутренним скоупом объекта класса не должно быть проблем, где launder нужен.
Но буду признателен, если кто-то покажет такой случай.

0

IGPIGP,
Насколько я понял вам интересно нужно ли применять launder к полям внутри методов?
Если вопрос был в этом то помоему не нужно.
Он будет нужен при использовании указателя (надо будет прогнать через него указатель) от имени которого вызывается метод

0

Сообщение от Undisputed Если вопрос был в этом то помоему не нужно.

И я о том же)
Мой пассаж относился к:

Сообщение от hoggy например, что вернёт return this->const_field; - вопрос остается открытым.

То есть к методу, в частностии и области видимости объекта, вообще.

0

Сообщение от Undisputed тогда было бы несоответствие потому что это нарушало бы гарантии стандарта (это в случае если используется std::launder)

стандарт не дает никаких гарантий для ситуаций,
которые декларирует как UB.

и при чем тут std::launder?
у тебя процесс может крякнуться задолго до момента его использования.

Сообщение от Undisputed я просто не могу понять почему ты не уверен насчет гарантий если в коде выше написано что

потому что мне очевидно, что раз UB,
значит не факт, что эта строчка кода вообще выполнится.

Сообщение от Undisputed если присмотреться, то нам говорят что результат std::launder это указатель на новый объект.

если присмотреться, там говорится:
лютый говнокод в терминальной стадии.

тебе никто не обещает, что ты сможешь дотянуться до данных,
если не используешь std::launder.

Сообщение от Undisputed можно сделать вывод std::launder(p)->getConstFieldValue() // OK

ты как то тупо делаешь выводы,
учитывая что оригинальная строка была:

Сообщение от hoggy return this->const_field;

ты не понял что ли сути проблемы?

нельзя изменять константу.
это - UB.

костыльный std::launder заставляет компилятор честно заново вычитывать память.
(не использовать оптимизирующие кэши, и тп штуки).

это может сработать при условии,
что процесс не крякнулся ещё на этапе перезаписи константного объекта.


однако, любой код, который не использует std::launder
никому ничего не гарантирует.

UB никуда не делось.

Добавлено через 7 минут

Сообщение от Undisputed Пусть инлайнит, какие проблемы если это допустить?)

да никаких.
если конечно не считать того,
что программко упадет (в лучшем случае)
или будет работать не правильно.

Добавлено через 1 минуту

Сообщение от IGPIGP что касается констант и ссылок то причины порождающие неоднозначность более-менее ясны. Однако если пользователь обеспечивает реинициализацию тем же значением для констант времени выполнения и даже тем же адресом для констант со статическим классом хранения, разве это может стать причиной проблем?

"это" - не может.
а вот сама попытка перезаписи константного объекта - очень даже может быть.
access violation, например.

0

Сообщение от hoggy тебе никто не обещает, что ты сможешь дотянуться до данных, если не используешь std::launder.

а где я утверждал обратное?
то что я утверждаю касается только того случая где есть std::launder
естественно const объекты модифицировать запрещено и это UB
мы вроде уже обсудили это почти в самом начале беседы

0

Сообщение от hoggy а вот сама попытка перезаписи константного объекта - очень даже может быть. access violation, например.

Я же не говорю о константах времени компиляции, которые могут быть размещены в памяти недоступной для записи. Поля объектов - указатели инициализированные адресом таких констант могут быть реинициализированы как старыми так и новыми адресами (под ответственность того кто это замыслил).
А вот поля - константы времени компиляции я себе (без злого умысла того кто это вершит) не представляю. Статические константы - да. но это данные класса. А константы - поля объекта, - не представляю (именно константы времени компиляции в реализации).

0

Сообщение от Undisputed а где я утверждал обратное?

ты выразил непонимание:

Сообщение от Undisputed тогда было бы несоответствие потому что это нарушало бы гарантии стандарта (это в случае если используется std::launder)

нет никакого несоответствия,
потому что нет никаких гарантий.
потому что UB никуда не делось.
UB начинается в момент работы new placement
потому что:

Сообщение от Undisputed const объекты модифицировать запрещено и это UB

а значит не известно, чем завершится строка:

Сообщение от hoggy new (p) X{5}; // p does not point to new object (6.8) because X::n is const

может процесс вообще крашнется в этой строчке.

а значит до строчки:

Сообщение от Undisputed const int c = std::launder(p)->n; // OK

дело вообще может и не дойти.
или дойти, но как то не так.

и в этом нет вины компиляторов.
в условиях UB компиляторы ничего не гарантируют.
-----------------------

а вот std::launder привносит некоторое противоречие в спецификацию.
он обещает суметь вычитать константное значение правильно,
даже если была осуществлена попытка его изменения.

что-то вроде:
"если ваш процесс все ж таки дожил до использования std::launder,
тогда через std::launder вы сможете правильно прочитать значение измененной константы"

на самом деле, строго говоря,
это так же не гарантируется.

результат работы std::launder - указатель,
для которого были отброшены все оптимизации,
связанные с оригинальным указателем.
и только лишь.

но поскольку UB никуда не девалось,
уже в принципе никто никому ничего не гарантирует.

зы:
лично я вообще не понимаю,
для каких сакральных нужд этот костыль завезли в стандарт.

Добавлено через 7 минут

Сообщение от IGPIGP Я же не говорю о константах времени компиляции

да это не важно.
теоретически, компилятор
запросто может расположить любую константу в read-only.

1

Сообщение от hoggy да это не важно. теоретически, компилятор запросто может расположить любую константу в read-only.

Я не представляю себе стоимости обращения к такой памяти и целесообразности такого мероприятия. Вот инициализируются 100500 объектов с константой (контрактом). И все поля лягут в закрытую от записи память?
Ну допустим в военных системах для врагов (на экспорт) это и целесообразно.
Если это так то это и есть аргумент.
Но это и значит, что константа - поле класса не является параметром состояния. Статическим членом класса она тоже не является. Просто какая-то чертовщина скрытая подтипизация.
Не люблю, когда математики пытаются писать определения для прикладных вещей.

0

hoggy,
вот теперь я понял в каком месте мы друг друга не понимаем ))

Сообщение от Undisputed другое дело как сильно будет болеть голова у тех кто будет отслеживать подобное что бы обеспечить эти гарантии

я не зря затронул вопрос реализации но ты видимо не придал этому значение
перефразирую:
да, то о чем ты говоришь это проблема
которую должна разрулить реализация что бы не было UB, например реализация может:
если где-то есть модифицированный const, который читается через std::launder
1) отследить такой вызов и если он есть то генерировать код, который не приведет к access violation.
2) не делать константы read only на уровне памяти и никаких access violation не будет.

Сообщение от hoggy зы: лично я вообще не понимаю, для каких сакральных нужд этот костыль завезли в стандарт.

например внутри контейнеров может быть полезно
некоторые из них используют вложенные классы для реализации узлов
поля этих узлов можно делать константными ведь так?
но как мы знаем память внутри контейнеров как правило переиспользуется
т.е в одном участке время от времени могут сидеть разные ноды с константными полями
значения которых так же может быть разным
и вот что бы их как то гарантировано прочитать
можно эту фичу и задействовать
что касается записи в эти поля - то как уже говорил выше, отсутствие access violation должна обеспечить реализация
ибо в стандарте четко написано что это рабочий код

а не как ты говоришь "если не свалится на placement new то только в этом случае".
таких оговорок в топике про std::launder просто нет

0

0

0

0

0

Сообщение от IGPIGP Я не представляю себе стоимости обращения к такой памяти и целесообразности такого мероприятия. Вот инициализируются 100500 объектов с константой (контрактом). И все поля лягут в закрытую от записи память?

технически, компилятор имеет право так сделать.
правил языка это не нарушает.

в чем сакральный смысл самого понятия "UB" ?
предполагается, что компиляторов может быть множество.
и не важно, как именно, они будут реализовывать ту,
или иную фичу.

стандарт описывает гарантии: как делать правильно.
во всех остальных кейсах - поведение не определенно.

стандарт запрещает модифицировать константу.
не важно почему:
один компилятор может запихать данные в read-only,
другой компилятор сделать inline-подстановку,
третий - ещё что нибудь,
и всё вышеперечисленное вместе.

суть одна:
ты не можешь закладываться,
что априори сама модификация константы пройдет успешно.
и не можешь закладываться,
что после модификации константы работа будет корректной.
не можешь закладываться даже если после такой модификации,
ты использовал std::launder,
потому что не можешь знать,
что и где ещё могло поломаться
после такого грубого нарушения правил игры.

ситуация, когда никто не даёт никаких гарантий и есть "UB".

Добавлено через 16 минут

Сообщение от Undisputed да, то о чем ты говоришь это проблема которую должна разрулить реализация что бы не было UB,

у тебя уже UB.
и оно никуда не делось.

Сообщение от Undisputed если где-то есть модифицированный const,

значит у тебя уже UB.

std::launder ты используешь уже в условиях UB.
что бы сбросить все эффекты возможных оптимизаций с указателя.
это может сработать.

но UB от этого не перестает быть UB.

Сообщение от Undisputed 1) отследить такой вызов и если он есть то генерировать код, который не приведет к access violation. 2) не делать константы read only на уровне памяти и никаких access violation не будет.

гениальная логика.
даже интересно: как ты эти два пункта реализуешь?

а может просто не писать говнокод,
который приводит к UB?

Сообщение от Undisputed например внутри контейнеров может быть полезно некоторые из них используют вложенные классы для реализации узлов поля этих узлов можно делать константными ведь так?

можно.
но потом в принципе нельзя будет делать new placement.

пример не годится.

ты не сможешь привести ни одного корректного примера,
потому что область применения std::launder - в некорректном коде.
он применяется, когда UB.

Сообщение от Undisputed что касается записи в эти поля - то как уже говорил выше, отсутствие access violation должна обеспечить реализация ибо в стандарте четко написано что это рабочий код

что за бред ты несешь?
где там написано, что это - рабочий код?
там написано, что std::launder сможет дотянуться
до измененного константного значения.
и это все, что там написано.

Сообщение от Undisputed а не как ты говоришь "если не свалится на placement new то только в этом случае". таких оговорок в топике про std::launder просто нет

такая оговорка есть во множестве пунктов.
undefined behaviour называется.

вот ты сам понимаешь, насколько тупо ты сам себе сейчас противоречишь?

- я изменил константу. но это - херня. ничего страшного не произошло - вообще то, у тебя теперь UB. а значит никаких гарантий. - код будет работать правильно невзирая на UB, потому что в пункте про std::launder нет оговорок про UB

я начинаю думать, что общаюсь с идиотом.

0