El estilo de C++ vs rendimiento?

1. Desaconsejaría atoi, y atol como regla, pero no solo por motivos de estilo. Hacen que sea esencialmente imposible detectar errores de entrada. Mientras que un stringstream puede hacer el mismo trabajo, strtol (por ejemplo) es lo que me gustaría generalmente aconsejar como el reemplazo directo.
2. No estoy seguro de quién está dando ese consejo. Use punteros inteligentes cuando sean útiles, pero cuando no lo sean, no hay nada de malo en usar un puntero raw.
3. Yo realmente no tengo idea de quién piensa no es" buena práctica " usar operadores bitwise en C++. A menos que hubiera algunas condiciones específicas asociadas a ese consejo, diría que fue simplemente incorrecto.
4. Este depende en gran medida de dónde se traza la línea entre una entrada excepcional y (por ejemplo) una entrada que se espera, pero no se puede usar. En términos generales, si estás aceptando entradas directas del usuario, no puedes (y no deberías) clasificar nada como verdaderamente excepcional. El principal punto bueno de las excepciones (incluso en un situación como esta) está asegurando que los errores no sean simplemente ignorados. OTOH, no creo que ese sea siempre el único criterio, así que no puedes decir que es la manera correcta de manejar cada situación.

En general, me parece que has recibido algunos consejos que son dogmáticos hasta el punto de ignorar la realidad. Probablemente es mejor ignorarlo o al menos verlo como una posición bastante extrema sobre cómo C++ podría escribirse, no necesariamente como siempre (o siempre, necesariamente) debe escribirse.

Añadiendo a la respuesta de @Jerry Coffin, que creo que es extremadamente útil, me gustaría presentar algunas observaciones subjetivas.

• La cosa es que los programadores tienden a ponerse elegantes. Es decir, a la mayoría de nosotros realmente nos gusta escribir código de lujo solo por el bien de ello. Esto está perfectamente bien, siempre y cuando usted está haciendo el proyecto por su cuenta. Recuerde que un buen software es aquel cuyo código binario funciona como se espera y no aquel cuyo código fuente está limpio. Sin embargo, cuando se trata de más grande proyectos que son desarrollados y mantenidos por mucha gente, es económicamente mejor escribir código más simple para que nadie del equipo pierda tiempo para entender lo que querías decir. Incluso a costa del tiempo de ejecución(naturalmente un costo menor). Es por eso que muchas personas, incluyéndome a mí, desalentarían el uso del truco xor en lugar de la asignación(puede que te sorprendas, pero hay muchos programadores por ahí que no han oído hablar del truco xor). El truco xor funciona solo para enteros de todos modos, y el la forma tradicional de intercambiar enteros es muy rápida de todos modos, por lo que usar el truco de xor es solo ser elegante.

• Usar itoa, atoi, etc. en lugar de streams es más rápido. Sí, lo es. ¿Pero cuánto más rápido? No mucho. A menos que la mayoría de su programa solo haga conversiones de texto a cadena y viceversa, no notará la diferencia. ¿Por qué la gente usa itoa, atoi, etc.? Bueno, algunos de ellos lo hacen, porque no son conscientes de la alternativa de c++. Otro grupo lo hace porque es solo un LOC. Para el grupo anterior-vergüenza en usted, para el último - ¿por qué no boost:: lexical_cast?

• Excepciones... ah ... sí, pueden ser más lentos que los códigos de retorno, pero en la mayoría de los casos no realmente. Los códigos de devolución pueden contener información, lo cual no es un error. Las excepciones deben utilizarse para informar de errores graves, aquellos que no se puede ignorar. Algunas personas se olvidan de esto y usan excepciones para simular algunos mecanismos extraños de señal / ranura (créeme, lo he visto, yuck). Mi opinión personal es que no hay nada malo usando códigos de retorno, pero los errores graves deben ser reportados con excepciones, a menos que el generador de perfiles haya demostrado que abstenerse de ellos aumentaría considerablemente el rendimiento

• Punteros raw - Mi propia opinión es la siguiente: nunca use punteros inteligentes cuando no se trata de propiedad. Siempre use punteros inteligentes cuando se trata de propiedad. Naturalmente, con algunas excepciones.

• Desplazamiento de bits en lugar de multiplicación por potencias de dos. Este, creo, es un ejemplo clásico de optimización prematura. x << 3; Apuesto a que al menos el 25% de sus compañeros de trabajo necesitarán algún tiempo antes de que entiendan/se den cuenta de esto significa x * 8; Código ofuscado (al menos para el 25%) ¿por qué razones exactas? Una vez más, si el perfilador le dice que este es el cuello de botella (que dudo que sea el caso para casos extremadamente raros), entonces luz verde, adelante y hazlo (dejando un comentario que de hecho esto significa x * 8)

Para resumirlo. Bueno profesional reconoce los "buenos estilos", entiende por qué y cuándo son buenos, y legítimamente hace excepciones porque sabe lo que está haciendo. Los profesionales promedio / malos se clasifican en 2 tipos: el primer tipo no reconoce el buen estilo, ni siquiera entiende qué y por qué es. despídelos. El otro tipo trata el estilo como un dogma, que no siempre es bueno.

¿Qué es una buena práctica ? Las palabras de Wikipedia son mejores que las mías:

Una buena práctica es una técnica, método, proceso, actividad, incentivo, o recompensa que sabiduría convencional más eficaz en el entrega de un resultado particular que cualquier otra técnica, método, proceso, sucesivamente. cuando se aplica a un condición o circunstancia.

[...]

A given best practice is only aplicable a condición particular o circunstancia y puede tener que ser modificado o adaptado para similares circunstancias. Además, un " mejor" la práctica puede evolucionar para ser mejor a medida que se descubren mejoras.

Creo que no hay tal cosa como la verdad universal en la programación : si usted piensa que algo es un mejor ajuste en su situación que una llamada "mejor práctica", entonces haga lo que usted cree que es correcto, pero sepa perfectamente por qué lo hace (es decir: probarlo con números).

1. Las funciones con argumentos mutables char* son malas en C++ porque es demasiado difícil manejar manualmente su memoria, ya que tenemos una alternativa. No son genéricos, no podemos cambiar fácilmente de char a wchar_t como basic_string lo permite. También lexical_cast es un reemplazo más recto para atoi, itoa.
2. Si realmente no necesita la inteligencia de un puntero inteligente, no lo use.
3. Para intercambiar utilice swap. Usar operaciones bitwise solo para operaciones bitwise-checking / setting / inverting flags, sucesivamente.
4. Las excepciones son rápidas. Permiten eliminar ramas de condición de comprobación de errores, por lo que si realmente "nunca ocurren", aumentan el rendimiento.

La multiplicación por bitshifting no mejora el rendimiento en C, el compilador lo hará por ti. Solo asegúrese de multiplicar o dividir por 2 valores^n para el rendimiento.

El intercambio de campos de bits también es algo que probablemente confundirá a tu compilador.

No tengo mucha experiencia con el manejo de cadenas en C++, pero por lo que sé, es difícil creer que sea más flexible que scanf e printf.

Además, estas declaraciones de" nunca debes", generalmente las considero como recomendaciones.

Todas tus preguntas son a priori. Lo que quiero decir es que las estás preguntando en abstracto, no en el contexto de ningún programa específico cuyo desempeño sea de tu incumbencia. Es como intentar nadar sin estar en el agua.

Si sintoniza un programa concreto específico, encontrará problemas de rendimiento, y es probable que no tengan casi nada que ver con estas preguntas abstractas. Lo más probable es que todas sean cosas que no podrías haber pensado a priori.

Para un ejemplo específico de esto, mira aquí.

Si pudiera generalizar a partir de la experiencia, una fuente importante de problemas de rendimiento es generalidad galopante. Es decir, mientras que la abstracción de la estructura de datos generalmente se considera una buena cosa, cualquier cosa buena puede ser masivamente utilizada en exceso, y luego se convierte en una cosa mala paralizante. Esto no es raro. En mi experiencia es típico.

Creo que estás respondiendo grandes partes de tu pregunta por tu cuenta. Personalmente prefiero el código fácil de leer (incluso si entiendes el estilo C, tal vez el siguiente en leer tu código tenga más problemas con él) y el código seguro (que sugiere stringstream, excepciones, punteros inteligentes...)

Si realmente tiene algo en lo que tiene sentido considerar operaciones bitwise - ok. Pero a menudo veo que los programadores de C usan un char en lugar de un par de bools. No me gusta esto.

La velocidad es importante, pero la mayor parte del tiempo se requiere generalmente en algunos puntos de acceso en un programa. Así que a menos que midas que alguna técnica es un problema (o sabes bastante seguro de que se convertirá en uno) Prefiero usar lo que llamas estilo C++.

¿Por qué el carácter costoso de las excepciones es un argumento? Las excepciones son excepciones porque son raras. Su rendimiento no influye en el rendimiento general. Los pasos que debe seguir para hacer que su excepción de código sea segura tampoco influyen en el rendimiento. Pero por otro lado las excepciones son convenientes y flexibles.

Esto no es realmente una "respuesta", pero si trabajas en un proyecto donde el rendimiento es importante (por ejemplo, embedded/games), la gente suele hacer la forma C más rápida en lugar de la forma C++ más lenta en las formas que describiste.

La excepción puede ser operaciones bitwise, donde no se gana tanto como se podría pensar. Por ejemplo ,"No utilices el desplazamiento a la izquierda para multiplicar por dos."Un compilador decente a medio camino generará el mismo código para