ejemplos - manual completo de c++ pdf
¿Por qué los enlaces estructurados de C++ 17 no usan{}? (5)
Encontré la propuesta original para enlaces estructurados * C ++ here . Propone una forma de vincular fácilmente múltiples valores de retorno, es decir:
auto {a, b} = minmax(data);
Pero ahora veo que todos apuntan a la sintaxis de propuesta C ++ 17 / C ++ 1z de
auto [a, b] = minmax(data);
Ahora que aprendí "las listas están escritas {como, esto}", ¿viene una nueva sintaxis de lista? ¿Por qué? ¿Cuál es el problema con las llaves aquí?
@SebastianWahl solo comentó con un enlace. Resumiré rápidamente el contenido detrás del enlace.
La respuesta de Chandler Carruth a esta pregunta: youtu.be/430o2HMODj4?t=15m50s
auto [a,b,c] = f();
está bien con
auto
.
Pero también puedes hacer esto:
tuple<int,float,string> [a,b,c] = f();
Entonces, cuando usas
{...}
esto se convertirá
tuple<int,float,string> {a,b,c} = f(); //<<< not C++17
lo cual es
malo
, porque la pieza
tuple<int,float,string> {a,b,c}
también tiene un significado en C ++ y, por lo tanto, sería una ambigüedad difícil, difícil de resolver.
El cambio de {} a [] ocurrió después de Jacksonville y se realizó en respuesta a los comentarios de esa reunión. Esto se detalla en p0144r2 , que establece: "porque es más visualmente distinto de la sintaxis existente para declarar múltiples variables del mismo tipo".
Parece que los comentarios de NB que solicitan un cambio en el uso original de {} no aumentaron el consenso en las reuniones de noviembre de 2016, dejando intacto el uso de []. Al menos hasta la reunión de primavera.
Esto todavía está en debate. Es difícil estar seguro de qué sintaxis será menos confusa dado cuántos usos hay para [] y {} ya.
También existe el riesgo de que "menos confuso" y "más fácil de analizar" estén en conflicto.
Los organismos nacionales de España y EE. UU. Han propuesto volver a la sintaxis
{}
porque (
P0488R0
):
La propuesta de "enlaces estructurados" originalmente usaba llaves "{}" para delimitar identificadores de enlace. Esos delimitadores se cambiaron a corchetes "[]" bajo la afirmación de que no introdujeron ningún problema sintáctico. Sin embargo, resultaron introducir ambigüedad sintáctica con atributos y lambdas. A la luz de varias soluciones sugeridas, parece que la sintaxis original es más adecuada.
Por lo tanto, aún queda la posibilidad de terminar teniendo la sintaxis original para C ++ 17 (que creo firmemente que la mayoría de los usuarios prefiere).
Actualización de este informe de viaje :
La propuesta original para las declaraciones de descomposición usaba la sintaxis
auto {a, b, c};eso se cambió en la última reunión aauto [a, b, c]. Este cambio fue bastante controvertido, y varios comentarios solicitaron volver a cambiarlo a{}(mientras que otros alentaron a mantener el[]). Hay argumentos técnicos en ambos lados (la sintaxis[]puede entrar en conflicto con los atributos una vez que comience a permitir descomposiciones anidadas; la sintaxis{}puede entrar en conflicto con la inicialización uniforme si agrega Conceptos a la mezcla y permite usar un concepto-nombre en lugar deauto) , así que al final es en gran medida una cuestión de gustos. Los implementadores de clang informaron que probaron ambos, y encontraron que las ambigüedades eran más fáciles de solucionar con[]. Al final, no hubo consenso para un cambio, por lo que el status quo ([]sintaxis) permanece.
Una cosa que se puede decir de la sintaxis de corchetes es que se parece mucho a las cláusulas de captura lambda, donde, de manera similar, no se especifica el tipo de variable, ya que implícito auto . Es decir
auto func = [a, b] {}
auto func = [a=1, b=2.0] {}
Obviamente no es exactamente lo mismo, pero cuando lo piensa como "sintaxis para la captura automática al dar sentido al contexto", puede funcionar:
auto [a, b] = std::make_pair(1, 2.0);