[c] Rendere sorgente portabile

[tglman]

Sto lavorando ad un piccolo progetto e sto cercando di renderlo il più possibile portabile da un sistema ad un'altro, o organizzato il tutto costruendo delle funzioni del tipo di questa...


int my_read(long file,char *buff,int lenbuf)
{
#ifdef WIN32
int lenr;
int s=ReadFile((HANDLE)file,buff,lenbuf,&lenr,0);
if(s!=0&&lenr==0)return FILE_EOF;
else return lenr;
#else
int s=fread(buff,lenbuf,1,(FILE *)file);
if (feof((FILE *)file))return FILE_EOF;
else return s;
#endif
}


il problema risale proprio dal fatto che io avrei potuto utilizzare sia fread e foef anche su windows ma se lo utilizzo mi viene idicata la fine di alcuni file prima del dovuto non vorrei che su linux succedesse la stessa cosa
ciao...

[Fenomeno85]

funziona uguale mi sa che hai sbagliato l'implementazione della funzione.

~§~ Sempre E Solo Lei ~§~

[cionci]

Prova una cosa del genere:

int my_read(int file,char *buff,int lenbufm int *eof)
{
int s=fread(buff,lenbuf,1,(FILE *)file);
*eof = feof((FILE *)file));
return s;
}

Se s è > 0 i dati ci sono ancora... Controlla il dato puntato da eof per verificare l'end of file... I file descriptor sono degli int...
In ogni caso se pensi alla portabilità è meglio usare fopen invece di open per aprire i file...a meno che non ti serve qualche opzione particolare di open...

[tglman]

Non mi sono spiegato bene... il mio problema è:
Quando leggo un file del tipo un immagine o un file mp3 la funzione feof mi dice che il file è finito prima della fine reale del file e sempre alla ricorrenza di un carattere, il problema su windows dovrebbe riguardare le librerie del compilatore le quali sono un pò vecchie e usano un'implementazione di fread errata in quanto esiste una versione di fread e feof che davano il file finito alla ricorrenza di un certo carattere, queste librerie vennero cotruite cosi perchè non era prevista la scrittura di file con tutti i caratteri ma solo di file con all'interno caratteri alfanumerici,
Dopo questo poema che ho scritto sopra vi chiedevo solamente può verificarsi che questo problema che o avuto con un compilatore di windows si ripeta anche con altri su linux o altri sistemi... Ciao

[/\/\@®¢Ø]

Originariamente inviato da tglman
Non mi sono spiegato bene... il mio problema è:
Quando leggo un file del tipo un immagine o un file mp3 la funzione feof mi dice che il file è finito prima della fine reale del file e sempre alla ricorrenza di un carattere
In Windows (e sui Mac) un file puo' venire aperto in modalita' testo o modalita' binaria. Se apri un file binario come un mp3 in modalita' testuale rischi di vederti troncare la lettura del file al primo carattere EOF.

[71104]

e pensare che qualcuno qui tempo fa sosteneva fermamente la grande portabilità del C e del C++, di gran lunga superiore a quella del Java!!! :D :rotfl:

[Fenomeno85]

Originariamente inviato da 71104
e pensare che qualcuno qui tempo fa sosteneva fermamente la grande portabilità del C e del C++, di gran lunga superiore a quella del Java!!! :D :rotfl:

ehm se non si usano funzioni paricolari vuoi mettere a confronto l'efficienza dei due linguaggi??

~§~ Sempre E Solo Lei ~§~

[cionci]

Originariamente inviato da 71104
e pensare che qualcuno qui tempo fa sosteneva fermamente la grande portabilità del C e del C++, di gran lunga superiore a quella del Java!!! :D :rotfl:
Ma queste sono bazzecole da risolvere per la portabilità del codice... E' chiaro che Java sia più portabile...è stato creato per questo...

[VICIUS]

Originariamente inviato da 71104
e pensare che qualcuno qui tempo fa sosteneva fermamente la grande portabilità del C e del C++, di gran lunga superiore a quella del Java!!! :D :rotfl:
Se ti riferisci alla nostra discussione nel thread di fenomeno85 allora dovresti rileggerti i miei messaggi perchè io non ho mai affermato questo e speravo che dopo 2 o 3 pagine di thread si fosse capito. :rolleyes:

ciao ;)

[71104]

Originariamente inviato da VICIUS
Se ti riferisci alla nostra discussione nel thread di fenomeno85 allora dovresti rileggerti i miei messaggi perchè io non ho mai affermato questo e speravo che dopo 2 o 3 pagine di thread si fosse capito. :rolleyes:

ciao ;)
pardon... :rolleyes:

[71104]

Originariamente inviato da Fenomeno85
ehm se non si usano funzioni paricolari vuoi mettere a confronto l'efficienza dei due linguaggi??
premesso che io AMO il C e che uso quasi esclusivamente quello (neanche il C++, solamente il C, spesso neanche il C99, ma solo ANSI C :)):
1) l'efficienza è praticamente pari perché (da quanto ne so, ma non credo di sbagliarmi) il Java non viene interpretato ed eseguito JIT, ma prima assemblato e poi eseguito, il tutto JIT dalla virtual machine
2) il Java è più portabile del C, anche se usi solo routines standard (molto difficile al giorno d'oggi) perché un programma C deve essere quantomeno ricompilato (e cmq stai tranquillo che in un programma serio l'#ifdef ci scappa sempre ;))
3) il vero vantaggio del C rispetto al Java non è tanto l'efficienza quanto la potenza; spesso per scegliere tra C e Java è necessario fare un paio di conti su questo piano: cosa è più importante per me, cos'è che devo mettere assolutamente in primo piano, la portabilità oppure la potenza (e magari anche l'efficienza)??? il mio programma è qualcosa di molto specifico per una particolare piattaforma, oppure voglio poterlo usare su qualsiasi piattaforma senza tante rotture di...?

[71104]

come conclusione aggiungo:
- il Java è ottimo per lo sviluppo di programmi multipiattaforma: il linguaggio è semplice e produttivo, i programmi Java possono essere eseguiti immediatamente su qualsiasi piattaforma supportata, e il corredo di classi a disposizione (implementate su qualsiasi piattaforma) è vastissimo, tanto da renderlo un linguaggio assai potente, ma mai comparabile (su questo punto di vista) con
- il C, che invece è qualcosa che assume forme diverse a seconda della piattaforma sul quale lo si usa, e perciò è più specifico, senza contare che un programma C per girare su diverse piattaforme deve essere ricompilato N volte, spesso con numerose condizionali, e spesso anche nonostante l'uso ESCLUSIVO di routines STL! infatti son pochi a saperlo, ma esistono sottili differenze tra le varie implementazioni esistenti di STL: si veda ad esempio la routine "stat", o "_stat", che dir si voglia: MSDN non documenta "stat", documenta solamente "_stat", anche se in realtà il MSVCRT le supporta entrambe...

[cionci]

Magari hai fatto l'esempio sbagliato...perchè stat non fa parte della standard library...almeno di quella dell'ANSI C ;) Tutte le funzioni e strutture supportate da MSVCRT con l'underscore davanti non sono standard, ma sono messe per compatibilità con altri SO...e per questo spesso sono supportate anche senza l'underscore...

[71104]

non stavo più parlando di ANSI C... :)

[cionci]

Originariamente inviato da 71104
non stavo più parlando di ANSI C... :)
Non sembrava...
Originariamente inviato da 71104
infatti son pochi a saperlo, ma esistono sottili differenze tra le varie implementazioni esistenti di STL: si veda ad esempio la routine "stat", o "_stat", che dir si voglia
stat non implementata nella standard C library ;)

[ilsensine]

Originariamente inviato da tglman
Quando leggo un file del tipo un immagine o un file mp3 la funzione feof mi dice che il file è finito prima della fine reale del file e sempre alla ricorrenza di un carattere
fopen(fname, "rb") (ANSI X3.159-1989)

[cionci]

Infatti mi sa che lui sta usando open...visto il passaggio del fd come int...

[ilsensine]

Originariamente inviato da cionci
Infatti mi sa che lui sta usando open...visto il passaggio del fd come int...
..."open" con "fread"? LOL :D

Già che me lo fai notare, c'è un possibile problema di portabilità con i sistemi a 64 bit nell'usare long in situazioni simili:
compilatori Microsoft: sizeof(long)==sizeof(int)
Compilatori GNU: sizeof(long)==sizeof(void *)

Non so se il tipo HANDLE sotto windows è un puntatore; se lo è, la frittata è pronta...

[tglman]

in windows tutti gli HANDLE e figli sono puntatori ed infatti ho sbagliato a scrivere long perchè mi sono confuso dal fatto che sizeof(int)==sizeof(long) su processori 32bit,comunque non so se ci sia qualche eccezzione ma il sizeof(int)==sizeof(void *) sempre perchè l'int dipende a punto dalla dimenzione dei registri del processore.
Ciao.

[ilsensine]

Devi solo fare attenzione se intendi portare il codice su processori a 64 bit, lì i compilatori possono interpretare long in maniera diversa.