Расширение Библиотеки Стандарта C++ наследованием?

Чтобы ответить на вопрос 2):

Я считаю, что да, они будут связаны описанием интерфейса стандарта ISO. Например, стандарт позволяет переопределить оператор new и оператор delete глобально. Однако стандарт гарантирует, что operator delete не является операцией с нулевыми указателями.

Несоблюдение этого, безусловно, неопределенное поведение (по крайней мере, для Скотта Майерса). Я думаю, мы можем сказать, что то же самое верно по аналогии для других областей стандартной библиотеки.

Некоторые вещи в функциональном , например больше <> , меньше <> и mem_fun_t являются производными от unary_operator <> и binary_operator <> . Но, IIRC, это дает вам только некоторые определения типов.

Экономное правило: «Любой класс может быть использован в качестве базового класса; ответственность за его безопасное использование в отсутствие виртуальных методов, включая виртуальный деструктор, полностью принадлежит производному автору. " Добавление члена, не являющегося POD, в дочерний элемент std :: exception - такая же ошибка пользователя, как и в производном классе std :: vector. Идея о том, что контейнеры не «предназначены» для использования в качестве базовых классов, является инженерным примером того, что профессора литературы называют ошибкой авторского намерения.

Преобладает принцип IS-A. Не производите D из B, если D не может заменить B во всех отношениях в публичном интерфейсе B, включая операцию удаления указателя B. Если B имеет виртуальные методы, это ограничение менее обременительно; но если у B есть только невиртуальные методы, все еще возможно и законно специализироваться на наследовании.

C ++ мультипарадигматичен. Библиотека шаблонов использует наследование, даже наследование от классов без виртуальных деструкторов, и таким образом демонстрирует на примере, что такие конструкции безопасны и полезны; предназначались ли они - вопрос психологический.

по вопросу 2), в соответствии со стандартом C ++, производный класс исключения должен указывать спецификацию no-throw, т.е. throw () , а также возвращать ненулевое значение . Во многих случаях это означает, что производный класс исключений не должен использовать std :: string, так как std :: string сам может вызывать в зависимости от реализации.

Думаю, что на второй вопрос ответ положительный. Стандарт говорит, что член what std :: exception должен возвращать значение, отличное от NULL. Не имеет значения, есть ли у меня значение стека, ссылки или указателя на std :: exception. Возврат what () ограничен стандартом.

Конечно, можно вернуть NULL. Но я считаю, что такой класс не соответствует стандартам.

Я знаю этот вопрос старый, но я хотел бы добавить сюда свой комментарий.

Уже несколько лет я использую класс CfgValue , который наследуется от std :: string, хотя документация (или какая-то книга или какой-то стандартный документ, у меня сейчас нет исходного кода) говорит, что пользователи не должны наследовать от std :: string. И этот класс содержит комментарий «TODO: удалить наследование из std :: string» с годами.

Класс CfgValue просто добавляет некоторые конструкторы, сеттеры и геттеры для быстрого преобразования между строками и числовыми и логическими значениями, а также преобразование из кодировки utf8 (хранится в std :: string) в кодировку ucs2 (хранится в std :: wstring) и т. Д. .

Я знаю, есть много разных способов сделать это, но это просто чрезвычайно удобно для пользователя, и он отлично работает (что означает, что не ломается. любые концепции stdlib, обработка исключений и т. д.):

class CfgValue : public std::string {
public:
    ...
    CfgValue( const int i ) : std::string() { SetInteger(i); }
    ...
    void SetInteger( int i );
    ...
    int GetInteger() const;
    ...
    operator std::wstring() { return utf8_to_ucs16(*this); }
    operator std::wstring() const { return utf8_to_ucs16(*this); }
    ...
};

Что касается вашей части B, от 17.3.1.2 «Требования», пункт 1:

Библиотека может быть расширена программой C ++. Каждое предложение, как применимо, описывает требования, которые такие расширения должны соответствовать. Такие расширения, как правило, являются одним из следующих:

• шаблон аргументов
• полученные классы
• контейнеры, итераторы и / или алгоритмы, соответствующие конвенции по интерфейсу

, в то время как 17.3 является информативным вместо того, чтобы привязать, намерение Комитета Производное поведение класса ясно.

Для других очень похожих точек расширения есть четкие требования:

• 17.1.15 «Обязательное поведение» охватывает замену (оператор новых и т. Д.) И функции обработчика (завершающие обработчики и т. Д.) И бросают все Соответствующее поведение в UB-Land.
• 17.4.3.6/1. Соответствуйте их требованиям, стандартные места нет требований к реализации ».

В последнее время не ясно для меня, что список в скобках является исчерпывающим, но учитывая, насколько конкретно каждый упомянутый случай рассматривается в следующем абзаце, это Будьте растягиваться, чтобы сказать, текущий текст был предназначен для покрытия полученных классов. Кроме того, что 17.4.3.6/1 текст не изменился в проекте 2008 года (где он в 17,6,4,8), и я не вижу проблем , касающихся виртуальных методов либо полученных классов.