Estilos de sintaxis de conversión de C++

StackOverflow https://stackoverflow.com/questions/32168

  •  09-06-2019
  •  | 
  •  

Pregunta

Una pregunta relacionada con Elenco regular vs.static_cast vs.transmisión_dinámica:

¿Qué estilo de sintaxis de transmisión prefieres en C++?

  • Sintaxis de conversión de estilo C: (int)foo
  • Sintaxis de conversión estilo C++: static_cast<int>(foo)
  • sintaxis del constructor: int(foo)

Puede que no se traduzcan exactamente en las mismas instrucciones (¿verdad?), pero su efecto debería ser el mismo (¿verdad?).

Si solo estás transmitiendo entre los tipos numéricos incorporados, encuentro que la sintaxis de conversión estilo C++ es demasiado detallada.Como ex codificador de Java, tiendo a usar la sintaxis de conversión estilo C, pero mi gurú local de C++ insiste en usar la sintaxis del constructor.

¿Qué opinas?

¿Fue útil?

Solución

es la mejor practica nunca utilizar modelos estilo C por tres razones principales:

  • Como ya se mencionó, aquí no se realiza ninguna verificación.El programador simplemente no puede saber cuál de las distintas versiones se utiliza, lo que debilita la escritura fuerte.
  • Los nuevos elencos son intencionalmente visualmente impactantes.Dado que las conversiones a menudo revelan una debilidad en el código, se argumenta que hacer que las conversiones sean visibles en el código es algo bueno.
  • Esto es especialmente cierto si se buscan modelos con una herramienta automatizada.Encontrar modelos de estilo C de manera confiable es casi imposible.

Como señaló palm3D:

La sintaxis de conversión de estilo C++ me parece demasiado detallada.

Esto es intencional, por las razones expuestas anteriormente.

La sintaxis del constructor (nombre oficial:elenco de estilo de función) es semánticamente lo mismo como la versión de estilo C y también debe evitarse (excepto para las inicializaciones de variables en la declaración), por las mismas razones.Es discutible si esto debería ser cierto incluso para los tipos que definen constructores personalizados, pero en Effective C++, Meyers sostiene que incluso en esos casos debería abstenerse de usarlos.Para ilustrar:

void f(auto_ptr<int> x);

f(static_cast<auto_ptr<int> >(new int(5))); // GOOD
f(auto_ptr<int>(new int(5));                // BAD

El static_cast aquí realmente llamaré al auto_ptr constructor.

Otros consejos

De acuerdo a estrustrup:

Se introdujeron los "elencos de nuevo estilo" para dar a los programadores la oportunidad de declarar sus intenciones con mayor claridad y para el compilador para detectar más errores.

En realidad, es por seguridad, ya que realiza comprobaciones adicionales en tiempo de compilación.

Respecto a este tema, sigo las recomendaciones hechas por Scott Meyers (C++ más eficaz, Punto 2 :Prefiere conversiones de estilo C++).

Estoy de acuerdo en que el estilo C++ es detallado, pero eso es lo que me gusta de ellos:son muy fáciles de detectar y hacen que el código sea más fácil de leer (lo cual es más importante que escribir).

También te obligan a pensar qué tipo de yeso necesitas y a elegir el correcto, reduciendo el riesgo de cometer errores.También le ayudarán a detectar errores en tiempo de compilación en lugar de en tiempo de ejecución.

Utilizo static_cast por dos razones.

  1. Está explícitamente claro lo que está sucediendo.No puedo leer eso sin darme cuenta de que hay un yeso.Con los yesos estilo C, la vista puede pasar por encima sin pausa.
  2. Es fácil buscar cada lugar en mi código donde estoy transmitiendo.

Definitivamente estilo C++.La escritura adicional te ayudará a evitar que envíes contenido cuando no deberías :-)

Sintaxis de conversión de estilo C, no realice verificación de errores.Sintaxis de conversión de estilo C++, realiza algunas comprobaciones.Cuando usa static_cast, incluso si no realiza comprobaciones, al menos sabe que debe tener cuidado aquí.

El reparto estilo C es el peor camino a seguir.Es más difícil de ver, inamovible, combina diferentes acciones que no deberían combinarse y no puede hacer todo lo que pueden hacer las conversiones de estilo C++.Realmente deberían haber eliminado las versiones de estilo C del lenguaje.

Actualmente utilizamos moldes estilo C en todas partes.le pregunté al otro pregunta de casting, y ahora veo la ventaja de usar static_cast en su lugar, aunque solo sea por que es "greppable" (me gusta ese término).Probablemente empezaré a usarlo.

No me gusta el estilo C++;se parece demasiado a una llamada de función.

Opte por el estilo C++ y, en el peor de los casos, los feos fragmentos de código detallados que componían el encasillamiento explícito de C++ serán un recordatorio constante de lo que todos sabemos (es decir, el casting explícito es malo, lo que lleva a acuñar malas palabras).No opte por el estilo C++ si desea dominar el arte de rastrear errores de tiempo de ejecución.

La sintaxis del constructor.C++ es OO, los constructores existen, yo los uso.Si siente la necesidad de anotar estos ctor de conversión, debe hacerlo para cada tipo, no solo para los integrados.Tal vez utilice la palabra clave "explícita" para los ctors de conversión, pero la sintaxis del cliente imita exactamente lo que hace la sintaxis del ctor para los tipos integrados.Al ser greppable, eso puede ser cierto, pero qué gran sorpresa que escribir más caracteres facilite las búsquedas.¿Por qué tratarlos como especiales?Si está escribiendo fórmulas matemáticas con muchos int/unsigned/...hacia y desde doble/flotante (gráficos) y necesita escribir un static_cast cada vez, el aspecto de la fórmula se vuelve desordenado y es muy ilegible.Y de todos modos es una batalla cuesta arriba, ya que muchas veces convertirás sin siquiera darte cuenta de que lo estás haciendo.Para los punteros de abatimiento, uso static_cast ya que, por supuesto, no existe ningún ctor por defecto que haga eso.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top