стандарты — Какова потенциальная выгода от того, что потоки C ++ и C могут буферизоваться независимо?
C ++ iostreams обеспечивает контроль того, должны ли потоки C ++ синхронизироваться с потоками C через std::ios_base::sync_with_stdio(), Отключение синхронизации потоков позволяет стандартной реализации библиотеки использовать независимые несинхронизированные буферы для потоков C ++ и потоков C, чтобы потенциально повысить производительность.
Почему считалось важным оставить открытой возможность для разработчиков использовать отдельные независимые наборы буферов ввода-вывода для потоков C и C ++? Я не вижу, как это может потенциально улучшить производительность по сравнению с одним набором буферов ввода-вывода. Разрешение стандартной библиотеке одного набора буферов ввода-вывода на программном уровне может уменьшить количество обычно дорогостоящих вызовов к базовым средствам ОС ввода-вывода, но в чем может быть преимущество двух наборов буферов ввода-вывода?
Есть ли техническая причина, по которой отдельные буферы для потоков C и C ++ могут повысить производительность, или проект является просто историческим артефактом?
Имеет ли это какое-то отношение к комитету, желающему, чтобы разработчики C ++ могли реализовать стандартную библиотеку C ++, опираясь на свои существующие реализации стандартной библиотеки C?
Я ищу больше, чем «стандарт так говорит».
Если для объяснения логического обоснования необходимы характеристики ОС, ответы могут быть использованы в качестве примеров возможностей, предоставляемых реальной ОС, или для объяснения гипотетической, но разумной ОС.
Редактировать: Чтобы уточнить, вопрос не в том, почему синхронизация потоков может нанести ущерб производительности. Вопрос в том, почему стандарт C ++ был разработан с предположением, что вообще может быть два набора буферов ввода-вывода, и почему оставить эту возможность открытой полезно для разработчиков. std::ios_base::sync_with_stdio() просто случается следствие этого предположения.
Решение
В отличие от некоторых стандартов, которые были написаны, чтобы предписывать поведение вещей, которые еще не были построены, стандарт C ++, как и стандарт C, был написан для описания поведения вещей, которые уже существовал. Авторы стандарта хотели избежать всего, что могло бы затруднить разработку соответствующей реализации C ++ для платформы, которая работала бы так же, как и более ранние предстандартные реализации для этой платформы.
Если бы было несколько реализаций, чьи потоки C ++ поддерживали некоторые дополнительные платформо-зависимые функции, не предписанные Стандартом, то соответствующая реализация C ++ могла бы не поддерживать одновременно эти функции, а также использовать те же конструкции буферизации, что и в C <stdio.h> пакет. Для авторов стандарта может оказаться невозможным избежать требования, чтобы реализации были неспособны поддерживать такую расширенную семантику, или же позволить им буферизовать свои потоки независимо от потоков <stdio.h>, Учитывая, что ничто не помешало бы конкретным реализациям гарантировать, что потоки обеих библиотек будут использовать одни и те же буферы независимо от того, требует ли это Стандарт или нет, последний вариант имел бы смысл, если бы существовала какая-либо вероятность того, что более сильное требование будет иметь какие-либо полезные функции реализации.
Другие решения
Других решений пока нет …
detector