Cosa rende un programma (in una lingua come C ++) multipiattaforma o no?

C'è una linea molto chiara nella sabbia tra cross-platform e mono-piattaforma:

Un programma utilizza solo le API esposte dalla libreria standard su cui è basato?

Se scegli come target un'implementazione standard, qualsiasi piattaforma che implementa tale standard dovrebbe, in teoria, compilare ed eseguire correttamente il tuo programma. Ci sono molte eccezioni, ma in generale se si evitano trucchi intelligenti si dovrebbe essere in grado di evitare molte di queste eccezioni.

Il motivo per cui questo problema si presenta specificamente con C ++ è che per molto tempo la libreria standard C ++ non includeva molti moduli utili per programmi non banali. Concurrency e GUI sono i due grandi. Ciò significava che un programma creato utilizzando solo la libreria standard C ++ non poteva avere molte delle funzionalità che ci aspettiamo dal software moderno.

Come scriviamo software multipiattaforma che non supporta la libreria standard?

Si menzionano "librerie multipiattaforma", che in pratica vengono normalmente chiamate "framework" o "toolkit" in base al loro ambito. Il modo di scrivere software in C ++ che è multipiattaforma è quello di indirizzare non solo la libreria standard, ma un framework che si basa sulle piattaforme di destinazione.

In sostanza, si finisce per esternalizzare i bit specifici della piattaforma in un'altra libreria. Ad esempio, wxWidgets è un framework popolare. È possibile utilizzare le sue classi per costruire una GUI e le relative funzionalità (ad esempio finestre di dialogo standard per la selezione dei file). Sotto le copertine, utilizza la compilazione condizionale per implementare la GUI utilizzando la GUI nativa per ciascuna piattaforma. Ma come utente della biblioteca, niente di tutto questo ti interessa.

Nota storica: qui nel 2015 i compilatori e le librerie C ++ sono, per la maggior parte, veramente buoni. Torna indietro di qualche anno, e non è vero. Il C ++ non aveva uno standard ufficiale fino al 1998, molti anni dopo la sua nascita. Ci sono voluti tempi lunghi per aggiornare i compilatori e le librerie per implementare correttamente lo standard. Le estensioni specifiche del fornitore abbondavano (e sono ancora presenti, in realtà). Alcuni compilatori avevano intestazioni e funzionalità non standard. La portabilità del codice era praticamente inesistente. La reputazione di C ++ in termini di portabilità soffre ancora.

At what level of complexity does the platform start to matter and the program won't just run anywhere?

Sostanzialmente qualsiasi cosa non banale. Se scrivi un programma non banale, sarà casualmente accidentalmente a seconda di un modo specifico del compilatore che ordini sovraccarichi, ricerche di nomi e altre cose complesse. Inoltre, praticamente tutti i programmi non banali dipendono dal comportamento specifico della piattaforma non standard perché lo Standard non fornisce nulla tranne alcuni contenitori.

Tuttavia, i programmi non banali possono variare ampiamente in quanto sono facili da trasferire su un'altra piattaforma. Se lo hai programmato bene e rispettato le regole, puoi eseguire il port in modo abbastanza semplice, e bonus se puoi astrarre i pezzi in una libreria (che potrebbe essere già stata fornita per te, ad esempio Boost.Filesystem).

I programmi diventano per lo più molto difficili da portare tra piattaforme se eseguono attività intrinsecamente specifiche della piattaforma, ad esempio scrivendo dati su disco con determinate garanzie di atomicità / coerenza o, se lo si fosse un deficiente ed è andato in giro facendo cose stupide che non erano mai ciò che avresti dovuto fare in primo luogo, come il casting tra inte e puntatori.

In termini molto semplici, ciò che rende un programma multipiattaforma è la tua capacità di prendere le fonti da un ambiente, compilarle in un altro e far funzionare il prodotto finito come previsto.

In termini meno semplici, sta avendo una sovrapposizione completa tra ciò che il programma si aspetta sia disponibile e ciò che gli ambienti di destinazione forniscono. Una volta che fai qualcosa che rende la sovrapposizione inferiore al 100%, come l'uso di una libreria specifica per l'ambiente o di una lingua con comportamento indefinito, hai legato il tuo programma agli ambienti che possono fornire funzionalità non sovrapposte.

("Piattaforma" è un po 'una parola soffocante: le persone possono parlare di Windows e Unix come piattaforme o Linux, OS X, BSD e Solaris come piattaforme anche se sono tutte nominalmente Unix. sopra su architetture hardware diverse e le cose diventano ancora più nebulose. Detto questo, inizierò a usare la parola.)

Fortunatamente, esistono degli standard per facilitare questo problema:

Lingue. Stai scrivendo C ++, che è stato prima standardizzato dall'ISO nel 1998. Qualsiasi programma scritto che sia conforme a quello standard può essere compilato ed eseguito con i risultati attesi su qualsiasi piattaforma con un compilatore e un runtime conformi. Non c'è limite alle dimensioni o alla sofisticazione del programma se non si discosta dallo standard. Se un programma che soddisfa in modo soddisfacente lo standard non funziona come previsto su una determinata piattaforma, l'implementazione della lingua su quella piattaforma diventa sospetta. Molte lingue hanno suite di test progettate con cura che possono essere utilizzate per verificare la conformità.

Java riceve una menzione speciale perché non solo standardizza una lingua, ma standardizza anche il codice oggetto, che rende i suoi programmi eseguibili ovunque senza ricompilazione. Ciò si ottiene spingendo il punto di conformità verso un livello aggiuntivo in una macchina virtuale personalizzata della piattaforma (o anche hardware) in grado di eseguire il codice dell'oggetto.

API. Le chiamate che fai per fare in modo che il tuo programma faccia certe cose possono essere standardizzate. Come le lingue, queste API e le librerie che le implementano possono essere configurate per comportarsi come i chiamanti si aspettano di utilizzare un'implementazione sottostante adatta per una piattaforma particolare. Una di queste API è lo standard POSIX dell'IEEE, che è nato come un modo per arginare la frammentazione che stava accadendo a Unix durante gli anni '80 . (Ero in giro allora, questo aspetto non era divertente.) Definendo chiamate e comportamenti standard, i venditori di sistemi potevano dare ai loro clienti la certezza che la migrazione al loro sistema operativo non avrebbe comportato enormi quantità di lavoro come nel passato. POSIX è stato ampiamente adottato ed è ancora ampiamente utilizzato quasi 30 anni dopo.

Ho realizzato numerosi progetti che hanno seguito pedissequamente gli standard perché sapevo che avrebbero dovuto essere eseguiti su piattaforme multiple. Quello che ho ottenuto per i miei problemi era il codice che funzionava ovunque avessi programmato di eseguirlo e piacevolmente mi ha sorpreso su alcuni dei quali non avevo.

Fondamentalmente, quando tocchi cose al di fuori del tuo programma. Un caso particolare (non oso dire l'unico caso) è quando si utilizzano le librerie relative al sistema operativo. Cose come l'uso della memoria condivisa tra processo e stampa di cose fantasiose sulla console. Nel primo caso si accede a un pezzo di memoria gestito dal sistema operativo, nel secondo caso lo schermo è controllato anche dal sistema operativo.

Fare una GUI dipende dal sistema operativo, ma ci sono librerie GUI fatte per essere multipiattaforma, quindi non devi preoccupartene. Almeno in teoria.

È difficile rendere tutto non banale essere multipiattaforma. Il bello è che se si usano le librerie giuste e si fanno test adeguati non è difficile rendere il software portatile, almeno se il codice non è troppo grande. Quanto è grande è troppo grande dipende dalle dimensioni del tuo team, dalle competenze di programmazione e così via.