Por ejemplo, es bastante común tener dos formas separadas de acceder a elementos de una matriz privada, sobrecargar el operador de suscripción de la matriz o definirat:

T& operator[](size_t i) { return v[i]; }
T const& operator[](size_t i) const { return v[i]; }

T& at(size_t i)
{
     if (i >= length)
         throw out_of_range("You shall not pass!");

     return v[i];
}

T const& at(size_t i) const
{
     if (i >= length)
         throw out_of_range("You shall not pass!");

     return v[i];
}

losat la versión puede lanzar una excepción, pero el operador de suscripción de matriz no puede.

Mi pregunta es, aunque eloperator[] no arroja una excepción, ¿se puede marcar comonoexcept incluso sabiendo que puede generar una señal SIGSEGV, ¿o es solo una mala práctica?

Quiero señalar una señal (como SIGSEGV) no es una excepción. Siendo literal interpretando elnoexcept es decir, unnoexcept La función dice que no arrojará excepciones. No dice nada sobre nada más (incluidas las señales).

Pero unnoexcept La función tiene más significado que eso, al menos para los clientes de mi código.noexcept también dice implícitamente que la función es segura y que finalizará su ejecución sin errores computacionales.

Entonces, ¿es inapropiado marcarnoexcept una función que no es segura?