Является ли неопределенным поведение передача указателя на несконструированный объектstreambuf в конструктор ostream?

Язык, который вы процитировали

Для объекта с нетривиальным конструктором обращение к любому нестатическому члену или базовому классу объекта до начала выполнения конструктора приводит к неопределенному поведению. [...]

может показаться, что это неопределенное поведение - вы ссылаетесь на базовый класс (std::streambuf) объекта до запуска конструктора. То, что происходит в конструкторе ostream, не имеет значения.

Итак, ответ @JerryCoffin верен, но против него есть возражение на том основании, что, хотя стандарт четко определяет, что basic_ios::init() делает, он не указывает, чего он не делает. Итак (возражение звучит), хотя стандарт утверждает, что единственное, что basic_ios::init() делает с переданным указателем, — это сравнивает его с nullptr и сохраняет его… он также может разыменовать его, что вызовет UB в описанной ситуации.

Хорошо, давайте предположим, что логика имеет смысл.

Итак, поскольку basic_ios::init() «может» разыменовать указатель и поскольку конструктор basic_ostream вызывает basic_ios::init(), мы не можем передать указатель члену. Итак, мы не можем этого сделать:

class myostream :
    public std::ostream
{
    std::streambuf _buf;

public:
    myostream() : std::ostream{&_buf} {}

    // other stuff...
};

Потому что, хотя стандарт определяет, что постусловия проводника ostream (косвенно/транзитивно) просто сравнивают указатель, переданный в nullptr, и сохраняют копию… постусловия не обязательно являются исчерпывающими. Поэтому по каким-то неизвестным причинам он может разыменовать указатель.

Если да, то это будет UB. Так как же нам этого избежать?

Предлагаемое решение выглядит следующим образом:

class myostream :
    private std::streambuf,
    public std::ostream
{
public:
    myostream() : std::ostream{this} {}

    // other stuff...
};

Так здорово! Проблема решена, да?

Ну нет.

Потому что, видите ли, стандарт не говорит, что конструктор ostream или basic_ios::init() не удаляет переданный указатель.

basic_ios::init() может сделать это:

auto basic_ios::init(streambuf* p_buf)
{
    // do all the stuff init() is specified to do, and then...

    delete p_buf;
}

Почему нет? Постусловия не говорят явно, что буфер потока, на который указывает аргумент, не будет удален. И это не противоречит постусловиям.

Или, может быть, он делает это:

auto basic_ios::init(streambuf* p_buf)
{
    // do all the stuff init() is specified to do, and then...

    p_buf->~streambuf();
    
    ::new (static_cast<void*>(p_buf)) streambuf{};
}

Опять же, почему бы и нет? Это не будет буквально противоречить точной формулировке контракта basic_ios::init(), как указано в стандарте. Так что это может случиться, верно?

Если вы предполагаете, что basic_ios::init() может делать с указателем все, что в нем явно не указано, то ваша хитрая стратегия наследования тоже не сработает. На самом деле… буквально ничего не получится. Если basic_ios::init() разрешено делать БУКВАЛЬНО ВСЁ с указателем, который вы ему передаете — при условии, что это не противоречит явной формулировке контракта — тогда вы не можете ничего предполагать относительно указателя на буфер потока, который вы ему передаете. Вы не можете предположить, что он не будет уничтожен. Вы не можете предположить, что он будет уничтожен. Вы не можете предположить, что он не будет перезаписан.

В общем, basic_ios::init() просто невозможно использовать безопасно. Это означает, что невозможно создавать собственные потоки вывода, потому что мы должны вызвать basic_ios::init() прямо или косвенно в какой-то момент (перед деструктором или любой функцией-членом).

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

Или… может быть… где-то наша логика сбилась с рельсов.

Послушайте, люди, пишущие стандарт, делают это не ради группы игроков D&D, которые разбирают микросемантику каждого отдельного пункта правил в поисках способа обмануть систему. У комитета нет ни времени, ни терпения, чтобы удовлетворить желание каждого абсурдного фанатика, искажающего правила, найти лазейки. Они будут включать в себя столько явных деталей, сколько необходимо разумным разработчикам для создания реализаций, которые ведут себя согласованно друг с другом, и с пониманием того, что разумные читатели стандарта будут интерпретировать его.

Так что давайте подойдем к этому как разумные люди.

Стандарт определяет, что basic_ios::init() делает с переданным указателем. В нем ничего не говорится о разыменовании указателя, нет даже ненормативного примечания, предполагающего, что это может иметь место.

Да, здесь явно не указано, что указатель не будет разыменован (или удален, или что-то еще). Но учтите следующее: как я уже отмечал в другом комментарии, libc++ Clang в основном делает то же, что и первый блок кода выше. Если бы существовала разумная интерпретация контракта basic_ios::init(), подразумевающая, что указатель может быть разыменован… разве кто-нибудь не заметил бы проблему примерно за десять лет, пока libc++ широко использовался? Вам не кажется, что, может быть, один или два дезинфицирующих средства могли это заметить?

И из любопытства я также проверил исходный код стандартной библиотеки Microsoft. Да, он делает то же самое: передает указатель на элемент данных буфера потока. Это две основные широко используемые стандартные библиотеки. Я не знаю, как долго используется эта конкретная стандартная библиотека, но опять же… не думаете ли вы, что кто-нибудь уже поднял бы этот вопрос, если бы была разумная интерпретация стандарта, согласно которой этот указатель буфера потока мог бы быть де- на который ссылаются до создания буфера потока?

(И сейчас я не могу откопать свою копию «Лангер и Крефт», но я почти уверен, что они делают то же самое.)

Еще раз: будьте разумны. IOstreams входит в стандарт с 1998 года, и даже до этого она была широко используемой библиотекой, начиная с 1984 года. Формулировка тщательно изучалась, пересматривалась и изучалась в десятках и десятках отчетов о дефектах. Если бы фраза «он не говорит, что не имеет значения» была бы разумной интерпретацией стандартного определения basic_ios::init()… не думаете ли вы, что кто-то сделал бы что-нибудь по этому поводу где-то за последние ~30–40 лет? Не думаете ли вы, что кто-то, работающий над стандартной библиотекой Microsoft или со стандартной библиотекой Clang, или один из многих, многих людей, которые создали свои собственные пользовательские потоки (включая людей, создающих новые стандартные пользовательские потоки, как в сетевых предложениях) — указал бы на проблему?

Будь благоразумен. В стандарте не обязательно явно указывать, что указатель не будет разыменовываться, потому что было бы чертовски глупо поступать с указателем, который вы не указали, который должен указывать на действительный буфер потока. Все остальное в basic_ios следует этому рассуждению: деструктор также не удаляет указатель. Действительно, если бы basic_ios::init() было разрешено разыменовывать указатель, это сильно усложнило бы процесс создания пользовательского потока. А для чего? Ради какой выгоды? Почему библиотека IOStreams была бы лучше, если бы она позволяла basic_ios::init() разыменовывать указатель потока? Как это можно сравнить со многими способами, которые были бы намного хуже, если бы вы не могли предположить, что безопасно передавать указатель на буфер потока-члена?

Вывод: тот факт, что в стандартной формулировке явно не указано… что то, что она явно делает с указателем буфера потока, — это единственное, что он делает с ним… не означает, что он может делать какие-то случайные действия с указателем буфера потока. . Особенно вещи, которые могли бы привести к необратимым последствиям, если бы они были сделаны неожиданно. Если бы ему требовался указатель на действительный буфер потока, он бы так и сказал. Это не так, и вместо этого перечисляет кучу вещей, которые не требуют действующего буфера потока.

Предложение: не относитесь к стандарту как к загадке и разбирайтесь в его формулировках в поисках ловушек.

ЯСНО, что намерение basic_ios::init() состоит в том, чтобы просто сравнить указатель с nullptr и сохранить копию. Нет никакого смысла не иметь этого значения и вместо этого требовать от разработчиков потоков прибегать к гимнастике, такой как множественное наследование (или динамическое выделение с последующим rdbuf() для последующего получения указателя или другие дурацкие, окольные идеи). Я имею в виду… почему? Зачем вам так спроектировать библиотеку? Это было бы абсурдно. Зачем вам так без необходимости ограничивать очевидный и самый безопасный способ реализации потока с базовым буфером потока?

tl;dr: 1) @JerryCoffin прав в том, что поведение определяется разумным следствием стандартной формулировки. 2) Первый блок кода в порядке, и вы можете передать указатель на неинициализированный буфер потока в basic_ios::init(). 3) Две основные стандартные библиотеки работают таким образом и делают это на протяжении десятилетий без каких-либо проблем. 4) В стандарте C++ нет риторических ловушек.