Preguntas hipotéticas sobre conceptos de C ++ 0x

Question

( Preámbulo: soy un seguidor tardío del juego C ++ 0x y la reciente controversia sobre la eliminación de conceptos del estándar C ++ 0x me ha motivado a aprender más sobre ellos. Si bien entiendo que todas mis preguntas son completamente hipotéticas, en la medida en que los conceptos no serán un código C ++ válido en el futuro, si es que lo hacen, todavía estoy interesado en aprender más sobre los conceptos, especialmente teniendo en cuenta cómo ayudaría entiendo más completamente los méritos detrás de la reciente decisión y la controversia que ha seguido)

Después de haber leído algunos materiales introductorios sobre conceptos que C ++ 0x (hasta hace poco) propuso, tengo problemas para comprender algunos problemas sintácticos. Sin más preámbulos, aquí están mis preguntas:

1) ¿Un tipo que admita un concepto derivado particular (ya sea implícitamente, a través de la palabra clave automática o explícitamente a través de concept_maps) también debería admitir el concepto base de forma independiente? En otras palabras, ¿el acto de derivar un concepto de otro (por ejemplo, concept B<typename T> : A<T>) incluye implícitamente una declaración de requerimiento 'invisible' (dentro de B, requires A<T>;)? La confusión surge de la página de Wikipedia sobre conceptos que dice:

  

Al igual que en la herencia de clases, los tipos que   cumplir los requisitos de la derivada   concepto también cumple los requisitos de   el concepto base.

Eso parece decir que un tipo solo necesita satisfacer los requisitos del concepto derivado y no necesariamente los requisitos del concepto base, lo que no tiene sentido para mí. Entiendo que Wikipedia está lejos de ser una fuente definitiva; ¿Es la descripción anterior solo una mala elección de palabras?

2) ¿Puede un concepto que enumera nombres de tipo ser 'auto'? Si es así, ¿cómo mapearía el compilador estos nombres de tipo automáticamente? Si no, ¿hay otras ocasiones en las que no sería válido usar 'auto' en un concepto?

Para aclarar, considere el siguiente código hipotético:

template<typename Type>
class Dummy {};

class Dummy2 { public: typedef int Type; };

auto concept SomeType<typename T>
{
     typename Type;
}

template<typename T> requires SomeType<T>
void function(T t)
{}

int main()
{
    function(Dummy<int>()); //would this match SomeType?
    function(Dummy2()); //how about this?
    return 0;
}

¿Alguna de esas clases coincidiría con SomeType? ¿O es necesario un concept_map para los conceptos que involucran nombres de tipos?

3) Finalmente, me cuesta entender qué axiomas se les permitiría definir. Por ejemplo, ¿podría un concepto definir un axioma que sea lógicamente inconsistente, como

concept SomeConcept<typename T>
{
    T operator*(T&, int);

    axiom Inconsistency(T a)
    {
         a * 1 == a * 2;
    }
} 

¿Qué haría eso? ¿Es eso incluso válido?

Aprecio que este es un conjunto muy largo de preguntas y por eso les agradezco de antemano.

Answer 1

He usado el borrador más reciente de C ++ 0x, N2914 (que todavía tiene una redacción de conceptos) como referencia para la siguiente respuesta.

1) Los conceptos son como interfaces en eso. Si su tipo admite un concepto, también debería admitir todos & Quot; base & Quot; conceptos. La declaración de Wikipedia que cita tiene sentido desde el punto de vista del cliente de un tipo: si sabe que T satisface el concepto Derived<T>, entonces también sabe que satisface el concepto Base<T>. Desde la perspectiva del autor tipográfico, esto naturalmente significa que ambos deben implementarse. Ver 14.10.3 / 2.

2) Sí, un concepto con typename miembros puede ser auto. Dichos miembros pueden deducirse automáticamente si se usan en definiciones de miembros de función en el mismo concepto. Por ejemplo, value_type para iterador puede deducirse como un tipo de retorno de su operator*. Sin embargo, si un miembro de tipo no se usa en ninguna parte, no se deducirá y, por lo tanto, no se definirá implícitamente. En su ejemplo, no hay forma de deducir SomeType<T>::Type para Dummy o Dummy1, ya que Type no es utilizado por otros miembros del concepto, por lo que ninguna clase se asignará al concepto (y, de hecho, , ninguna clase podría mapearse automáticamente). Ver 14.10.1.2/11 y 14.10.2.2/4.

3) Los axiomas eran un punto débil de la especificación, y se actualizaban constantemente para tener algo (más) de sentido. Justo antes de extraer los conceptos del borrador, había un papel que cambió bastante: léalo y vea si tiene más sentido para usted, o si todavía tiene preguntas al respecto.

Para su ejemplo específico (teniendo en cuenta la diferencia sintáctica), significaría que se permitiría al compilador considerar que la expresión (a*1) sea igual a (a*2), a los efectos de " as-if " regla del lenguaje (es decir, el compilador permitió hacer las optimizaciones que quisiera, siempre que el resultado se comporte como si no hubiera ninguna). Sin embargo, no se requiere de ninguna manera que el compilador valide la exactitud de los axiomas (¡por eso se les llama axiomas!), Solo los toma por lo que son.