He escuchado muchas veces esa frase de Bjarne Stroustrup "C++ hace que sea más difícil dispararse en el pie, pero cuando lo haces, se quita toda la pierna" y realmente no sé si es tan terrible como suena.¿Cuál es la característica más peligrosa de C++?
¿Qué es lo peor que le ha pasado a usted (o más propiamente, a su software) durante la programación en C++? ¿De qué manera puede ser más peligroso que decir C simple, por ejemplo?
delete [] array;
a veces puede llegar a ser
delete array;
en manos de alguien que no conoce. El seguimiento de ese error puede ser horrible, y no ocurre cuando estás haciendo malloc y de forma gratuita.
Como probablemente sepa, por qué no ocurre con malloc y libre es porque no hace una distinción entre una matriz o un solo elemento. – Skurmedel
Exactamente. Así que me deshice de la cláusula 'parece' allí; Estaba siendo cauteloso porque ha pasado tanto tiempo desde que utilicé C ... – mmr
Hehe mismo aquí :) – Skurmedel
Su implementación de manejo de excepciones es un camino fácil para las fugas de memoria.
¿Cómo es eso? ¿Estás pensando en el caso de las excepciones arrojadas por un puntero en lugar de una referencia? –
Con una RAII adecuada, esto no es un problema, creo que –
No estoy de acuerdo. No veo ninguna razón para que la memoria se filtre con excepciones. El estándar es muy claro en cómo se propone la excepción. –
desbordamientos de búfer tienen que ser las cosas más peligrosas tanto en c como en C++. Esta es también la razón por la que Microsoft announced that they have added memcpy() to their list of banned functions
herencia múltiple es otro
Lo más peligroso de cualquier idioma sin protección de desbordamiento. – Skurmedel
Probablemente el aspecto más peligroso de C++ que no existe en C es la capacidad de anular los operadores para este tipo de complejos. Puede ser muy fácil hacer suma de resta (y viceversa), por ejemplo.
Es estúpido que alguien pueda hacer eso, pero se puede hacer. Haciéndolo peligroso.
El requisito del destructor virtual es fácil de perder para los recién llegados (aunque creo que la mayoría de los compiladores son lo suficientemente inteligentes como para señalarlo).
¿Qué requisito de destructor virtual? – ralphtheninja
@Magnus: si destruyes un objeto mediante un puntero a su base (o cualquier antecesor), entonces si el destructor no es virtual se invocará el destructor incorrecto. Por lo tanto, las clases que están diseñadas para ser anuladas probablemente deberían tener un destructor virtual. –
Operator overloading. Muy fácil hacer que las cosas sean difíciles de entender lo que está pasando. Es fácil pasar por alto el hecho de que está ocurriendo una sobrecarga, incluso para desarrolladores con experiencia en C++.
Los operadores sobrecargados tienen su lugar. No diría que la característica es inherentemente mala, puede ser bastante útil. Es cuando las personas comienzan a definirlos para hacer las cosas de manera contra intuitiva que surgen las dificultades. Los operadores sobrecargados, cuando se usan correctamente, pueden hacer que el código sea más simple y más limpio. –
Si comparas la seguridad de C++ con respecto a C, te has perdido el objetivo de esa frase. C++ podría decirse que no es más seguro que C.
Donde la comparación realmente se puede hacer es con un lenguaje como Java. Esencialmente, Java maneja su memoria por usted, por lo que no terminará con un comportamiento indefinido cuando llame a la memoria fuera de la memoria que su programa está utilizando actualmente (saliéndose de los límites en las matrices, etc.).
Para resolver su pregunta, lo peor que me pasó fue un desbordamiento del búfer para anular mi propia contraseña (sin embargo, lo hice con determinación).
Muy cierto. Los aspectos más peligrosos de C++ son en realidad holdovers de C. Hay algunas características en C++ que no existen en C (como la sobrecarga del operador); Creo que la pregunta es sobre ellos. – Randolpho
De hecho, la comprobación de tipo estática puede aplicarse más estrictamente en C++ que en C, creo (los typedefs son al final algo así como "todo vale") – fortran
C++ le da la opción, puede usar límites de matriz marcados si lo desea - pero no tiene que (y pagar la penalización de rendimiento) si no necesita –
Siempre me he preguntado acerca de esa cita. No puedo pensar en ninguna forma en la que C++ es más peligroso que C.
En cualquier caso, tengo que decir que el más peligroso "característica" es que no hay nada que le impida el acceso a memoria no asignada. Es un error que es casi imposible de depurar, provoca todo tipo de comportamiento aleatorio, desde fallas hasta nada y solo un comportamiento extraño.
me pasó este a una función de ayuda en otro objeto a partir de un constructor. La función auxiliar agregó el puntero a una lista de objetos que mantenía.Por supuesto, después de que el constructor terminó y regresó, el objeto estaba ubicado en una ubicación muy diferente en la memoria y el puntero almacenado en el otro objeto ya no era válido. ¡Ay!
¿Es eso verdad? : - | – fortran
Nunca es seguro filtrar "esto" de un constructor. Particularmente no en un entorno de subprocesos múltiples, en cuyo caso el objeto puede estar parcialmente construido o solo parcialmente visible. No se puede asumir que los objetos están completamente construidos hasta después de que el constructor haya regresado (esto también es cierto para Java y C#). –
Parece que has tenido un error. –
Tendría que decir la conversión de tipo automático. C++ puede crear variables temporales de forma poco intuitiva a través de la conversión automática de tipos.
Cuando se da cuenta de que lo está haciendo no hay nada peligroso. El arma en manos de mono siempre puede ocasionar problemas. –
Sí, pero la banana conduce a mucho menos. –
No le daré una respuesta, pero le diré el consejo más memorable que he escuchado sobre el tema. Es decir, "si olvida capturar una excepción, ¡toda su aplicación se cerrará!". Por alguna razón, eso me sonaba bastante siniestro en ese momento. –