So di controllare / utilizzare asserzioni e di esaminare attentamente tutti i componenti dell'assieme, ma non sapevo se qualcuno là fuori avesse una lista di controllo abbastanza completa o standard del settore di cose specifiche a cui guardare? Sto guardando più a C e C ++.
nota: ci sono alcune risposte davvero utili, sto lasciando la domanda aperta per un paio di giorni nel caso in cui alcuni individui controllino solo le domande che non hanno risposte accettate.
Non un elenco completo, ma alcune delle cose che ho incontrato durante la conversione di una grande base di codice C ++:
Biblioteche, ovviamente. Trova tutti loro e guarda cosa hanno. Nel mio caso, abbiamo deciso di passare alle librerie Open Source per la gestione di JPEG e la compressione dei dati, e così abbiamo compilato la nostra. Le librerie commerciali potrebbero darti più problemi.
Conversioni puntatore. Sui sistemi a 32 bit, di solito sizeof(int) == sizeof(void *) , e molte persone lavorano su questa base. Su un sistema a 64 bit un round trip dal puntatore a int al puntatore di solito perde metà del puntatore. Il tuo compilatore dovrebbe essere in grado di aiutarti qui.
Valori delle dimensioni dell'oggetto dati. Sarebbe un buon momento per passare e modificare tutti i valori di dimensione in size_t , se li trovi e le differenze tra puntatori e ptrdiff_t . Questo non sarà necessariamente un problema, ma dal momento che eravamo spinti dalla dimensione dei dati su cui stavamo lavorando volevo assicurarmi che potesse crescere il più possibile.
Dimensione dell'oggetto. Qualsiasi struct o class che hai con i membri del puntatore aumenterà, e se stai modificando qualsiasi int in size_t o ptrdiff_t . Di nuovo, è improbabile che questo sia un problema, ma potresti voler controllare l'I / O. Se stai facendo un I / O binario, hai davvero bisogno di esaminare cosa viene inserito e prodotto. Se stai inviando o ricevendo dati attraverso un protocollo fisso, devi guardarlo. Fai un grep per union e controlla ciascuno per le modifiche.
Una cosa da fare attenzione sono le librerie di terze parti da cui si dipende. Alcuni potrebbero non essere stati portati su x64 o avere una versione separata per i progetti x86 e x64, quindi dovrai fare del lavoro extra per gestire le dipendenze e assicurarti di costruire contro la libreria corretta per la tua piattaforma di destinazione.
Do you have any thoughts on moving depended packages into the source tree to minimise this type of problem? For example, mplayer does this. I have noticed doing it this way often mangles some things and leads to a complicated configure script, but it seems like a valid approach.
Questo suona bene per me, specialmente se puoi automatizzare la maggior parte della non tutta la tua gestione delle dipendenze per le build.
L'ultima volta che mi sono imbattuto in questo, abbiamo fatto qualcosa di simile: abbiamo mantenuto le dipendenze di terze parti su una condivisione (e / o sul controllo del codice sorgente - abbiamo provato in entrambi i modi) e gli sviluppatori hanno mantenuto il loro ambiente locale utilizzando gli script batch forniti per impostare con le versioni giuste. Il codice dovrebbe essere scritto con un riferimento a un particolare nome di DLL in mente. Abbiamo lavorato in .NET, quindi per esempio i nostri file di progetto avrebbero fatto riferimento a Whatever.dll e al termine della compilazione, avevamo uno script che sostituiva la versione a 64 bit al suo posto. Se ricordo, la macchina di compilazione userebbe gli stessi script che gli sviluppatori userebbero per afferrare le giuste versioni di libreria. Non è stato necessario modificare i file di progetto, poiché i nomi di dll non sono stati modificati.
Dove sono ora, modifichiamo i file csproj per includere riferimenti specifici della piattaforma, quindi invece del normale percorso relativo alla dipendenza che Visual Studio inserisce, usiamo la variabile ${Platform} ed è controllata attraverso le configurazioni del progetto - - in un progetto x64, avremo una configurazione "win64", quindi ${Platform} verrà sostituito con "win64" e le dll verrebbero quindi estratte dalla sottocartella "win64" della cartella che contiene tutte le nostre dipendenze.
Il test è una delle cose più importanti da considerare. La maggior parte dei test del software si basa su "grandfathering" - le funzionalità che prima funzionavano e non sono cambiate saranno OK per questa versione. Quello che troverete con il passaggio a 64 bit (a meno che il vostro codice sia particolarmente buono) è che i problemi che non hanno avuto sintomi in precedenza si presenteranno - a volte in modi strani e inspiegabili. Cose come i buffer overflow precedentemente "contenuti", ipotesi sulle dimensioni dei dati che causano nuovi buffer overflow, matematica dei puntatori dubbia ecc.
L'importo dipenderà in gran parte dalla qualità della base di codice - in un caso ci è voluto molto tempo per passare da "finito" a "accettazione da parte del cliente".