Каковы побочные эффекты маркировки производной реализации, за исключением того, что интерфейс не

Question

У нас есть класс, который реализует IUnknown (или любой интерфейс, которым мы не владеем).Мы начали помечать большинство / все наши методы без исключения для любой потенциальной оптимизации, так как мы все равно не генерируем никаких исключений;хотя некоторые библиотеки от нас зависят.Был задан вопрос о том, должен ли QueryInterface / AddRef / Release быть помечен как noexcept, поскольку интерфейс отсутствует.

Есть ли какие-либо побочные эффекты или ошибки, когда только некоторые из производных классов помечены как noexcept?

Answer 1

Я бы всегда рекомендовал добавлять noexcept, где только можно.

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

Answer 2

Вы должны быть осторожны с noexcept в целом.Если компилятор не может доказать, что функция действительно не будет генерировать никаких исключений, он должен вставить динамический обработчик для завершения вашей программы в случае исключения.Таким образом, это не обязательно приведет к оптимизации, на которую вы надеетесь.В любом случае добавление его к AddRef, Release и QueryInterface должно быть безопасным.

Редактировать

Например, рассмотрим следующий код:

extern int Foo();

int Bar() noexcept
{
    return Foo();
}

Это то, что Clang 7.0 генерирует на O3:

Bar():                                # @Bar()
    push    rax
    call    Foo()
    pop     rcx
    ret
    mov     rdi, rax
    call    __clang_call_terminate
__clang_call_terminate:                 # @__clang_call_terminate
    push    rax
    call    __cxa_begin_catch
    call    std::terminate()

Если вы удалите noexcept, вы получите это вместо:

Bar():                                # @Bar()
    jmp     Foo()                 # TAILCALL

InВ этом примере основной эффект состоит в том, чтобы немного увеличить изображение, но обратите внимание, что вызов Foo также стал немного менее эффективным.