Re[72]: Когда это наконец станет defined behavior? - C/C++

Здравствуйте, σ, Вы писали:

σ>Только вот sequenced before никак не отменят, что при NRVO someDictionary обозначает тот же объект, что и result, как описано в https://timsong-cpp.github.io/cppwp/n4868/class.copy.elision#1.sentence-2
Здесь ссылка на sequenced before только для того, чтобы показать, что время жизни someDictionary ещё не началось.

BFE>>А пока вычисление выражения buildMap() не закончилось, время жизни константного объекта не началось:
BFE>>

σ>The lifetime of an object of type T begins when: ... its initialization (if any) is complete

σ>Ну и какая инициализация для этого объекта должа быть complete? Первая (std::map<int, int> result;) или последняя (которая для someDictionary)?
Последняя. Та, которая пропускается. Вы видимо не понимаете, что опущение (omitter) операции не отменяет момент старта времени жизни константного объекта.

BFE>>Запрет на модификацию константного объекта относится только ко времени жизни:
BFE>>

σ>Any attempt to modify a const object during its lifetime results in undefined behavior.

BFE>>Ну а так, как время жизни константного объекта ещё не началось, то изменять его можно.
BFE>>Нет тут никакого UB.

σ>Раз время жизни объекта не началось, то result.insert(42, 43); — вызов метода на объекте до начала времени жизни? Тогда получается UB есть.
Разумеется это не так. Объект может изменятся внутри конструктора, т.е. до начала lifetime.

σ>>>Или объект сначала вроде как создаётся константным (const std::map<int, int> someDictionary), но потом становится неконстантным (std::map<int, int> result;), а опять константным не становится, и его можно менять даже после const std::map<int, int> someDictionary = buildMap();?
BFE>>Близко нет.
σ>Ты наверное опечатался когда хотел написать «ближе нет»?
Нет.

σ>По крайней мере кое-то в CWG согласен, что, видимо, согласно текущему тексту стандарта, такое описание самое (формально) корректное

.
σ>В общем, я спалил ответ на свой вопрос, по крайней мере соответствующий стандарту буквально (насколько стандарт тут дефектен, это отдельный разговор), а ты даже не понял.

апелляция к авторитету
Вы ошибаетесь и ваш авторитет ошибается. Я же вас с самого начала предупреждал, что попытка описания на естественном языке формального поведения однозначно приведёт к проблемам толкования.
И ваше описание формально не корректно. Если формально, то константный объект не может становится неконстантным: A const object is an object of type const T. Другое дело, что есть периоды существования объекта (не путайте со временем жизни), когда константный объект можно изменять.
А то, что вы тут описываете, это неформальное описание, которое даёт тот же видимый эффект, но верным от этого не становится.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, vopl, Вы писали:

V>>>>Выше по ветке это уже проходили, там implicit create позиционировался как не имеющий отношения к create..

S>>>А он и не имеет. implicit create не создает объектов, он возвращает указатель на объект, для которого лайвтайм будет считаться начатым. Но созданием объектов implicit create не занимается.

V>>https://timsong-cpp.github.io/cppwp/intro.object#1.sentence-2
V>>

An object is created by a definition, by a new-expression ([expr.new]), by an operation that implicitly creates objects (see below), when implicitly changing the active member of a union, or when a temporary object is created ([conv.rval], [class.temporary]).

S>Ну вот еще раз люди читают стандарт и теряют из виду смысл происходящего (это как за деревьями не видеть леса).

S>А смысл такой: в C++ объекты должны быть созданы (т.е. у них должен начаться lifetime) видимым для компилятора образом. Если появляется указатель на что-то, что компилятор не может определить как корректно созданный объект (с начатым lifetime), то компилятор волен сотворить разное. При этом в реальной жизни случаются ситуации, когда объекты создаются невидимым для компилятора образом (скажем, посредством вызова calloc, посредством чтения с диска в память или посредством отображения из разделяемой памяти). И тогда возникает вопрос как указать компилятору, что у нас корректный объект, а не херня какая-то.

S>И вот для решения этой проблемы (причем в большей степени для решения проблемы того, как описать это в стандарте) и сделали термин implicitly creates. Т.е. применение некоторых конструкций (вроде каста возвращенного calloc-ом результата к указателю на некий T) якобы создает объект типа T.

S>Хотя, на самом деле, здесь нет никакого создания. Создание (а именно выделение места и инициализация этого места должным образом) лежит на пользователе. Т.е., по факту, implicitly creates означает, что пользователь сделал все вручную, но затем компилятор согласился считать полученный пользователем указатель валидным указателем на объект с начатым lifetime.

S>Вот, собственно, и все.

S>Именно так и следует объяснять происходящее обычным разработчикам. Чтобы они понимали, что создание объекта через new -- это одно. Создание объекта на стеке -- другое. Легитимизация указателя на содержимое объекта полученное через разделяемую память -- третье. Хотя с точки зрения текста стандарта это все типа "creates".

S>Вот если бы происходящее в языке C++ объясняли такими простыми словами, лично моя жизнь была бы сильно проще.

Обычные разработчики тут не при чем. Я конечно могу начать придумывать что такое "создание объекта", и может быть даже моя придумка совпадет с твоей, но это будет лишь субъектив, с большой вероятностью отличающийся от реалий. Если честно — мне становится немного не по себе от сложившейся ситуации. Приведена выдержка из стандарта, в которой определяется что суть есть "object creation". И как после нее можно заявлять о потере смысла? Она и определяет смысл. Она есть смысл. Какой еще lifetime

Приведено оригинальное определение. В нем нет ни слова про lifetime. Думаю далее нет смысла продолжать

σ>>Это не моя точка зрения. Это стандарт. Поищи по слову created, например.

S>Это уже заход на какой-то N-ый круг.

Т.е. ты уже N кругов ищешь по слову created (ну и читаешь, что нашёл, естественно), но так и не понял разницу между an object is created и object lifetime starts?

σ>>Не прикидывайся. Появляется только объект типа const demo. Это не только здравому смыслу соответствует.

S>Только вот фокус в том, что пока инициализация const demo d не завершилась, есть объект типа demo.

Пруф?

σ>>Т.е. ты всё это время пытался выродить мысль, что внутри f lookup для имени d найдёт переменную d только в точке программы после const demo d?

S>Нет, про lookup имен я вообще ничего не говорил. Речь про то, когда объекты начинают жить и в каком виде.

σ>>Как это влияет на тип объекта?

S>Тем, что внутри конструктора мы имеем demo. После его успешного завершения уже const demo.

Пруф?

S>>>В ней написано про момент, когда объект уже "типа есть" но лайфтайм для него начатым еще не считается.

σ>>И какого же типа этот объект?

S>Внутри конструктора -- demo.

Пруф?

S>Ну как-то так получается, что эмпирический опыт исходя из которого я здесь привожу примеры, основан на C++.

Нет, он не основан на C++. Твой эмпирический опыт — это максимум взаимодействие с некоторыми т.н. реализациями C++.
Ну и, самое главное, ты ведь приводишь не свой опыт, а вещаешь свои кривые его интерпретации.

Здравствуйте, vopl, Вы писали:

V>Нет. Никаких "сперва". Константный объект снаружи и не-константный объект внутри, в случае NRVO это "один и тот же объект" (да, звучит как коллизия, но все же, так написано в стандарте). То есть, наружный константный объект модифицируется внутри функции через неконстантное имя. Это все есть одновременно, а не "сначала/затем"

Ну и как добиться этой одновременности из потока исполнения абстрактного С++ вычислителя над программой?
1. Оно не одновременно в описании исходника;
2. Оно не одновременно в рантайме.

В то время как ваше UB требует иметь на руках неконстантную ссылку/указатель на объект (или на область памяти объекта), про который компилятор уже сделал умозаключение, что объект константный.

V>Вот эта посылка не верна. Объект снаружи и внутри — это по стандарту "один и тот же объект".
V>Его время жизни стартует внутри функции после отработки конструктора.

Для внешнего кода время жизни объекта стартует после возврата из ф-ии и вызова конструктора копирования от неконстантного prvalue.
(то, что конструктор копирования не вызывается — внешний код об этом даже не догадывается)

V>После этого он одновременно и является константным (потому что снаружи задекларирован так) и модифицируется внутри функции.

Для UB недостаточно декларации — с объектом надо что-то "делать", чтобы наблюдать "поведение", которое вы обещали "потенциально неопределённое".

До возврата из ф-ии с объектом ничего сделать нельзя.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, σ, Вы писали:

σ>>>>И что «lifetime»? Он начинается внутри функции, после инициализации result.
BFE>>>Когда начинается lifetime объекта someDictionary ? Тогда, когда заканчивается конструирование объекта.
σ>>Ну. При NRVO, оно заканчивается на std::map<int, int> result;.

BFE>Нет, конечно. Даже при NRVO вычисление значения выражения buildMap() должно быть выполнено до начала инициализации someDictionary. Это следует из описания sequenced before.
BFE>А пока вычисление выражения buildMap() не закончилось, время жизни константного объекта не началось:
BFE>

BFE>The lifetime of an object of type T begins when: ... its initialization (if any) is complete

BFE>Запрет на модификацию константного объекта относится только ко времени жизни:
BFE>

BFE>Any attempt to modify a const object during its lifetime results in undefined behavior.

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

Но. В силу NRVO — result и someDictionary есть один и тот же объект, его лайфтайм начинается не так как ты тут описал

Здравствуйте, vopl, Вы писали:

V>Но. В силу NRVO — result и someDictionary есть один и тот же объект, его лайфтайм начинается не так как ты тут описал
Формально, нет:

In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object.

treat — behave toward or deal with in a certain way.
referring to — ссылаться на.

Здесь не говорится, что объект один и тот же. Здесь говорится, что с этими объектами работают, как с одним объектом опуская некоторые операции. Нигде не сказано, что пропуск операции — это тоже самое, что её отсутствие.

Здравствуйте, σ, Вы писали:

σ>Т.е. ты уже N кругов ищешь по слову created (ну и читаешь, что нашёл, естественно), но так и не понял разницу между an object is created и object lifetime starts?

А вы все эти N кругов занимаетесь начетничеством.

σ>>>Не прикидывайся. Появляется только объект типа const demo. Это не только здравому смыслу соответствует.

S>>Только вот фокус в том, что пока инициализация const demo d не завершилась, есть объект типа demo.

σ>Пруф?

Уже приводился в виде примеров кода и от меня, и от T4r4sB. Внутри конструктора this указывает на demo, а не на const demo.

S>>Тем, что внутри конструктора мы имеем demo. После его успешного завершения уже const demo.

σ>Пруф?

Сделайте typeid для d.

S>>Ну как-то так получается, что эмпирический опыт исходя из которого я здесь привожу примеры, основан на C++.

σ>Нет, он не основан на C++. Твой эмпирический опыт — это максимум взаимодействие с некоторыми т.н. реализациями C++.
σ>Ну и, самое главное, ты ведь приводишь не свой опыт, а вещаешь свои кривые его интерпретации.

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, vopl, Вы писали:

V>>Нет. Никаких "сперва". Константный объект снаружи и не-константный объект внутри, в случае NRVO это "один и тот же объект" (да, звучит как коллизия, но все же, так написано в стандарте). То есть, наружный константный объект модифицируется внутри функции через неконстантное имя. Это все есть одновременно, а не "сначала/затем"

V>Ну и как добиться этой одновременности из потока исполнения абстрактного С++ вычислителя над программой?
V>1. Оно не одновременно в описании исходника;
V>2. Оно не одновременно в рантайме.

выше показывал как:
1. исходя из внешней декларации — объект является константным (по определению декларации из стандарта — тип декларируемого объекта принимается такой, который указан при декларации этого объекта. Ссылку на стандарт могу поискать, мелькала тут выше по теме вроде)
2. его время жизни началось так как внутри функции отработала его инициализация (конструктор завершил работу). Обращаю внимание, на этот момент действие пункта 1. распространяется в полной мере, объект сейчас константный
3. он используется как неконстантный — внутри функции через неконстантное имя объекту производится модификация полей. Снова обращаю внимание, на этот момент действие пункта 1. распространяется в полной мере, объект сейчас константный

Вот так и добились

V>В то время как ваше UB требует иметь на руках неконстантную ссылку/указатель на объект (или на область памяти объекта), про который компилятор уже сделал умозаключение, что объект константный.

Никаких ссылок/указателей. Доступ к объекту производится по его именам, коих два, одно снаружи функции другое внутри. Внешнее имя типизировано константно. Внутреннее — не константно.

И ни о каких областях памяти говорить не нужно, это совершенно другой аспект.

V>>Вот эта посылка не верна. Объект снаружи и внутри — это по стандарту "один и тот же объект".
V>>Его время жизни стартует внутри функции после отработки конструктора.

V>Для внешнего кода время жизни объекта стартует после возврата из ф-ии и вызова конструктора копирования от неконстантного prvalue.
V>(то, что конструктор копирования не вызывается — внешний код об этом даже не догадывается)

Время жизни объекта по стандарту стартует после отработки конструктора, то есть, после того как конструктор отработал — объект живой. А конструктор (для объекта который один и тот же — внутренний и внешний) отрабатывает внутри функции. То есть, время жизни объекта, доступного по внешнему имени (вроде в примере это было someDictionary) начинается внутри функции, после отработки конструктора для result

V>>После этого он одновременно и является константным (потому что снаружи задекларирован так) и модифицируется внутри функции.

V>Для UB недостаточно декларации — с объектом надо что-то "делать", чтобы наблюдать "поведение", которое вы обещали "потенциально неопределённое".

Для UB достаточно выполнить эти условия:

Any attempt to modify a const object during its lifetime results in undefined behavior.

И эти условия выполнены.

V>До возврата из ф-ии с объектом ничего сделать нельзя.
а это уже не важно

BFE>>>А пока вычисление выражения buildMap() не закончилось, время жизни константного объекта не началось:
BFE>>>

σ>>The lifetime of an object of type T begins when: ... its initialization (if any) is complete

σ>>Ну и какая инициализация для этого объекта должа быть complete? Первая (std::map<int, int> result;) или последняя (которая для someDictionary)?
BFE>Последняя. Та, которая пропускается. Вы видимо не понимаете, что опущение (omitter) операции не отменяет момент старта времени жизни константного объекта.

Короче. (При NRVO) возможны только две вещи, если ты хочешь прицепиться к лайфтайму и инициализации
1. Если лайфтайм начинается после первой инициализации, то объект константный уже в функции и его модифицировать — UB
2. Если после последней, то объект вне lifetime на протяжении выполнения всей функции, и его модифицировать — UB

BFE>>>Запрет на модификацию константного объекта относится только ко времени жизни:
BFE>>>

σ>>Any attempt to modify a const object during its lifetime results in undefined behavior.

BFE>>>Ну а так, как время жизни константного объекта ещё не началось, то изменять его можно.
BFE>>>Нет тут никакого UB.

σ>>Раз время жизни объекта не началось, то result.insert(42, 43); — вызов метода на объекте до начала времени жизни? Тогда получается UB есть.
BFE>Разумеется это не так. Объект может изменятся внутри конструктора

И к чему ты это? По-твоему, std::map<int, int> buildMap() это конструктор?

σ>>>>Или объект сначала вроде как создаётся константным (const std::map<int, int> someDictionary), но потом становится неконстантным (std::map<int, int> result;), а опять константным не становится, и его можно менять даже после const std::map<int, int> someDictionary = buildMap();?
BFE>>>Близко нет.
σ>>Ты наверное опечатался когда хотел написать «ближе нет»?
BFE>Нет.

σ>>По крайней мере кое-то в CWG согласен, что, видимо, согласно текущему тексту стандарта, такое описание самое (формально) корректное

.
σ>>В общем, я спалил ответ на свой вопрос, по крайней мере соответствующий стандарту буквально (насколько стандарт тут дефектен, это отдельный разговор), а ты даже не понял.
BFE>

апелляция к авторитету

Не в тему.

BFE>Вы ошибаетесь и ваш авторитет ошибается. Я же вас с самого начала предупреждал, что попытка описания на естественном языке формального поведения однозначно приведёт к проблемам толкования.

Если я не дал релевантных ссылок, это ещё не делает его описанием на естественном языке. То, что я описал, вполне формально-буквально следует из стандарта.

BFE>И ваше описание формально не корректно. Если формально, то константный объект не может становится неконстантным: A const object is an object of type const T.

И как из этой цитаты следует, может или не может?

Интересно самому найти формальное описание? Или мне привести?

Могу пока дать поцсказку. Ты ведь, надеюсь, в курсе, чем создание объекта отличается от начала его времени жизни? Ну так вот. Ты, похоже, забыл, что создание объекта sequenced before, и сразу перескочил на описание начала времени жизни, и зря. Почитай внимательно про создание объекта

BFE>Другое дело, что есть периоды существования объекта (не путайте со временем жизни), когда константный объект можно изменять.

С этим кто-то спорил? Я на это даже ссылку давал в https://rsdn.org/forum/cpp/8585023.1
Только этот параграф тут ни при чём.

BFE>А то, что вы тут описываете, это неформальное описание, которое даёт тот же видимый эффект, но верным от этого не становится.

Я описываю формальное описание.

Здравствуйте, vopl, Вы писали:

V>Приведена выдержка из стандарта, в которой определяется что суть есть "object creation". И как после нее можно заявлять о потере смысла? Она и определяет смысл. Она есть смысл.

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

V>Какой еще lifetime

Приведено оригинальное определение. В нем нет ни слова про lifetime.

Или нужно просто посмотреть на чуть более расширенную цитату (https://timsong-cpp.github.io/cppwp/basic.memobj#intro.object-1):

The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is created by a definition, by a new-expression ([expr.new]), by an operation that implicitly creates objects (see below), when implicitly changing the active member of a union, or when a temporary object is created ([conv.rval], [class.temporary]). An object occupies a region of storage in its period of construction ([class.cdtor]), throughout its lifetime, and in its period of destruction ([class.cdtor]).

[Note 1: A function is not an object, regardless of whether or not it occupies storage in the way that objects do. — end note]

The properties of an object are determined when the object is created. An object can have a name ([basic.pre]). An object has a storage duration ([basic.stc]) which influences its lifetime ([basic.life]). An object has a type ([basic.types]).

[Note 2: Some objects are polymorphic ([class.virtual]); the implementation generates information associated with each such object that makes it possible to determine that object's type during program execution. — end note]

Т.е. в разделе про создание объектов уже ссылаются на lifetime.

Здравствуйте, σ, Вы писали:

σ>Ну и какая инициализация для этого объекта должа быть complete? Первая (std::map<int, int> result;) или последняя (которая для someDictionary)?

Всего тут 3 лайфтайма:
— локальной переменной внутри buildMap;
— безымянного/временного возвращённого значения;
— целевого константного, получаемого конструктором копирования.

Все три объекта живут последовательно.

А что касается оптимизаци... ))

Вот тут:

#include <iostream>

class SomeObj {
public:
    SomeObj(int i) : index{i} {}
    
    //SomeObj(SomeObj && other) = delete;

    int index;
};

SomeObj buildObj() {
    SomeObj result = 42;
    result.index = 43;
    return result;
}

int main() {
    const SomeObj obj = buildObj();
    const_cast<int&>(obj.index) = 44;
    std::cout << obj.index;
}

после оптимизации даже не создаётся объект:

main:
        sub     rsp, 8
        mov     esi, 44
        mov     edi, OFFSET FLAT:_ZSt4cout
        call    std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
        mov     eax, 0
        add     rsp, 8
        ret

просто выводится 44 в cout.
А могло бы вывести 43. ))
Бо там UB в const_cast<int&>(obj.index) = 44;, а не при объявлении объекта.

Здравствуйте, so5team, Вы писали:

S>Какой-то здесь, право слово, фигней страдают, пытаясь найти некий гипотетический UB. Хотя с NRVO и получением константного объекта из неконстантного можно запросто наступить на несложные грабли:

Блин, недочитал до сюда, породил аналогичный пример:
http://www.rsdn.org/forum/cpp/8585549.1

σ>>Т.е. ты уже N кругов ищешь по слову created (ну и читаешь, что нашёл, естественно), но так и не понял разницу между an object is created и object lifetime starts?

S>А вы все эти N кругов занимаетесь начетничеством.

И?

σ>>>>Не прикидывайся. Появляется только объект типа const demo. Это не только здравому смыслу соответствует.

S>>>Только вот фокус в том, что пока инициализация const demo d не завершилась, есть объект типа demo.

σ>>Пруф?

S>Уже приводился в виде примеров кода и от меня, и от T4r4sB. Внутри конструктора this указывает на demo, а не на const demo.

Пример кода это не пруф.

S>>>Тем, что внутри конструктора мы имеем demo. После его успешного завершения уже const demo.

σ>>Пруф?

S>Сделайте typeid для d.

Это, по-твоему, пруф?

S>>>Ну как-то так получается, что эмпирический опыт исходя из которого я здесь привожу примеры, основан на C++.

σ>>Нет, он не основан на C++. Твой эмпирический опыт — это максимум взаимодействие с некоторыми т.н. реализациями C++.
σ>>Ну и, самое главное, ты ведь приводишь не свой опыт, а вещаешь свои кривые его интерпретации.

S>Да я бы с удовольствием выслушал то, как оно должно быть и поучился бы. Но... Вы же не можете связно изложить что к чему и почему

Тащем-та могу. Хочу на попытки других посмотреть.

Здравствуйте, vdimas, Вы писали:

S>>Какой-то здесь, право слово, фигней страдают, пытаясь найти некий гипотетический UB. Хотя с NRVO и получением константного объекта из неконстантного можно запросто наступить на несложные грабли:

V>Блин, недочитал до сюда, породил аналогичный пример:
V>http://www.rsdn.org/forum/cpp/8585549.1

Ага. При этом я был сильно удивлен тому, насколько похожими они получились, а ведь мы не сговаривались

Здравствуйте, σ, Вы писали:

S>>А вы все эти N кругов занимаетесь начетничеством.

σ>И?

И это не есть хорошо.

σ>Пример кода это не пруф.

Ну, некоторые думают, что практика -- это критерий проверки теории. Ошибаются, наверное.

S>>Сделайте typeid для d.

σ>Это, по-твоему, пруф?

Да.

S>>Да я бы с удовольствием выслушал то, как оно должно быть и поучился бы. Но... Вы же не можете связно изложить что к чему и почему

σ>Тащем-та могу. Хочу на попытки других посмотреть.

Не вопрос, я подожду. Учиться никогда не поздно.

σ>>Пример кода это не пруф.

S>Ну, некоторые думают, что практика -- это критерий проверки теории.

Да пожалуйста. Только сначала теоретически опиши, чтобы было чего проверять

От одного тут попросил описать ожидаемое поведение — в ответ только пикрил

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, vopl, Вы писали:

V>>Но. В силу NRVO — result и someDictionary есть один и тот же объект, его лайфтайм начинается не так как ты тут описал
BFE>Формально, нет:
BFE>

BFE>In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object.

BFE>treat — behave toward or deal with in a certain way.
BFE>referring to — ссылаться на.

BFE>Здесь не говорится, что объект один и тот же. Здесь говорится, что с этими объектами работают, как с одним объектом опуская некоторые операции. Нигде не сказано, что пропуск операции — это тоже самое, что её отсутствие.

Вот это поворот

.. Какая разница, "он один и тот же" или "действия с ними трактуются как с одним и тем же". Если "действия с ними трактуются как с одним" — то логика такая:

внешнее и внутреннее имена трактуются как если они ссылаются на один и тот же объект. Тогда время жизни объекта, означенного внешнем именем — трактуется как время жизни как будто бы "того же объекта". То есть, не важно как мы эту штуку назовем — один и тот же объект, или "нечто трактуемое как один и тот же объект" — все эффекты около этой штуки будут одинаковыми в обоих случаях. Более того, эти два подхода не различимы, не возможно определить, имеем мы дело с "одним и тем же объектом" или с чемто, "с чем работать нужно как с одним и тем же"

	От:	B0FEE664
	Дата:	22.08.23 10:42
	Оценка:

	От:	vopl
	Дата:	22.08.23 10:48
	Оценка:

	От:	σ
	Дата:	22.08.23 10:48
	Оценка:

	От:	vdimas
	Дата:	22.08.23 10:48
	Оценка:

	От:	vopl
	Дата:	22.08.23 10:52
	Оценка:

От:	so5team	https://stiffstream.com
Дата:	22.08.23 11:09
Оценка: