La misurazione della dimensione binaria di un programma c ++ è una buona indicazione della complessità del codice? O qualcos'altro?

Come notato nei commenti, la dimensione del file binario potrebbe essere molto importante per alcuni sistemi embedded, specialmente quelli vecchi.

Tuttavia, come hai notato nell'aggiornamento alla domanda

There is no customer or product driven arguments for it. It is a big server that is installed as singleton of a dedicated machine, where the executable size is completely ignorable in comparison to all the other resources involved in the system.

Questo è uno dei più schemi a punta di pelo che ho ascoltato da molto tempo. Sarai penalizzato per aver incluso una libreria che è ben testata e risolve un sacco di problemi, ma lasceranno passare una sorta di Bubble?

Seriamente, sarebbe utile vedere alcune giustificazioni per il loro argomento principale secondo cui la dimensione binaria è correlata con altre qualità del codice. È del tutto possibile che io sia completamente sbagliato e che ci sia una tale correlazione, ma ne dubito.

Ci sono stati alcuni cambiamenti e aggiornamenti, quindi vado con rev4 della tua domanda.

The main argument for this practice is that -Os binary size correlates with code complexity.

Stai chiedendo una dimensione binaria ottimizzata per le dimensioni per fungere da proxy per la complessità del codice; dalla versione alla versione quel numero può andare su o giù. Se hai detto che le misurazioni "su" osservate sono in genere correlate agli aumenti della complessità del codice, direi che è ... ragionevole.

Ma questo da solo non è utilizzabile .

Non hai detto perché i tuoi capi ti chiedono di farlo, o come usano le informazioni. Se stanno rifiutando un cambiamento solo perché la versione -Os del file binario è aumentata di 3K, sembra pazzesco. Se sono solo interessati a vedere / disegnare / rappresentare graficamente le modifiche al codice nel tempo, va bene, specialmente perché dovrebbe / potrebbe / potrebbe essere facile calcolare questo numero durante un processo di compilazione automatizzato. Se non altro, le metriche possono avviare conversazioni e / o agire come controlli di integrità.

Scenario 1

Boss: Vedo che le dimensioni non sono disponibili, come è successo?

Coder: Il marketing ci ha finalmente autorizzato a rimuovere completamente il set di funzionalità deprecate.

Boss: Oh, bello.

Scenario 2

Boss: Un aumento del 30% delle dimensioni? Pensavo che la nuova funzionalità comportasse un piccolo ritocco!

Coder: Questo è quello che pensavamo anche noi, ma una volta capito cosa chiedeva il cliente, dovevamo bla bla bla ....

La dimensione del file binario è praticamente solo una buona indicazione della dimensione del file binario. La complessità del codice deriva fondamentalmente dalla "scelta" (che sia la scelta di terminare un ciclo, una condizione in am if statement, un switch o cond block, anatra-tipizzazione, con più classi che implementano un'interfaccia, .. .). Per ogni data dimensione binaria, esiste un file binario di dimensioni comparabili interamente composto da codice lineare non ramificato.

La modifica delle dimensioni binarie (che è ciò che sembra effettivamente chiedere) può essere correlata o meno ai cambiamenti di complessità. È "più complesso" inserire una libreria collaudata per fare una (o più) cose? Probabilmente non è in alcun senso utile, purché le interfacce della libreria siano pulite e sufficientemente "black box". Aumenterebbe la dimensione binaria? Molto probabilmente.

Che cosa significa la complessità del codice in questo contesto? Stiamo parlando in termini di codice macchina o codice sorgente C ++ che gli umani devono mantenere? Direi "non necessariamente" anche se il primo, ma soprattutto "no" per quest'ultimo.

In una società del passato a cui ho lavorato, abbiamo spedito oltre 90 megabyte solo in termini di binari, e questo era un build di rilascio ottimizzato privo di informazioni di debug e così via. Ed era un codebase piuttosto complesso, milioni di LOC, ma sarebbe molto fuorviante dedurre la complessità del codice da quella dimensione binaria ...

... perché un weekend mi sono preso gioco del sistema di build e ho ottenuto il risultato in meno di 10 megabyte senza modificare alcun codice o modificare le impostazioni di ottimizzazione. Tutto ciò che ho fatto è stato collegare dinamicamente il CRT (C runtime lib) e un paio di altre grandi librerie nella nostra sezione di terze parti. Presto; questo ha eliminato ogni tipo di codice collegato staticamente a tutti i nostri binari (che si estendevano a centinaia con tutti i plugin che avevamo). Non ho controllato i cambiamenti da quando stavo scherzando (e non ero sicuro circa l'impatto di dipendere da dylibs in quel caso e C ++ può diventare faticoso lavorare oltre i limiti del modulo se il codice non è stato scritto in anticipo per occuparsi di per evitare di fare cose come buttare oltre i confini), ma almeno mi ha soddisfatto la mia curiosità che i binari almeno non dovessero essere teoricamente così massicci.

Quando vedo altri prodotti con binari massivi, tendo a chiedermi se potrebbero trarre beneficio dalla stessa cosa. D'altra parte, potrebbe non valere la pena prendersi cura di questa roba così tanto al di fuori dei dispositivi embedded con i nostri dischi fissi epici e la larghezza di banda che è abbondante. Comunque mi piace ancora l'estetica dei piccoli binari e cose che installano e scaricano molto velocemente e così via. È uno dei luoghi in cui sono ancora poco pratico e preferirei perdere tempo a rendere i binari più piccoli, partendo da giorni in cui un disco rigido da 10 MB era considerato eccezionale, ma ancora una volta non considero la dimensione binaria come un riflesso del complessità di un codebase poiché molti binari probabilmente stanno collegando staticamente il codice ridondante più e più volte.

La mia memoria è un po 'confusa, ma mi ricordo un po' di tempo fa circa 25 anni fa quando potevi prendere un programma C ++ "Hello World" e collegare staticamente tutto e finire con un file binario di poche centinaia di KB, e ho ricevuto molte critiche dai programmatori C. I miei ricordi potrebbero esagerare un po '(forse non era quello enorme), ma mi ricordo un po' quando alcuni compilatori C ++, ora sbiaditi nell'oscurità, tenderebbero a generare binari massivi per il più programmi banali anche senza informazioni di debug o qualcosa del genere. Questo è successo prima che gli stream I / O fossero standardizzati in C ++, penso (scusa, la mia memoria è così confusa).

La dimensione binaria è la metrica più fondamentale di qualsiasi build perché colpirà la linea di fondo del deliverable, nel bene o nel male.

Per i programmi di grandi dimensioni, come regola generale, le dimensioni binarie rifletteranno la complessità. Ciò sembra controintuitivo perché il codice ridondante o duplicato sembrerebbe essere un percorso verso dimensioni maggiori. In pratica, tuttavia, per i programmi non banali il codice ridondante tende ad essere difficile da mantenere, quindi è autolimitante. In altre parole, più grande diventa un programma, più diventa essenziale astrarlo per supportare un'ulteriore crescita. Per questo motivo, le dimensioni binarie tendono ad approssimare la complessità.

Si noti che è solo una metrica molto approssimativa, tuttavia. In alcuni casi è possibile trovare bloatware da parte di organizzazioni di grandi dimensioni, come IBM, dove sono riusciti a creare binari di grandi dimensioni utilizzando team di sviluppatori molto grandi che sono in qualche modo ridondanti. Tuttavia, anche in questi casi si applica la legge della manutenibilità e persino IBM non ne è immune; alla fine anche gli sforzi di manodopera più massicci soccombono all'inerzia se non sono astratti.

Quindi, come regola, specialmente per un determinato contesto aziendale, le dimensioni binarie forniranno una generalizzazione molto complessa della complessità.