c++ - programacion - ¿Hay alguna ventaja en el uso de static_cast en lugar de la fundición de estilo C para los tipos que no son de puntero?
ventajas y desventajas de python (4)
Soy muy consciente de la ventaja de usar static_cast lugar de fundición estilo C para tipos de punteros.
Si los tipos de puntero son incompatibles, entonces:
-
static_castproducirá un error de tiempo de compilación en una línea específica dentro del código fuente - La conversión de estilo C puede generar un error de tiempo de ejecución en un punto "aleatorio" en la ejecución del programa
Pero no puedo encontrar ningún ejemplo similar para tipos que no sean punteros.
En otras palabras, ambos métodos de conversión arrojan el mismo resultado para los tipos que no son punteros.
¿Es correcto o me he perdido algo?
En caso afirmativo, ¿se usa static_cast para tipos que no son punteros solo para mantener la consistencia de la codificación?
¿
static_castusastatic_castpara tipos no punteros solo para mantener la consistencia de la codificación?
No solo eso, sino también para ayudar a mantener la corrección y la compatibilidad futura.
Ayuda a mantener la corrección, ya que static_cast no puede hacer algunos lanzamientos que un molde de estilo C puede hacer. Esto ayuda si comete un error sobre algunos de los tipos involucrados, tal vez manejar un puntero mientras se convence de que es un número entero (y varias capas de plantillas y tipos, no es demasiado difícil de imaginar). Entonces, si pretendes un static_cast , escribe uno y obtienes un error en tiempo de compilación, se te static_cast inmediatamente que los tipos involucrados no son lo que pensabas que eran. Con la actitud de "todo vale" del elenco estilo C, no descubrirás el error a tiempo.
También ayuda con la compatibilidad futura. Si los tipos involucrados en el elenco cambian más adelante en el desarrollo, un static_cast informará un error en el que un elenco de estilo C simplemente cambiará su comportamiento silenciosamente (a algo que probablemente no sea el deseado).
¿static_cast se usa para tipos no punteros solo para mantener la coherencia de codificación?
No (bueno, sí, pero no solo).
También es fácil de encontrar / reemplazar. Esto es importante en caso de refactorizaciones, corrección de errores, etc.
Es una restricción en el tipo de reparto permitido: considere un ejemplo en el que tenga un molde estilo C (que funciona bien) en una variable, luego cambie la declaración de la variable lanzada, a algo que lo haga inválido (por ejemplo, , cambia int x; a void * const x; ).
El elenco de estilo C de repente realiza otra función (es decir, const_cast<...>(reinterpret_cast<...>(...) ) con el mismo código.
Si escribe el código inicial con un static_cast en lugar de un elenco de estilo C, el compilador le informará que static_cast no está realizando un lanzamiento estático.
Estoy asumiendo que los usos triviales de las referencias para evitar punteros no contarán.
En ese caso: un elenco de estilo C puede ser:
- un
const_cast - un
static_cast - un
static_castseguido de unconst_cast, - una
reinterpret_cast - un
reinterpret_castseguido de unconst_cast
con la excepción de que se static_cast las restricciones de static_cast sobre las clases base inaccesibles.
const_cast solo se aplica a punteros y referencias.
reinterpret_cast solo se aplica a punteros y referencias. Incluye conversiones de puntero a entero y viceversa, pero eso todavía implica un tipo de puntero.
Esa excepción especial para static_cast solo se aplica a punteros y referencias.
Así que sí, al excluir punteros y referencias, ha excluido todo lo que admite el estilo C en una static_cast .
En caso afirmativo, ¿se usa
static_castpara tipos que no son punteros solo para mantener la consistencia de la codificación?
Vamos con una analogía: no utilizaría una motosierra para abrir una bolsa de papas fritas. Podría, pero las motosierras son peligrosas, así que al usar una, introduciría riesgos innecesarios. Es muy fácil usar una motosierra incorrecta, y si la uso mal, no hay un mecanismo de seguridad para evitar accidentes.
Una ventaja que las otras dos respuestas no mencionaron aún es que static_cast es mucho más fácil de detectar. El significado de paréntesis es notoriamente sobrecargado en C ++ y puede ser difícil detectar yesos malvados (o incluso incorrectos). _cast embargo, cuando veo que algo termina en _cast , es como un golpe de velocidad mental: desacelero y compruebo cuidadosamente por qué el sistema de tipos está siendo subvertido.