que - Los conceptos de C++ 0X se han ido. ¿Qué otras características deberían ir también?
para que sirve c++ (9)
Por supuesto, esto afectará a otras características y parece que volverá a abrir el estándar.
Apenas. Todavía quieren cerrar el estándar pronto, que es una de las razones principales para eliminar conceptos. Hacerlo "totalmente abierto" a los cambios no relacionados simplemente eliminaría todo lo que obtuvieron al deshacerse de los conceptos.
De todos modos ... De las restantes adiciones de C ++ 0x, no puedo pensar en otra cosa que quisiera eliminar. Estoy de acuerdo con su decisión con respecto a los conceptos sin embargo. El documento de Stroustrup realmente describió algunos problemas serios. La especificación actual para los conceptos admitiría que simplificaría los mensajes de error de la plantilla, pero lo haría al reducir dramáticamente la utilidad de la programación genérica, un precio que no estoy dispuesto a pagar.
Cuando leí ese artículo por primera vez, me asusté, porque asumí que era demasiado tarde en el proceso para realizar cambios serios en la especificación. Resulta que no fue así, y el comité estaba dispuesto a tomar medidas dramáticas.
Pero aparte de esto, creo que C ++ 0x está en buena forma. Las nuevas características restantes todas parecen valer la pena.
Por supuesto, hay muchas características existentes que me encantaría eliminar. Principalmente la especialización vector<bool> . Hay otros ejemplos populares de características que no funcionaron (la palabra clave de exportación, especificaciones de excepción), pero la especialización de vectores es la única de ellas que no se puede ignorar. Mientras no intentemos exportar plantillas, no importa que la palabra clave exista (y no sea implementada por compiladores), y podemos abstenernos de usar especificaciones de excepción, pero cada vez que necesitamos un vector de bools Estamos atrapados por la optimización prematura estúpida que se deslizó en el estándar actual.
Desafortunadamente, parece que se han dado por vencidos al eliminarlo. (La última vez que lo comprobé, ni siquiera estaba en desuso).
Por supuesto, también se puede abandonar un montón de viejos cruceros C, pero recientemente, descubrí que el único cambio que realmente me encantaría ver es ... abandonar la biblioteca de Iostreams. Deséchelo y cree una nueva biblioteca de E / S de estilo STL basada en programación genérica.
La actual biblioteca Iostreams de estilo OOP es fea, lenta, demasiado complicada e inflexible. Hay demasiado vudú involucrado en la definición de nuevas transmisiones, muy pocos tipos de transmisiones estándar involucrados, muy poca flexibilidad (el problema que me hizo darme cuenta de lo limitada que era la biblioteca, era que necesitaba extraer un flotante de una cadena. Fácil de hacer con cadenas de caracteres , pero si necesita hacerlo con frecuencia, no desea tener que copiar la cadena de entrada cada vez (como lo hace la cadena de cadenas). ¿Dónde está la secuencia que funciona en un rango de iterador existente? ¿O incluso en una matriz sin formato? )
Deseche IOstreams, desarrolle un reemplazo moderno y C ++ se mejorará enormemente.
Y tal vez hacer algo acerca de la clase de cadena también. Funciona como si estuviera bien, pero en realidad, ¿qué pasa con la gran cantidad de funciones miembro? La mayoría de ellos funcionaría mejor, y sería más general, como funciones gratuitas. Demasiada parte de la biblioteca estándar se basa específicamente en la clase de cadena, cuando en principio podría funcionar con cualquier contenedor, o incluso con un iterador ( std::getline , te estoy mirando)
Como habrá escuchado, la última reunión del comité de estándares de C ++ votó para eliminar los conceptos del próximo estándar de C ++. Por supuesto, esto afectará a otras características y parece que volverá a abrir el estándar. Si ese es el caso, ¿qué otras características crees que deberían eliminarse (o agregarse) y por qué?
Campo de golf:
Eliminación de conceptos - Danny Kalev (sobre la decisión de eliminar conceptos)
Simplificación del uso de Concepts - Bjarne Stroustrup (sobre los problemas con los conceptos tal como se ven ahora)
El polo largo se alarga : Martin Tasker (sobre el impacto en el programa para C ++ 0x si los conceptos tienen que ser corregidos)
La decisión sobre "Eliminar conceptos" de C ++ 0x - Stroustrup sobre el problema del Dr. Dobbs
Informe de viaje: conceptos de salida, borrador final de ISO C ++ en ~ 18 meses - Herb Sutter
Los conceptos se votan en la isla C ++ 0x - Jeremy Siek defiende la especificación actual de Conceptos
¿Qué pasó en Frankfurt? - Doug Gregor en C ++ Next (sobre la historia y eliminación de Conceptos).
¡Quita las páginas de los mensajes de error en el código de la plantilla!
Los conceptos de IIRC deberían resolver un gran problema del codificador de C ++: mensajes de error legibles por humanos para el STL. Es una mala noticia que este problema no se aborde.
Hay dos cosas que creo que deberían agregarse a C ++ 0x, pensé en estas dos cosas y luego descubrí que otras personas las han sugerido antes, pero no parece que vayan a suceder.
1. Por defecto mover constructores y mover operadores de asignación
Escribir un constructor de movimientos es una actividad manual y propensa a errores. Si se agrega un miembro, debe agregarse al constructor de movimientos y los operadores de asignación y std::move deben usarse religiosamente. Por eso creo que estas funciones deberían ser defaultables .
movable(movable&&) = default;
movable& operator=(movable&&) = default;
Editar (2009-10-01): Parece que esto va a suceder después de todo.
2. Anular Deducción de Tipo para Plantillas de Expresión
Las plantillas de expresión a menudo definen tipos que no deben usarse directamente; un ejemplo de ello es el valor de retorno del std::vector<bool> operator[](size_type n) , si se usa auto o decltype en este tipo de objeto, el comportamiento inesperado puede sobrevenir. Por lo tanto, un tipo debe poder decir qué tipo debe deducirse (o evitar la deducción utilizando = delete sintaxis de = delete ).
Ejemplo para la adición de vectores.
// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
V1& lhs_;
V2& rhs_;
public:
T operator[](size_t n) const
{ return lhs_[n] + rhs_[n]; }
// If used by auto or decltype perform eager creation of vector
std::vector<T> operator auto() const
{
if (lhs_.size() != rhs_.size())
throw std::exception("Vectors aren''t same size");
std::vector<T> vec;
vec.reserve(lhs_.size());
for (int i = 0; i < lhs_.size(); ++i)
vec.push_back(lhs_[i] + rhs_[i]);
return vec;
}
Haz lo que quieras con conceptos, pero por el amor de Dios, mantenemos los hilos y los elementos atómicos, los necesitamos absolutamente. Tal vez agregue grupos de hilos y soporte para hilos cooperativos también conocidos como fibers . En mi opinión, estos son mucho más importantes que los conceptos, porque todos usan / pronto usarán hilos.
La función sin nombre / función lambda me pone nervioso. Los objetos de función son perfectamente buenos y explícitos, por lo tanto, más fáciles de leer y encontrar.
Por otro lado, me gustaban los conceptos, aunque ciertamente no los habría usado todos los días.
Me gustaría eliminar =delete .
Ya existe un idioma común y aceptado para lograr el mismo efecto (declarar la función en cuestión como privada). Creo que esta característica solo generará una gran cantidad de ''I use =delete para eliminar una función de clase base de mi clase derivada, pero aún se puede llamar usando preguntas de puntero de clase base''.
Por no hablar de confundir a las personas entre los (ahora) dos significados de la palabra clave delete .
Ninguno, creo que el resto del borrador fue excelente: un gran número de piezas muy pequeñas que pueden implementarse correctamente de forma independiente, lo que permite a los proveedores evolucionar hacia un soporte completo y permitir a los usuarios adoptar un enfoque de "lista de compras".
Una situación bastante diferente con los contratos, ya que eran como un nuevo sistema de tipo paralelo y muy probablemente habrían llevado a diferentes compiladores a terminar con sus propios problemas de compatibilidad con versiones anteriores, muy similares a los CSS en los navegadores web.
Para mí, el problema no es qué otras características deben eliminarse, sino cuán complejas serán otras características después de que se hayan eliminado los conceptos. Eso y cuánto tiempo tomará para que el resto de las características se reformulen sin conceptos.
Muchas características asumieron que los conceptos serían aceptados en el lenguaje y la redacción se expresa en términos de conceptos. (Me pregunto si alguna característica propuesta depende de los conceptos).
También me pregunto cómo evolucionarán otras bibliotecas (piense boost :: type_traits) para tomar el nicho que dejan los conceptos. Parte de los conceptos proporcionados pueden implementarse (aunque de una manera más complicada) en términos de rasgos aplicados a los argumentos de tipo.
Para mí, lo más importante que agregaron los conceptos al lenguaje fue una formulación expresiva de errores de compilación, que en la actualidad es uno de los lugares donde más se critica a C ++.
Conceptos de RIP.
Personalmente, quiero que C ++ finalmente se aparte de C. No más preprocesador, no más archivos de encabezado. Básicamente quiero D, pero sin todas las cosas que D tachea, usando el STL.