20 Library introduction [library]

20.5 Library-wide requirements [requirements]

20.5.5 Conforming implementations [conforming]

20.5.5.1 Overview [conforming.overview]

В этом разделе описываются ограничения и широта реализаций стандартной библиотеки C ++.

Использование заголовков в реализации обсуждается в[res.on.headers]: использование макросов в[res.on.macro.definitions], функций, не являющихся членами, функций-[global.functions]членов в[member.functions], предотвращения гонки данных в[res.on.data.races], спецификаторов доступа в[protection.within.classes], производного класса в[derivation]и исключений в[res.on.exception.handling].

20.5.5.2 Headers [res.on.headers]

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

Некоторые типы и макросы определены более чем в одном заголовке. Каждый такой объект должен быть определен таким образом, чтобы любой заголовок, который его определяет, мог быть включен после любого другого заголовка, который также его определяет ([basic.def.odr]).

ОниC standard library headers должны включать только соответствующий заголовок стандартной библиотеки C ++, как описано в[headers].

20.5.5.3 Restrictions on macro definitions [res.on.macro.definitions]

Имена и подписи глобальных функций, описанные в[contents] , зарезервированы для реализации.

Все объектно-подобные макросы, определенные стандартной библиотекой C и описанные в этом разделе как расширяющиеся до целочисленных константных выражений, также подходят для использования в директивах предварительной обработки, если явно не указано иное.#if

20.5.5.4 Non-member functions [global.functions]

Не указано, определены ли какие-либо функции, не являющиеся членами, в стандартной библиотеке C ++ как inline.

Вызов сигнатуры функции, не являющейся членом, описанной в разделах[language.support] по[thread] и в приложении,[depr] должен вести себя так, как если бы реализация не объявила никаких дополнительных сигнатур функций, не являющихся членами.181

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

Если не указано иное, вызовы, выполняемые функциями в стандартной библиотеке для неоператорных функций, не являющихся членами, не используют функции из другого пространства имен, которые можно найти с помощью argument-dependent name lookup ([basic.lookup.argdep]). [ Note: Фраза «если не указано иное» применяется к таким случаям, как замена с требованиями ([swappable.requirements]). Исключение для перегруженных операторов разрешает поиск в зависимости от аргументов в следующих случаях ostream_­iterator​::​operator=:

Effects:

*out_stream << value;
if (delim != 0)
  *out_stream << delim;
return *this;

end note]

Допустимая программа на C ++ всегда вызывает ожидаемую библиотечную функцию, не являющуюся членом. Реализация также может определять дополнительные функции, не являющиеся членами, которые в противном случае не вызывались бы действительной программой C ++.

20.5.5.5 Member functions [member.functions]

Не указано, определены ли какие-либо функции-члены в стандартной библиотеке C ++ как inline.

Для невиртуальной функции-члена, описанной в стандартной библиотеке C ++, реализация может объявить другой набор сигнатур функций-членов при условии, что любой вызов функции-члена, который выберет перегрузку из набора объявлений, описанных в этом международном стандарте, ведет себя как если бы была выбрана эта перегрузка. [ Note: Например, реализация может добавлять параметры со значениями по умолчанию или заменять функцию-член с аргументами по умолчанию двумя или более функциями-членами с эквивалентным поведением или добавлять дополнительные подписи для имени функции-члена. ]end note

20.5.5.6 Constexpr functions and constructors [constexpr.functions]

Этот международный стандарт явно требует, чтобы определенные стандартные библиотечные функции были constexpr. Реализация не должна объявлять какую-либо сигнатуру стандартной библиотечной функции,constexpr за исключением тех, где это явно требуется. В любом заголовке, который предоставляет любые не определяющие объявления функций или конструкторов constexpr, реализация должна предоставлять соответствующие определения.

20.5.5.7 Requirements for stable algorithms [algorithm.stable]

Когда в требованиях к алгоритму указано, что он «стабилен» без дальнейшей разработки, это означает:

  • Дляsort алгоритмов сохраняется относительный порядок эквивалентных элементов.

  • Для алгоритмовremove иcopy сохраняется относительный порядок элементов, которые не удаляются.

  • Дляmerge алгоритмов для эквивалентных элементов в исходных двух диапазонах элементы из первого диапазона (с сохранением их исходного порядка) предшествуют элементам из второго диапазона (с сохранением их исходного порядка).

20.5.5.8 Reentrancy [reentrancy]

За исключением случаев, когда это явно указано в этом международном стандарте, это определяется реализацией, какие функции в стандартной библиотеке C ++ могут быть повторно введены рекурсивно.

20.5.5.9 Data race avoidance [res.on.data.races]

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

Функция стандартной библиотеки C ++ не должна прямо или косвенно обращаться к объектам ([intro.multithread]), доступным потокам, отличным от текущего потока, если к объектам не осуществляется прямой или косвенный доступ через аргументы функции, в том числеthis.

Функция стандартной библиотеки C ++ не должна прямо или косвенно изменять объекты ([intro.multithread]), доступные потокам, отличным от текущего потока, если к объектам не осуществляется прямой или косвенный доступ через неконстантные аргументы функции, включаяthis.

[ Note: Это означает, например, что реализации не могут использовать статический объект для внутренних целей без синхронизации, потому что это может вызвать гонку данных даже в программах, которые явно не разделяют объекты между потоками. ]end note

Функция стандартной библиотеки C ++ не должна обращаться к объектам, косвенно доступным через ее аргументы или через элементы аргументов контейнера, кроме как путем вызова функций, требуемых ее спецификацией, для этих элементов контейнера.

Операции с итераторами, полученные путем вызова контейнера стандартной библиотеки или строковой функции-члена, могут обращаться к базовому контейнеру, но не должны его изменять. [ Note: В частности, операции контейнера, которые делают итераторы недействительными, конфликтуют с операциями над итераторами, связанными с этим контейнером. ]end note

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

Если не указано иное, функции стандартной библиотеки C ++ должны выполнять все операции исключительно в текущем потоке, если эти операции оказывают влияние visible на пользователей.

[ Note: Это позволяет реализациям распараллеливать операции, если нет видимых побочных эффектов. ]end note

20.5.5.10 Protection within classes [protection.within.classes]

Не указано, является ли какая-либо сигнатура функции или класс, описанные в Разделах[language.support] по[thread] и Приложение[depr] , к friend другому классу в стандартной библиотеке C ++.

20.5.5.11 Derived classes [derivation]

Реализация может наследовать любой класс в стандартной библиотеке C ++ от класса с именем, зарезервированным для реализации.

Некоторые классы, определенные в стандартной библиотеке C ++, должны быть производными от других классов стандартной библиотеки C ++. Реализация может получить такой класс непосредственно из требуемой базы или косвенно через иерархию базовых классов с именами, зарезервированными для реализации.

В любом слючае:

  • Каждый базовый класс, описанный как, virtual должен быть виртуальным;

  • Каждый базовый класс, не указанный как virtual , не должен быть виртуальным;

  • Если явно не указано иное, типы с разными именами должны быть разными типами.182

Все типы, указанные в стандартной библиотеке C ++, не должны бытьfinal типами, если не указано иное.

Из этого правила есть неявное исключение для типов, которые описываются как синонимы для основных интегральных типов, таких как size_­t и streamoff.

20.5.5.12 Restrictions on exception handling [res.on.exception.handling]

Любая из функций, определенных в стандартной библиотеке C ++, может сообщать о сбое, генерируя исключение типа, описанного в его Throws: абзаце, или типа, производного от типа, названного в Throws: абзаце, которое будет перехвачено обработчиком исключений для базового типа. .

Функции из стандартной библиотеки C не должны вызывать исключения, 183 за исключением случаев, когда такая функция вызывает программную функцию, которая вызывает исключение.184

Операции деструктора, определенные в стандартной библиотеке C ++, не должны вызывать исключений. Каждый деструктор в стандартной библиотеке C ++ должен вести себя так, как если бы он имел спецификацию исключения, не вызывающего выброса.

Функции, определенные в стандартной библиотеке C ++, которые не имеют Throws: абзаца, но имеют спецификацию потенциально вызывающего исключения, могут вызывать исключения, определяемые реализацией.185 Реализации должны сообщать об ошибках, бросая исключения из или полученных из стандартных классов исключений ([bad.alloc], [support.exception],[std.exceptions]).

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

То есть все функции библиотеки C можно рассматривать так, как если бы они были отмеченыnoexcept. Это позволяет реализациям оптимизировать производительность на основе отсутствия исключений во время выполнения.

Функции qsort() и bsearch() ([alg.c.library]) удовлетворяют этому условию.

В частности, они могут сообщить об ошибке выделения хранилища, выбрасывая исключение типа bad_­allocили класса, производного от bad_­alloc.

20.5.5.13 Restrictions on storage of pointers [res.on.pointer.storage]

Объекты, созданные стандартной библиотекой, которые могут содержать значение указателя, предоставленное пользователем или целое число типа,std​::​intptr_­t должны хранить такие значения в файлеtraceable pointer location. [ Note: Другим библиотекам настоятельно рекомендуется делать то же самое, поскольку невыполнение этого может привести к случайному использованию указателей, которые не выводятся безопасно. Библиотеки, хранящие указатели вне адресного пространства пользователя, должны создавать впечатление, что они хранятся и извлекаются из отслеживаемого местоположения указателя. ]end note

20.5.5.14 Value of error codes [value.error.codes]

Некоторые функции стандартной библиотеки C ++ сообщают об ошибках через std​::​error_­code объект.category() Член этого объекта должен возвращатьstd​::​system_­category() для ошибок, происходящих из операционной системы, или ссылку на объект, определенный реализацией,error_­category для ошибок, возникающих в другом месте. Реализация должна определять возможные значенияvalue() для каждой из этих категорий ошибок. [ Example: Для операционных систем, основанных на POSIX, реализациям рекомендуется определятьstd​::​system_­category() значения как идентичныеerrno значениям POSIX , с дополнительными значениями, как определено в документации операционной системы. Реализациям для операционных систем, не основанных на POSIX, рекомендуется определять значения, идентичные значениям операционной системы. Для ошибок, которые происходят не из операционной системы, реализация может предоставить перечисления для связанных значений. ]end example

20.5.5.15 Moved-from state of library types [lib.types.movedfrom]

Объекты типов, определенных в стандартной библиотеке C ++, можно перемещать из ([class.copy]). Операции перемещения могут быть заданы явно или неявно. Если не указано иное, такие перемещенные объекты должны быть переведены в допустимое, но неуказанное состояние.