c++ - programacion - especificadores de formato en c

¿Cómo funcionará el sistema de tipo de especificador de excepción C++ 17?

Question

Al estudiar sobre "especificador de noexcept (y operador)", escribí un código simple. Y me sorprende que esta pieza de código:

void asdf() noexcept {}
int main()
{
auto f = asdf;
std::cout << std::boolalpha << noexcept(f()) << std::endl;
}

imprime false , la función par "asdf" no está especificada.

Así que mientras buscaba por qué ocurre este misterioso fenómeno, encontré el "sistema de tipo de especificador de excepción" de C ++ 17: P0012R1 .

Según esta propuesta (aceptada), desde C ++ 17; como noexcept es parte del tipo de función, ¿se imprimirá el código anterior?

Y una más, en una sola línea de this pregunta:

std::function<void() noexcept> f

La especificación de noexcept parece ignorada en C ++ 14 o 11. ¿ noexcept este código como se pretende en C ++ 17?

Answer 1

Según esta propuesta (aceptada), desde C ++ 17; como noexcept es parte del tipo de función, ¿se imprimirá el código anterior?

Sí.

El tipo de f se deducirá a void(*)() noexcept ya que la conversión de función a puntero aplicada a asdf conservará la propiedad noexcept . Una llamada a un puntero de función noexcept ciertamente no puede lanzar una excepción, a menos que una de sus subexpresiones lo haga.

Para la redacción exacta, vea [expr.unary.noexcept]/3 y [expect.spec]/13 . Tenga en cuenta que la nueva redacción en el último párrafo del borrador de C ++ 17 proviene de P0012R1, que está vinculado en el OP.

El resultado del operador noexcept es true si el conjunto de posibles excepciones de la expresión ([except.spec]) está vacío, y de lo contrario es false .

...

• Si e es una llamada de función ([expr.call]):
  • Si su expresión postfix es una expresión-id (posiblemente entre paréntesis) ([expr.prim.id]), acceso de miembros de la clase ([expr.ref]), u operación de puntero a miembro ([expr.mptr.oper]) ) cuya expresión-cast es una expresión-id , S es el conjunto de tipos en la especificación de excepción de la entidad seleccionada por la expresión-id contenida (después de la resolución de sobrecarga, si corresponde). ...

Por lo tanto, el conjunto de posibles excepciones de f() es el mismo que el conjunto de tipos en la especificación de excepción de f , que está vacío ya que f se declara noexcept .

Vayamos a la segunda pregunta:

La especificación de noexcept parece ignorada en C ++ 14 o 11. ¿ noexcept este código como se pretende en C ++ 17?

Su pregunta parece ser: ¿ std::function<void() noexcept> negará a mantener una función que pueda generar excepciones?

Yo diría que no está claro. En la redacción actual del estándar, std::function<void() noexcept> no está realmente definido, al igual que std::function<double(float) const> no está definido . Por supuesto, esto no era un problema en C ++ 14, ya que noexcept no se consideraba parte del tipo de una función.

¿Se descompondrá std::function<void() noexcept> simplemente en C ++ 17? Eso es incierto para mí. Echemos un vistazo a la redacción actual para adivinar cuál es el comportamiento "debería" ser.

El estándar requiere que el argumento al constructor de std::function<R(ArgTypes..)> sea ​​"Lvalue-Callable" para los tipos de argumento ArgTypes... y devuelva el tipo R , lo que means :

Un tipo que se puede llamar ([func.def]) F es Lvalue-Callable para los tipos de argumento ArgTypes y tipo de retorno R si la expresión INVOKE(declval<F&>(), declval<ArgTypes>()..., R) , considerada como un operando no evaluado (Cláusula [expr]), está bien formado ([func.require]).

Tal vez debería haber un requisito adicional de que si el tipo de función es noexcept , entonces noexcept(INVOKE(...)) debe ser verdadero. No obstante, esta redacción no está presente en el borrador actual.

En P0012R1, hay un comentario que:

Es un problema abierto cómo propagar "noexcept" a través de la std::function .

Supongo que quieren decir que no está claro cómo se podría implementar std::function si se impusiera este requisito adicional. Con suerte, alguien más puede proporcionar más detalles.