Должна ли стандартная библиотека С++ быть реализована на С++?

  1. Должна ли соответствующая реализация стандартной библиотеки C++ быть реализована на C++?
  2. Если нет, разрешено ли делать магические вещи, которые невозможно выполнить в чистом C++ и стандартной библиотеке, а также в некотором поведении, определенном реализацией?
  • Мне известно, что существуют параллельные реализации, основанные на расширениях (по крайней мере, до C++11), но соответствуют ли они требованиям?
  • Я не смог найти ни одного требования в стандарте, но, возможно, мой стандарт сегодня слаб

c++ standards-compliance c++-standard-library
person Sebastian Mach    schedule 06.02.2012    source источник
comment
Мне вспоминается цитата о положении в стране: если президент покупает Конгрессу подписку на Wall Street Journal, он выполняет свои конституционные обязательства!   -  person spraff    schedule 06.02.2012
comment
Правило «как если бы» позволяет реализации выбирать любую реализацию, которая ей нравится.   -  person Raymond Chen    schedule 06.02.2012

Ответы (3)


arrow_upward
9
arrow_downward

No.

На самом деле, Стандарт даже предписывает, что #include <map> (например) может просто импортировать предварительно сохраненный AST и вообще не ссылаться на файл.

person Matthieu M.    schedule 06.02.2012
comment
Позвольте мне принять это. Ответ Дитмарса имхо менее конкретен, чем ваш. - person Sebastian Mach; 23.02.2012

arrow_upward
19
arrow_downward

Нет никаких требований к тому, как реализована стандартная библиотека C++ (или стандартная библиотека C, если уж на то пошло). Все, чего должна достичь библиотека, — это реализовать задокументированный и указанный интерфейс. Как это сделать, полностью зависит от реализации. Часть стандартных библиотек часто каким-то волшебным образом реализуется компилятором, а в C++2011 есть несколько интерфейсов, которые на самом деле нельзя реализовать стандартными средствами языка C++2011! В первую очередь это верно для некоторых черт в <type_traits>, но есть и другие вещи.

Просто для справки: как реализован C++ и что на самом деле означает соответствие стандарту, остается крайне расплывчатым. Соответствующий пункт — 1.4 [intro.compliance]. Это просто говорит о выдаваемой диагностике и о том, что программа должна делать, однако ограничение ресурсов.

person Dietmar Kühl    schedule 06.02.2012
comment
+1: Я сам являюсь умеренным писателем шаблонов, и мне действительно любопытно, какие это будут черты типа. - person Sebastian Mach; 06.02.2012
comment
Вам не нужны какие-либо последние дополнения, чтобы найти то, что невозможно реализовать с помощью стандартных средств языка. В самом языке нет концепции ввода-вывода, поэтому filebuf и др. нужно что-то большее (во всяком случае, Posix --- но это не стандартный C++). На самом деле тот факт, что что-то полезно даже для небольшого сообщества, но не может быть реализован с помощью стандартных языковых конструкций, часто является мотивацией для добавления этого в библиотеку. (В C это был аргумент, заданный для offsetof.) - person James Kanze; 06.02.2012
comment
@phresnel: у меня нет доступного исчерпывающего списка вещей, которые нельзя реализовать без поддержки компилятора. Однако такие вещи, как is_trivially_default_constructible, должны будут проверить информацию о том, как на самом деле объявлен конструктор по умолчанию или синтезирован ли он. Некоторые компиляторы реализуют различные признаки типа, но они часто реализуют больше, чем это абсолютно необходимо, потому что компилятор может быть намного эффективнее, сообщая определенные свойства, вместо того, чтобы проверять несколько надуманные экземпляры. - person Dietmar Kühl; 06.02.2012
comment
@JamesKanze: я немного уточнил свой второй вопрос, включив в него поведение, определяемое реализацией. Не должно ли это насыщать требования ввода-вывода? - person Sebastian Mach; 06.02.2012
comment
@JamesKanze: Ну да, стандарт ничего не определяет, например, как осуществляется доступ к файловым дескрипторам. Однако, если вы работаете на платформе, на которой можно использовать семейство функций файлового дескриптора (например, на платформе POSIX), вы можете реализовать все операции с файловым потоком на C++ без вызовов соответствующих системных вызовов. Я бы подумал, что это считается реализованным в C++, но я согласен, что другие определения того, что это означает, вполне разумны, возможно, даже более разумны. - person Dietmar Kühl; 06.02.2012
comment
@phresnel Я так не думаю, по крайней мере, с точки зрения стандарта C ++. В C++ нет языковой конструкции, которая будет передавать байты из ОС в вашу программу. И стандарт C++ говорит, что все, что не указано иным образом в стандарте, является неопределенным поведением. (И это языковая юриспруденция в самом крайнем ее проявлении — на практике вы всегда имеете в своем распоряжении другие стандарты, такие как Posix, которые определяют поведение.) - person James Kanze; 06.02.2012
comment
@DietmarKühl Как? Как получить байты из ОС в объект C++ (массив char или что-то еще), не выходя за пределы языка C++ (который, насколько я могу судить, даже не признает существование байтов вне программы)? - person James Kanze; 06.02.2012
comment
@JamesKanze: я согласен, что использование, например. функций POSIX выходит за рамки стандарта C++, и без использования соответствующей функциональности (будь то библиотека C, ловушки или что-то еще) вы не сможете реализовать, например. файловые потоки. Очевидно, я согласен с тем, что стандарт, включая его библиотеку, не может быть реализован на стандартном C++ без них. - person Dietmar Kühl; 06.02.2012
comment
C++2011 в каком-то смысле правильный, но разве он не называется C++11? - person L. F.; 02.05.2019

arrow_upward
2
arrow_downward

Вовсе нет, только интерфейс должен быть C++.

person spraff    schedule 06.02.2012
comment
Что ты этим имеешь ввиду? #include <some-std-header> не обязательно включать файл: он может просто уведомить компилятор об определенных определениях, которые будут доступны в единице перевода, т.е. я также не думаю, что интерфейс должен быть на C++. Это несколько зависит от того, что вы считаете interface, хотя... - person Dietmar Kühl; 06.02.2012
comment
Я тоже так думаю (но догадки не должны быть частью вопроса :)), но я больше искал ссылки или цитаты. - person Sebastian Mach; 06.02.2012
comment
@DietmarKühl Я считаю, что эта техника действительно использовалась Visual Age. - person James Kanze; 06.02.2012