Interesante visión de la OLP - página 9

[fxsaber]

Igor Makanu:

Estoy 99% seguro de que estos códigos se ejecutarán con la misma velocidad hasta un tacto a nivel de procesador - el procesador tiene optimización, paralelismo y cualquier otra cosa que se ejecute a nivel de microcomando

¿No se produce aquí un efecto negativo cuando se escribe código de cualquier calidad confiando en que "el compilador lo cepillará hasta el óptimo"?

Sabes con certeza que el compilador hará lo correcto con un estilo de escritura. Con otro estilo, sólo hay que confiar en que el compilador es más inteligente.

Teniendo en cuenta la multiplicidad de plataformas, los diferentes compiladores, etc., opto por ser consciente de lo que estoy haciendo en el código.

[Igor Makanu]

fxsaber:

¿No tiene un efecto negativo el hecho de que cualquier código de calidad se escriba con la expectativa de que "el compilador se lo cepillará hasta lo óptimo"?

Mis ejemplos apenas tienen calidad, son construcciones típicas - hace tiempo que comparo las fuentes en githab, tanto los ejemplos de tst1 como de tst2, ambos son utilizados activamente por los programadores

Por eso creo que los desarrolladores de compiladores aprendieron las construcciones de código estándar hace mucho tiempo y no es un problema para los compiladores.

efecto negativo - aquí, como@TheXpert escribió anteriormente, hay requisitos de la empresa para el formato del código, pero los requisitos son generalmente los mismos - el código debe ser comprensible para otros miembros del equipo, incluso los que acaban de llegar....

fxsaber:

Con un estilo de escritura se sabe con seguridad que el compilador hará lo correcto. Con otro estilo sólo hay que confiar en que el compilador es más inteligente.

No es el compilador el que es más inteligente ahora, sino el propio procesador, en mi opinión, si estamos hablando de código de alto rendimiento - la principal sobrecarga de rendimiento no está en las llamadas a funciones, sino en las lecturas de memoria (accesos a memoria) - si puedes sustituir el almacenamiento de datos/variables por pequeños valores de cálculo, tendrás (a nivel de optimización de microcomandos del procesador) una pequeña ganancia

... pero todo lo demás, en mi opinión, es malo ))))

SZY: también hay optimización de un código en un nivel del compilador, no he leído lo suficiente - todo en un nivel de una conjetura, en el hardware de PC que periódicamente leer, mucho tiempo he leído, he escrito la opinión

fxsaber:

Teniendo en cuenta la multiplicidad de plataformas, los diferentes compiladores, etc., opto por ser consciente de lo que estoy haciendo en el código.

No tengo otra opción entonces - en resumen: "Soy un artista - así es como lo veo" ))) , espero no haber ofendido.

[Valeriy Yastremskiy]

Tengo una regla, después de 5 años el código debe ser comprensible para el codificador, si no es comprensible, mal código.

Y si lo entienden los demás, muy bien.

[fxsaber]

Valeriy Yastremskiy:

Tengo una regla, después de 5 años el código debe ser comprensible para el codificador, si no es comprensible, mal código.

Y si lo entienden los demás, muy bien.

Aquí ( y aquí) hay un código muy bueno. Pero no lo entiendo. Mi cerebro dejó de crecer hace mucho tiempo.

[Valeriy Yastremskiy]

fxsaber:

Aquí ( y aquí) hay un código muy bueno. Pero no lo entiendo. Mi cerebro dejó de crecer hace mucho tiempo.

Los temas son complicados. No todo el mundo los entenderá,) por no hablar del código.

[Georgiy Merts]

Oh, qué tema... Y sin mí... No es bueno... Hay que hablar.

En cuanto al artículo del título - la premisa correcta (el código debe ser determinista en la medida de lo posible) se utiliza de forma muy tonta, comparando la operación de suma y la de acumulación como ejemplos. Y la conclusión es que la operación de suma es determinista, siempre devuelve el mismo resultado, mientras que la acumulación no lo es, porque el resultado siempre es diferente.

Pero, disculpa... ¡Son operaciones diferentes, y en ambos casos los resultados son perfectamente correctos, y exactamente lo que se espera de la suma y la acumulación respectivamente !

Incluso el ejemplo del generador de números aleatorios - tampoco puede llamarse "no determinista" si se considera que es una operación con un componente aleatorio.

Según me parece, lo de no determinista es que el autor espera del código en absoluto lo que el código pretende.

Y lo segundo es la legibilidad del código: la operación "signo de interrogación" me parece muy perjudicial y difícil de entender. La sustitución de la "pregunta" por un operador condicional produce un código ejecutable con absolutamente la misma eficacia. En este caso, el código fuente es notablemente más voluminoso, pero también mucho más claro. Lo que creo que es una gran ventaja.

Siempre intento dividir todas esas numerosas expresiones lógicas en una serie de operaciones separadas con resultados intermedios. Incluso si ese código resulta en un código ejecutable menos eficiente, el beneficio de una mejor comprensión es, en mi opinión, mucho más importante.

[Maxim Kuznetsov]

y este es el reino de la programación orientada a los árboles de Navidad :-)

void OnStart()
  {
   if(condition)
     {
      if(other_condition)
        {
         for(loop_stmt)
           {
            if(wtf)
              {
               while(repeats)
                 {
                  if(oh_shit)
                    {
                     if(really_fck)
                       {
                        deep_nesting();
                       }
                    }
                 }
              }
           }
        }
     }
  }

[Georgiy Merts]

Maxim Kuznetsov:

y este es el reino de la programación orientada a los árboles de Navidad :-)

Si las condiciones son expresiones cortas, está bien. Aunque se pueden separar en funciones.

Y en los paréntesis inversos en estos casos siempre pongo un comentario en la cabecera del paréntesis inicial para que quede claro.

[Andrey Khatimlianskii]

fxsaber:

Con un estilo de escritura, sabes con seguridad que el compilador hará lo correcto. Con otro, lo único que hay que hacer es confiar en que el compilador es más inteligente.

No habrá ninguna diferencia en la ejecución de este

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  

y esto:

return( a() || b() );

Estoy a favor de un código fácil de leer y depurar.

[Vitaly Muzichenko]

Andrey Khatimlianskii:

No habrá ninguna diferencia al hacer esto:

y esto:

Estoy a favor de un código fácil de leer y depurar.

No me gusta nada este diseño en cuanto a legibilidad y desorden

if ( a() ) return(true);
if ( b() ) return(true);
return(false);