Questo tipo di problemi di solito appaiono quando non si attaccano allo standard C nuda, e fare ipotesi circa l'ambiente che potrebbe non essere vero. Questi possono includere dipendenza:
- non standard, specifica piattaforma include (
<conio.h>, <windows.h>, <unistd.h>, ...);
- comportamento non definito (
fflush(stdin), come è stato segnalato da qualcun altro, non è richiesto di fare nulla dallo standard - è in realtà un comportamento indefinito invocare fflush su qualsiasi cosa tranne i flussi di output; in generale, i compilatori più vecchi erano più indulgenti in merito alla violazione di alcune regole sottili come il rigoroso aliasing, quindi fai attenzione con i trucchi puntatori "intelligenti");
- tipo di dati di formato (il bit
short = 16, int = long = 32 assunzione bit non tenere ovunque - 64 bit Linux, per esempio, ha 64 bit long);
- in particolare, dimensioni del puntatore (
void * non è sempre a 32 bit, e non può essere sempre fusa in modo sicuro ad una unsigned long); in generale, si dovrebbe stare attenti con conversioni e confronti che coinvolgono puntatori, e si dovrebbe sempre utilizzare i tipi previsti per quel tipo di attività, invece di "normali" int s (si veda in particolare size_t, ptrdiff_t, uintptr_t) Tipo
- dati " formato interno "(lo standard non dice che
float se double s siano in IEEE 754, sebbene non abbia mai visto le piattaforme farlo in modo diverso);
- funzioni non standard (
__beginthread, MS stringhe sicure funzioni, dall'altro lato, le estensioni POSIX/GNU)
- estensioni del compilatore (
__inline, __declspec, #pragma s, ...) e, in generale, tutto ciò che inizia con la doppia sottolineatura (o anche con un trattino singolo, in implementazioni vecchie e non standard);
- codici di escape della console (questo di solito è un problema quando si tenta di eseguire il codice Unix su Windows);
- formato di ritorno a capo: in stringhe normali è
\n ovunque, ma se scritto su file è \n su * NIX, \r\n su Windows, \r su Mac pre-OSX; la conversione viene gestita automagicamente dai flussi di file, quindi fate attenzione di aprire i file in formato binario quando effettivamente vuole scrivere dati binari, e lasciarli in modalità testo quando si desidera scrivere il testo.
In ogni caso un esempio di programma che non si compila su * NIX sarebbe utile, potremmo darvi suggerimenti più precisi.
I dettagli sul programma sono ancora da ottenere. Gli studenti provenivano dal nostro gruppo precedente. L'ho chiesto. turbo C è ciò che viene attualmente utilizzato.
Come detto nel commento, si prega di cadere Turbo C e (se lo si utilizza) Turbo C++, al giorno d'oggi sono entrambi pezzi di storia e hanno molte incompatibilità con gli standard C++ C attuale e (e se ricordo bene entrambi generano file eseguibili a 16 bit, che non funzioneranno nemmeno su sistemi operativi a 64 bit su x86_64).
Esistono molte alternative gratuite, di lavoro e conformi agli standard (VC++ Express, MinGW, Pelles C, CygWin su Windows e gcc/g ++ è lo standard di fatto su Linux, rivaleggiato da clang), solo devo sceglierne uno
fonte
2010-02-19 09:53:28
Forse stai facendo delle ipotesi che non sono garantite come vere secondo lo standard C, ma sono vere in un ambiente Windows. Se puoi, per favore pubblica un piccolo programma che mostri questo comportamento. Dovresti anche leggere lo standard C, o la versione draft se non puoi permetterti di comprarlo: http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf (questo è per C99). –
Nessun sistema UNIX nel tuo laboratorio? Wow. Quanto sarebbe difficile creare un paio di Linux box? –
Un semplice esempio è '#include'. Quel file non esiste in Unix. Ci sono troppe differenze e un elenco esaustivo potrebbe non essere comunque possibile. –