🍿 🆎 🚅 Primera impresión de conceptos. 🐨 📸 📦

Decidí tratar con la nueva característica C ++ 20: conceptos.

Los conceptos (o conceptos , como escribe el Wiki de habla rusa) es una característica muy interesante y útil que ha faltado durante mucho tiempo.

Esencialmente, está escribiendo argumentos de plantilla.

El principal problema de las plantillas antes de C ++ 20 es que podría sustituir cualquier cosa en ellas, incluso algo para lo que no fueron diseñadas. Es decir, el sistema de plantillas estaba completamente sin tipo. Como resultado, se produjeron mensajes de error increíblemente largos y completamente ilegibles al pasar el parámetro incorrecto a la plantilla. Intentaron luchar contra esto con la ayuda de diferentes hacks de idiomas, que ni siquiera quiero mencionar (aunque tuve que lidiar).

Los conceptos están diseñados para corregir este malentendido. Añaden un sistema de mecanografía a las plantillas, y es muy poderoso. Y ahora, entendiendo las características de este sistema, comencé a estudiar los materiales disponibles en Internet.

Francamente, estoy un poco sorprendido :) C ++ es un lenguaje ya complicado, pero al menos hay una excusa: sucedió. La metaprogramación en plantillas se descubrió, no se estableció, al diseñar un lenguaje. Y luego, al desarrollar las próximas versiones del lenguaje, se vieron obligados a adaptarse a este "descubrimiento", ya que se había escrito mucho código en el mundo. Los conceptos son una oportunidad fundamentalmente nueva. Y, me parece, ya hay algo de opacidad en su implementación. ¿Quizás esto es una consecuencia de la necesidad de tener en cuenta la gran cantidad de capacidades heredadas? Tratemos de resolverlo ...

Información general

Un concepto es una nueva entidad de lenguaje basada en la sintaxis de la plantilla. Un concepto tiene un nombre, parámetros y un cuerpo, un predicado que devuelve un valor lógico constante (es decir, calculado en la etapa de compilación) dependiendo de los parámetros del concepto. Me gusta esto:

template<int I> 
concept Even = I % 2 == 0;  

template<typename T>
concept FourByte = sizeof(T)==4;

Técnicamente, los conceptos son muy similares a las expresiones constexpr de plantilla como bool:

template<int I>
constexpr bool EvenX = I % 2 == 0; 

template<typename T>
constexpr bool FourByteX = sizeof(T)==4;

Incluso puede usar conceptos en expresiones comunes:

bool b1 = Even<2>;

Utilizando

La idea principal de los conceptos es que se pueden usar en lugar del nombre de tipo o las palabras clave de clase en las plantillas. Al igual que los metatipos ("tipos para tipos"). Por lo tanto, la escritura estática se introduce en las plantillas.

template<FourByte T>
void foo(T const & t) {}

Ahora, si usamos int como parámetro de plantilla, entonces el código en la gran mayoría de los casos se compilará; y si es doble, se emitirá un mensaje de error breve y comprensible. Escritura simple y clara de plantillas, hasta ahora todo está bien.

requiere

Esta es una nueva palabra clave "contextual" C ++ 20 con un doble propósito: requiere cláusula y requiere expresión. Como se mostrará más adelante, este extraño ahorro de palabras clave genera cierta confusión.

requiere expresión

Primero, considerar requiere expresión. La idea es bastante buena: esta palabra tiene un bloque entre llaves, cuyo código se evalúa para su compilación. Es cierto que el código no debe estar escrito en C ++, sino en un lenguaje especial, cercano a C ++, pero que tiene sus propias características (esta es la primera rareza, era muy posible hacer solo código C ++).

Si el código es correcto, la expresión requiere devuelve verdadero, de lo contrario es falso. El código en sí, por supuesto, nunca entra en la generación de código, al igual que las expresiones en sizeof o decltype.

Desafortunadamente, la palabra es contextual y funciona solo dentro de las plantillas, es decir, fuera de la plantilla, esto no compila:

bool b = requires { 3.14 >> 1; };

Y en la plantilla, por favor:

template<typename T>
constexpr bool Shiftable = requires(T i) { i>>1; };

Y funcionará:

bool b1 = Shiftable<int>; // true
bool b2 = Shiftable<double>; // false

El uso principal de requiere expresión es la creación de conceptos. Por ejemplo, así es como puede verificar la presencia de campos y métodos en un tipo. Un caso muy popular.

template <typename T>
concept Machine = 
  requires(T m) {  //   `m` ,   Machine
	m.start();     //    `m.start()` 
	m.stop();      //   `m.stop()`
};

Por cierto, todas las variables que pueden ser necesarias en el código probado (no solo los parámetros de la plantilla) deben declararse entre paréntesis requiere expresión. Por alguna razón, declarar una variable simplemente no es posible.

La verificación de tipo en el interior requiere

Aquí es donde comienzan las diferencias entre el código requerido y el estándar C ++. Para verificar los tipos devueltos, se utiliza una sintaxis especial: el objeto se toma entre llaves, se coloca una flecha y después se escribe un concepto que el tipo debe satisfacer. Además, el uso de tipos directamente no está permitido.

Compruebe que el retorno de la función se puede convertir a int:

requires(T v, int i) {
  { v.f(i) } -> std::convertible_to<int>;
}

Verifique que la función de retorno sea exactamente int:

requires(T v, int i) {
  { v.f(i) } -> std::same_as<int>; 
}

(std :: same_as y std :: convertible_to son conceptos de la biblioteca estándar).

Si no encierra una expresión cuyo tipo está marcado entre llaves, el compilador no entiende lo que quiere de él e interpreta toda la cadena como una sola expresión que debe verificarse para la compilación.

requiere adentro requiere

La palabra clave require tiene un significado especial en el interior requiere expresiones. Las expresiones obligatorias anidadas (ya sin llaves) se comprueban no para la compilación, sino para la igualdad de verdadero o falso. Si dicha expresión resulta ser falsa, entonces la expresión que lo encierra resulta ser falsa inmediatamente (y se interrumpe el análisis posterior de la compilación). Forma general:

requires { 
  expression;         // expression is valid
  requires predicate; // predicate is true
};

Como predicado, por ejemplo, se pueden utilizar conceptos o rasgos de tipo previamente definidos. Ejemplo:

requires(Iter it) {
  //     (   Iter   *  ++)
  *it++;
 
  //    -  
  requires std::convertible_to<decltype(*it++), typename Iter::value_type>;
 
  //    -  
  requires std::is_convertible_v<decltype(*it++), typename Iter::value_type>;
}

Al mismo tiempo, se permiten expresiones obligatorias anidadas con código entre llaves, que se verifica para verificar su validez. Sin embargo, si simplemente escribe una expresión requerida dentro de otra, entonces se verificará la validez de la expresión anidada (todo en su conjunto, incluida la palabra clave requerida anidada):

requires (T v) { 
  requires (typename T::value_type x) { ++x; }; //     , 
												//     !
};

Por lo tanto, surgió una forma extraña con doble:

requires (T v) { 
  requires requires (typename T::value_type x) { ++x; }; //       "++x"
};

Aquí hay una secuencia de escape tan divertida de "requiere".

Por cierto, otra combinación de dos requisitos es esta cláusula de tiempo (ver más abajo) y expresión:

template <typename T>
  requires requires(T x, T y) { bool(x < y); }
bool equivalent(T const& x, T const& y)
{
  return !(x < y) && !(y < x);
};

requiere cláusula

Ahora pasemos a otro uso de la palabra requiere: declarar restricciones de un tipo de plantilla. Esta es una alternativa al uso de nombres de concepto en lugar de typename. En el siguiente ejemplo, los tres métodos son equivalentes:

//  require
template<typename Cont>
	requires Sortable<Cont>
void sort(Cont& container);

//   require (  )
template<typename Cont>
void sort(Cont& container) requires Sortable<Cont>;

//    typename
template<Sortable Cont>
void sort(Cont& container)

La declaración requerida puede usar varios predicados combinados por operadores lógicos.

template <typename T>
  requires is_standard_layout_v<T> && is_trivial_v<T>
void fun(T v); 
 
int main()
{
  std::string s;
 
  fun(1);  // ok
  fun(s);  // compiler error
}

Sin embargo, solo invierta una de las condiciones, ya que se produce un error de compilación:

template <typename T>
  requires is_standard_layout_v<T> && !is_trivial_v<T>
void fun(T v);

Aquí hay un ejemplo que tampoco compilará

template <typename T>
  requires !is_trivial_v<T>
void fun(T v);

La razón de esto son las ambigüedades que surgen al analizar algunas expresiones. Por ejemplo, en dicha plantilla:

template <typename T> 
  requires (bool)&T::operator short unsigned int foo();

no está claro a qué atribuir sin firmar: el operador o el prototipo de la función foo (). Por lo tanto, los desarrolladores decidieron que sin paréntesis, ya que los argumentos requieren una cláusula, solo se puede usar un conjunto muy limitado de entidades: literales verdaderos o falsos, nombres de campo del tipo bool del valor del formulario, valor, T :: valor, ns :: trait :: value, Nombres de concepto del tipo Concepto y requiere expresiones. Todo lo demás debe estar entre paréntesis:

template <typename T>
  requires (!is_trivial_v<T>)
void fun(T v);

Ahora sobre las características del predicado en la cláusula require

Considere otro ejemplo.

template <typename T>
  requires is_trivial_v<typename T::value_type> 
void fun(T v);

En este ejemplo, require utiliza un rasgo que depende del tipo value_type anidado. No se sabe de antemano si un tipo arbitrario tiene un tipo anidado que se puede pasar a la plantilla. Si pasa, por ejemplo, un tipo int simple a dicha plantilla, habrá un error de compilación, sin embargo, si tenemos dos especializaciones de la plantilla, entonces no habrá error; solo se elegirá otra especialización.

template <typename T>
  requires is_trivial_v<typename T::value_type> 
void fun(T v) { std::cout << "1"; } 
 
template <typename T>
void fun(T v) { std::cout << "2"; } 
 
int main()
{
  fun(1);  // displays: "2"
}

Por lo tanto, la especialización se descarta no solo cuando el predicado de la cláusula require devuelve falso, sino también cuando resulta ser incorrecto.

Los paréntesis alrededor del predicado son un recordatorio importante de que en la cláusula require el inverso del predicado no es lo opuesto al predicado en sí. Entonces,

requires is_trivial_v<typename T::value_type>

significa que el rasgo es correcto y devuelve verdadero. Donde

!is_trivial_v<typename T::value_type>

significaría "el rasgo es correcto y devuelve falso" La
inversión lógica real del primer predicado NO es ("el rasgo es correcto y devuelve verdadero") == "el rasgo es INCORRECTO o devuelve falso" - esto se logra de una manera un poco más compleja - a través de una definición explícita del concepto:

template <typename T>
concept value_type_valid_and_trivial 
  = is_trivial_v<typename T::value_type>; 
 
template <typename T>
  requires (!value_type_valid_and_trivial<T>)
void fun(T v);

Conjunción y disyunción

Los operadores lógicos de conjunción y disyunción se ven como de costumbre, pero en realidad funcionan un poco diferente que en C ++ normal.

Considere dos fragmentos de código muy similares.

El primero es un predicado sin paréntesis:

template <typename T, typename U>
  requires std::is_trivial_v<typename T::value_type>
		|| std::is_trivial_v<typename U::value_type>
void fun(T v, U u);

El segundo es con paréntesis:

template <typename T, typename U>
  requires (std::is_trivial_v<typename T::value_type>
		 || std::is_trivial_v<typename U::value_type>)
void fun(T v, U u);

La diferencia está solo entre paréntesis. Pero debido a esto, en la segunda plantilla, no hay dos restricciones unidas por una "cláusula de exigencia", sino una unida por un OR lógico habitual.

Esta diferencia es la siguiente. Considera el código

std::optional<int> oi {};
int i {};
fun(i, oi);

Aquí la plantilla se instancia por los tipos int y std :: opcional.

En el primer caso, el tipo int :: value_type no es válido y, por lo tanto, la primera limitación no se cumple.

Pero el tipo opcional :: value_type es válido, el segundo rasgo devuelve verdadero, y dado que hay un operador OR entre las restricciones, todo el predicado se satisface como un todo.

En el segundo caso, esta es una expresión única que contiene un tipo no válido, por lo que no es válido en general y el predicado no está satisfecho. Entonces, los corchetes simples cambian imperceptiblemente el significado de lo que está sucediendo.

En conclusión

Por supuesto, no todas las características de los conceptos se muestran aquí. Simplemente no fui más allá. Pero como primera impresión, una idea muy interesante y una implementación confusa algo extraña. Y una sintaxis divertida con repeticiones requiere, lo que realmente confunde. ¿Hay realmente tan pocas palabras en inglés que tuvo que usar una palabra para propósitos completamente diferentes?

La idea con el código compilado es definitivamente buena. Incluso es algo similar a "cuasi-citando" en macros de sintaxis. ¿Pero valió la pena mezclar la sintaxis especial para verificar los tipos de retorno? En mi humilde opinión, para esto simplemente sería necesario hacer una palabra clave por separado.

Mezcla implícita de los conceptos "verdadero / falso" y "compila / no compila" en un montón, y como resultado, las bromas entre paréntesis también están mal. Estos son conceptos diferentes, y deben existir estrictamente en diferentes contextos (aunque entiendo de dónde vino, de la regla SFINAE, donde el código no compilado excluyó silenciosamente la especialización de la consideración). Pero si el objetivo de los conceptos es hacer que el código sea lo más explícito posible, ¿valió la pena arrastrar todas estas cosas implícitas a nuevas características?

El artículo está escrito principalmente sobre la base de
akrzemi1.wordpress.com/2020/01/29/requires-expression
akrzemi1.wordpress.com/2020/03/26/requires-clause
(hay muchos más ejemplos y características interesantes)
con mis adiciones de otras fuentes,
todos los ejemplos se pueden consultarwandbox.org

Primera impresión de conceptos.