Interessante presa di posizione sull'OLP - pagina 9

[fxsaber]

Igor Makanu:

Sono sicuro al 99% che questi codici saranno eseguiti con la stessa velocità fino a un tatto a livello di processore - il processore ha l'ottimizzazione, il parallelismo e qualsiasi altra cosa sia in esecuzione a livello di microcomando

Non si ottiene qui un effetto negativo quando si scrive codice di qualsiasi qualità facendo affidamento su "il compilatore lo spazzolerà fino a quello ottimale"?

Si sa per certo che il compilatore farà la cosa giusta con uno stile di scrittura. Con un altro stile, devi solo avere fiducia che il compilatore sia più intelligente.

Data la multipiattaforma, i diversi compilatori, ecc., scelgo di essere consapevole di ciò che sto facendo nel codice.

[Igor Makanu]

fxsaber:

Non ha un effetto negativo quando qualsiasi codice di qualità è scritto con l'aspettativa che "il compilatore lo spazzoli fino all'ottimale"?

I miei esempi non sono affatto di qualità, sono costrutti tipici - ho confrontato a lungo i sorgenti su githab, entrambi gli esempi tst1 e tst2, entrambi sono attivamente utilizzati dai programmatori

Ecco perché penso che gli sviluppatori di compilatori abbiano imparato molto tempo fa i costrutti di codice standard e non è un problema per i compilatori.

effetto negativo - come@TheXpert ha scritto sopra, ci sono requisiti aziendali per la formattazione del codice, ma i requisiti sono generalmente gli stessi - il codice deve essere comprensibile agli altri membri del team, compresi anche quelli che sono appena arrivati....

fxsaber:

Con uno stile di scrittura si sa per certo che il compilatore farà la cosa giusta. Con un altro stile devi solo avere fiducia che il compilatore sia più intelligente.

Non è il compilatore che è più intelligente ora, ma il processore stesso, imho, se stiamo parlando di codice ad alte prestazioni - il principale overhead di prestazioni non è nelle chiamate di funzione, ma nelle letture di memoria (accessi alla memoria) - se si può sostituire la memorizzazione di dati/variabili con piccoli valori calcolati, si avrà (a livello di ottimizzazione dei microcomandi del processore) un piccolo guadagno

... ma tutto il resto, imho, è male ))))

SZY: c'è anche l'ottimizzazione di un codice a livello del compilatore, non ho letto abbastanza - tutto a livello di un'ipotesi, sull'hardware del PC ho letto periodicamente, molto tempo ho letto, ho scritto il parere

fxsaber:

Data la multipiattaforma, i diversi compilatori, ecc., scelgo di essere consapevole di ciò che sto facendo nel codice.

Non ho scelta allora - in breve: "Sono un artista - è così che la vedo" ))) , spero di non aver offeso.

[Valeriy Yastremskiy]

Ho una regola, dopo 5 anni il codice deve essere comprensibile al codificatore, se non è comprensibile, cattivo codice.

E se capito da altri, molto bene.

[fxsaber]

Valeriy Yastremskiy:

Ho una regola, dopo 5 anni il codice deve essere comprensibile al codificatore, se non è comprensibile, cattivo codice.

E se capito da altri, molto bene.

Qui (e qui) c'è un codice molto buono. Ma non lo capisco. Il mio cervello ha smesso di crescere molto tempo fa.

[Valeriy Yastremskiy]

fxsaber:

Qui (e qui) è un codice molto buono. Ma non lo capisco. Il mio cervello ha smesso di crescere molto tempo fa.

Gli argomenti sono complicati, non tutti li capiranno, per non parlare del codice.

[Georgiy Merts]

Oh, che argomento... E senza di me... Non è buono... Bisogna parlare più forte.

Per quanto riguarda l'articolo nel titolo - la premessa corretta (il codice deve essere deterministico il più possibile) è usata in un modo molto sciocco, confrontando l'operazione di addizione e l'operazione di accumulazione come esempi. E la conclusione è che l'operazione di addizione è deterministica, restituisce sempre lo stesso risultato, mentre l'accumulazione non lo è, perché il risultato è sempre diverso.

Ma, mi scusi... Sono operazioni diverse, e in entrambi i casi i risultati sono perfettamente corretti, ed esattamente ciò che ci si aspetta dall'addizione e dall'accumulazione rispettivamente!

Anche l'esempio del generatore di numeri casuali - non può essere chiamato "non deterministico" se si considera un'operazione con una componente casuale.

Come mi sembra, tutta la faccenda del non-determinismo è che l'autore si aspetta dal codice niente affatto quello per cui il codice è destinato.

E la seconda cosa è la leggibilità del codice - trovo l'operazione "punto interrogativo" molto dannosa e difficile da capire. Sostituendo la "domanda" con un operatore condizionale si ottiene un codice eseguibile con assolutamente la stessa efficienza. In questo caso, il codice sorgente diventa notevolmente più voluminoso, ma anche molto più chiaro. Il che penso sia un grande vantaggio.

Cerco sempre di dividere tutte quelle numerose espressioni logiche in una serie di operazioni separate con risultati intermedi. Anche se tale codice risulta in un codice eseguibile meno efficiente, il beneficio di una migliore comprensione è, secondo me, molto più importante.

[Maxim Kuznetsov]

e questo è il regno della programmazione orientata all'albero di Natale :-)

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:

e questo è il regno della programmazione orientata all'albero di Natale :-)

Se le condizioni sono espressioni brevi, va bene. Anche se è possibile separarli in funzioni.

E nelle parentesi inverse in questi casi ho sempre messo un commento nell'intestazione della parentesi di apertura per renderlo chiaro.

[Andrey Khatimlianskii]

fxsaber:

Con uno stile di scrittura, sai per certo che il compilatore farà la cosa giusta. Con un altro, tutto quello che dovete fare è confidare che il compilatore sia più intelligente.

Non ci sarà alcuna differenza nell'esecuzione di questo

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

e questo:

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

Sono a favore di un codice facile da leggere e debuggare.

[Vitaly Muzichenko]

Andrey Khatimlianskii:

Non ci sarà alcuna differenza nel fare questo:

e questo:

Sono a favore di un codice facile da leggere e debuggare.

Non mi piace affatto questo design in termini di leggibilità e disordine

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