Newsgroup: it.comp.lang.c
Titolo: file ex novo

In C si possono creare dei file Ex-novo? ossia: mettiamo che abbia fatto
un'elaborazione e voglia salvare il tutto su un file (che non esiste) di
testo. come si fa?



Devi usare le istruzioni fopen e fclose.
Le trovi in qualunque manuale o tutorial sul C.

 ha scritto nel messaggio
news:qsu18uoofuj5vo2s9...@4ax.com...


 dov controlla la possibilitàdi aprire  un file si dovrebbe inchiodare!
se sei su un*x: man fopen.
Se specifichi come secondo parametro "w" ( con le virgolette ed il file
non esiste, verrà creato con dimensione nulla, se invece gia' esiste,
verrà troncato a dimensione nulla ( perdi il suo contenuto ). Se vuoi
aggiungere qualcosa ad un file usi come secono paramentro "w+".
Bye, -_-

 controlla la possibilitàdi aprire  un file si dovrebbe inchiodare!
avendo dichiarato in precedenza:
FILE *ptr;
usi una selezione del tipo:
if ((ptr = fopen ("nomeFile", "w")) == NULL)
	printf ("Impossibile aprire il file\n");
-- 
Marco

	printf ("Impossibile aprire il file\n");
Il tuo esempio è sintatticamente ineccepibile, ma su alcune macchine
Winzozz non funziona (non è capitato solamente a me).
Per evitare che ptr assuma valori NULL anche quando non esiste motivo,
ho sperimentato che è meglio separare l'assegnazione dalla verifica
della condizione.
Più esplicitamente, è meglio dividere nel modo che segue:
ptr = fopen("nomeFile", w")
if(ptr == NULL)
	printf("Impossibile aprire il file\n");

 Winzozz non funziona (non è capitato solamente a me).
Su quali ? e con quale compilatore ?
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:pan.2002.03.02.19...@nowhere.net...


 che vuol dire :" se sei un *x:man fopen?
vuol dire che se usi un sitema operativo unix-like puoi accedere alle
pagine di documentazione delle funzioni standard del C utilizzando il
comando man, es. man fopen, man printf, man scanf ecc.
-- 
Marco

Su quali ? e con quale compilatore ?
Win98, in rete (all'università).
Compilatore cygnus o mingw, sotto Dev C++4.01
Borland Turbo C++ 3.1
Borland Turbo C++ 1.0
Il problema si è verificato su un numero di macchine non ben
identificato (non uso sempre lo stesso PC, e non mi metto a
controllare quale sia il numero della postazione ).
Vorrei inoltre osservare che tu stesso hai più volte osservato che non
cambia assolutamente nulla dal punto di vista del compilatore.
Non capisco quindi questa tua diffidenza, è seccante.
Credi forse che io sia il genere di persona che mente per portare
avanti la propria tesi con il passaparola? (un amico di mio cugino ha
sentito dire...)
Quoto un thread precedente di Kronos (che dovresti avere già letto), a
testimonianza del fatto che non si tratta di un caso isolato.
Da:Kronos (
kro...@nospam.kronoz.cjb.net
)
Message 6 in thread
Soggetto:Re: errori nell'aprire un file
Newsgroups:it.comp.lang.c
View this article only
Data:2002-01-31 09:50:17 PST
Ho avuto dei problemi simili con un vecchio TCC, ma solo WinNT.
Aprendo il
file cosi`:
if ((file = fopen(...)) == NULL)
Tutte le operazioni seguenti davano EOF.

 sentito dire...)
Uei, datti una calmata... innanzitutto dovresti sapere che,
in C, non c'e' alcuna differenza tra le due istruzioni (e
sottolineo ALCUNA).  Se pensi che separare le due istruzioni
sia meglio, IN ASSOLUTO, hai preso un granchio grande come
una casa.  Se un problema c'e' dipende strettamente dal 
compilatore utilizzato, il quale assume due comportamenti
diversi ed e', pertanto, assolutamente NON CONFORME allo
standard del linguaggio.  Il TC e' decisamente troppo
vecchio (l'1.0, poi, e' anteguerra) perche' possa essere 
preso ad esempio come un'alternativa allo sviluppo moderno, 
quindi quando rimarchi eventuali malfunzionamenti di un 
determinato codice su determinate macchine attuali, specifica 
sempre "con un compilatore vecchio come il cucco come il TC++" 
potrebbe non funzionare.


potrebbe non funzionare.
Io credo che nemmeno con quel compilatore ci siano differenze...
Non e' che semplicemente ci si e' dimenticati delle parentesi ?
Scrivere
   if ( ptr = fopen("pippo.txt","w") == NULL )
assegna a ptr il risultato del confronto con NULL, non il
risultato di fopen e questa assegnazione e' illegale (un
intero non e' un puntatore), ma alcuni compilatori C secondo
me un po' troppo fiduciosi generano solo un warning e non
un errore bloccante in questi casi e alcuni programmatori
un po' troppo pigri ignorano i warning... :-)
Andrea

Io credo che nemmeno con quel compilatore ci siano differenze...
Anche secondo me, d'altronde l'assegnazione in una
espressione booleana e' sempre stata supportata dal C e il
fatto che vi sia una funzione di apertura di un file non
cambia le cose...
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

 ha scritto nel messaggio
news:slrna84lpj....@igloo.northpole...


potrebbe non funzionare.
Passi per il Turbo C++, ma cosa mi dici del mingw e del cygnus?
Sono le versioni windows del gcc, e sono sufficientemente recenti da
suggerire che simili eccezioni non dovrebbero sussistere.
Oltretutto stiamo parlando di sintassi valide già per l'ansi C K&R,
non di C99 (che non conosco), quindi anche il TC++3.1 dovrebbe essere
più che compatibile.
Quando non sapevo più che pesci pigliare ho provato, colto dalla
disperazione, ad usarli tutti e quattro, ottenendo lo stesso identico
risultato (Dev C++ con i due compilatori gcc-like, TC++ 3.1  e TC++
1.0).
Usciva EOF fisso.

   if ( ptr = fopen("pippo.txt","w") == NULL )
E' stata la prima cosa cui ho pensato, ma le parentesi erano corrette.
Non era un problema di priorità degli operatori.

Non era un problema di priorità degli operatori.
E allora il programma funzionava. Oppure non funzionava
perche' sbagliavi da qualche altra parte (sconfinare da
un array un milione di istruzioni eseguite prima del
punto in cui chiami fopen() potrebbe benissimo provocare
il comportamento che descrivi).
Il problema del tuo approccio alla programmazione C
(basato su irrazionali formule magiche che funzionano
ma non si capisce perche') e' che ti permettera' di fare
ben poca strada.
Se non capisci perche' un programma funziona allora non
sarai certamente in grado di capire perche' *non*
funziona e inizierai a incolpare i compilatori, il
sistema operativo e, come ultima spiaggia, i compagni o
colleghi "portasfiga" (come se la sfiga centrasse).
Il codice "C"
   if  ((ptr = fopen("pippo","w")) == NULL)
   {
      ...
   }
   else
   {
      ...
   }
funziona, perche' e' un aggregato sensato di singole
parti che funzionano secondo una determinata logica:
l'operatore di assegnazione "=" e' un operatore come
gli altri, non uno statement e quindi puo' essere
usato nelle espressioni (con alcune limitazioni che
non staro' qui ad elencare).
Forse non e' bello stile... (ci sono linguaggi piu'
recenti che hanno abbandonato questa visione
dell'assegnazione come operatore di espressione)
ma in C e' corretto e funziona su tutti i compilatori
che hai citato.
Le motivazioni per cui tu pensi che non funziona sono
irrazionali e quindi evitero' di cercare di spiegarti
razionalmente perche' quel codice funziona (sarebbe
una perdita di tempo... tu continueresti a ripetere
"pero' a me quella volta li' non ha funzionato"...
cosa falsa ma indimostrabile visto che non ci porti
un esempio concreto e verificabile da tutti).
Dire che non funziona ha la stessa sensatezza che dire
che per compilare la versione definitiva di un programma
bisogna indossare mutande rosse perche' altrimenti e'
facile che i primi utenti perdano dei dati importanti.
Andrea

 suggerire che simili eccezioni non dovrebbero sussistere.
Peccato che questo problema lo stai sperimentando solo tu e 
pochi altri, il che non esclude che il problema sia vostro
e non del sistema o dei compilatori.  Io, ti ripeto, uso 
regolarmente il gcc e problemi di questo tipo non li ho MAI 
e risottolineo MAI avuti.


 sottolineo ALCUNA).
Se  ne  era gia`  parlato  ampiamente  (o  forse era  l'altro  Andrea?).
Succedeva anche a me con NT5sp6 + BCC3.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
La vispa candela bruciava l'erbetta
creando un'essenza alquanto sospetta;
sembrava l'odore di una sacrestia
ma presto mi accorsi che era maria.

 Succedeva anche a me con NT5sp6 + BCC3.
Ripeto: in C non c'e' alcuna differenza tra le due istruzioni,
sicuramente e' un bug del compilatore o delle istruzioni a 
seguire contenute nel codice.


Succedeva anche a me con NT5sp6 + BCC3.
Ma avete provato a rimuovere tutto il codice che non c'entrava nulla
con l'istruzione di apertura e la verifica che il file fosse aperto?
-- 
Marco Barisione (ICQ 84277092)

e risottolineo MAI avuti.
Buon per te... sono felice che tu viva in un mondo perfetto e
rigoroso, dove i compilatori non hanno bug, e il PC non fallisce
mai... dove tutti gli stati possibili di un processore pentium sono
già stati provati, e non c'è proprio nulla che possa sfuggire alla
comprensione.

Succedeva anche a me con NT5sp6 + BCC3.
No... era lui, ma evidentemente è più comodo dimenticare, e sostenere
che debba essere per forza un errore altrui.

seguire contenute nel codice.
Ripeto: i programmatori sono esseri umani, e i compilatori ed i
sistemi operativi possono contenere errori.
Di più essi possono commettere errori imprevedibili quando vengono
messi a contatto.
Sono manifestamente imperfetti.
La tua è una affermazione quasi religiosa. Sarebbe più ragionevole (ed
umile, che non guasta) sostenere semplicemente "non dovrebbe esserci
alcuna differenza...".

con l'istruzione di apertura e la verifica che il file fosse aperto?
Certo! :-)
La primissima cosa che ho provato quando ho notato che il punto
critico era proprio quella porzione č stato di far girare il programma
che segue:
#include <stdio.h>
#define PERCORSO "c:\\pippo.txt"
int main void
{
  file *miofile;
  if((miofile = fopen(PERCORSO, "r"))== NULL) /* *** ovviamente questa
č la riga incriminata *** */
  {
    printf("Impossibile aprire il file %s", PERCORSO);
    return 1;	/* errore */
  }
  fclose(miofile);
  return 0;	/* tutto bene */
}
Nessuna speranza... sempre e solo NULL.
E' strano ma č successo.
Il percorso era corretto, tant'č vero che la separazione ha
funzionato.

funziona
Stai parlando a vanvera. Io non ho accusato nessuno di qualche mio
errore. In quel caso specifico *neppure il mio insegnante* ha trovato
nulla che non andasse nel mio sorgente.
Conosco benissimo tutto ciò che mi hai tanto generosamente spiegato.
Perciò potevi benissimo risparmiarti una sparata del genere, visto che
(nell'ordine):
-1- non mi conosci;
-2- non mi hai mai visto programmare o debuggare qualcosa, quindi non
conosci il mio modo di lavorare, né conosci il mio approccio alla
programmazione in c, che *non è superstizioso*;
-3- dai per scontato che *io* abbia commesso un errore, mentre lo
stesso sorgente che all'università non funzionava, usando gli *stessi*
compilatori, ma con il mio PC di casa funzionava perfettamente
(spiegamelo tu allora... sto aspettando).
Non ho suggerito una formula magica o un rito vodoo... e stupisce
*moltissimo* anche me una stranezza del genere.
Semplicemente, dopo aver controllato e ricontrollato *tutti* i
puntatori, le parentesi, le priorità degli operatori e non ti dico
quante altre verifiche (rigorosamente con il debugger gnu del Dev
C++), ho provato a separare le singole istruzioni, poiché il
compilatore non distingueva le righe, ma le eseguiva come
un'istruzione unica.
Fatto questo... *sorpresa*! Ha funzionato tutto, e *senza alcun motivo
apparente*.
Se per te questa è superstizione o quant'altro, è un tuo limite, non
mio.
Lo standard è un'insieme di regole che servono a definire una
compatibilità minima tra i vari dialetti dei linguaggi, ma i
compilatori sono scritti da esseri umani *imperfetti*.
Vuoi forse dire che non può essere scappato un errore?
E ti sembra tanto illogico pensare al sistema operativo, visto che con
*gli stessi compilatori* ci sono due distinti comportamenti?
Rispondimi a queste domande.

mai...
Stai cominciando a stancarmi: ho gia' detto PER PRIMO
(rinfrescati la memoria) che il compilatore che hai usato
potrebbe avere dei bug, se produce due risultati diversi per
lo stesso codice, ma, se permetti, sospetto prima che sia il
tuo codice a non andare che non il compilatore e/o il
sistema operativo.


alcuna differenza...".
No, IN C *****NON C'E' ALCUNA DIFFERENZA***** e te lo grido
quante volte vuoi.  


  file *miofile;
   ^^^^
Che linguaggio e' ? 


che debba essere per forza un errore altrui.
Piu' comodo ??? e perche' dovrebbe essere piu' comodo ?
ROTFL... 


mio.
Veramente chi mi sembra piu' limitato sei tu.  E' molto piu'
intelligente indagare sui motivi dei fenomeni che ti
circondano che accettare le cose dicendo: mah... tutto ha
funzionato di nuovo, dopo aver fatto tre giri su me stesso
cantando Hare Krishna.


quante volte vuoi.  
Lo so benissimo.
E lo sa anche Kronos (tra l'altro ho erroneamente citato MOX in un
post precedente).
L'errore però si è verificato, quindi nella pratica può esservi
differenza, per quanto rara.
Fine della discussione, no?
Non mi pare che vi sia altro da dire, che ne pensi?

ROTFL... 
Per dire che non è mai successo.

Rispondimi a queste domande.
HTH
Andrea

 (spiegamelo tu allora... sto aspettando).
Più che altro mi viene in mente un test fesso fesso che probabilmente 
non hai fatto, che taglierebbe la testa al toro e ti farebbe capire DOVE 
sta il problema: anzichè compilare lo stesso programma su macchine 
diverse, prova ad eseguire il programma compilato sulla macchina sulla 
quale non funziona, sul tuo PC. Se neanche lì funziona, il problema sta 
nel compilatore, altrimenti nell'OS dell'uni (cosa che ritengo ALTAMENTE 
improbabile). Un'altra verifica da fare consisterebbe nel vedere se i 
due eseguibili sono realmente uguali... un'altra verifica da fare 
consiste nel disassemblare il codice eseguibile e vedere dove cavolo è 
che non funziona, e perchè.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
"Ogni cosa è vaga in una misura di cui non ci si rende conto finché non
  si cerca di renderla precisa"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 differenza, per quanto rara.
NO NO NO NO NO NO NO. CERCA DI FICCARTELO IN TESTA.
Sia in teoria che in pratica NON C'E' ALCUNA DIFFERENZA e mi
pare di avertelo dimostrato anche con degli stralci di
codice assembly generati dal Borland C++ Compiler.
Se proprio vuoi metterla in questi termini, diciamo che
nella pratica dei TUOI programmi puo' esserci differenza.


 Per dire che non è mai successo.
Io non dico che non e' mai successo, dico che sicuramente
non e' successo per i motivi che dici tu e siccome tu non
esponi alcun motivo, io sono libero di controbattere con
quello che voglio.  Il bello dei tuoi ragionamenti (parola
grossa) e' che tu non conosci i motivi per cui un fenomeno 
si verifica, ma conosci sicuramente la soluzione per non farlo 
piu' verificare.  
E' un'approccio alla risoluzione dei problemi alquanto strano 
e mi ricorda un po' gli stregoni dei villaggi dell'Africa nera.  
Spero per il tuo bene e per il bene di chi verra' in possesso 
di software scritto da te, in futuro, che, prima o poi, tu 
impari a capire *prima* il "perche'" dei problemi e *dopo* a 
studiarne la soluzione.  Aver trovato un bypass e pensare
che quel bypass sia la soluzione solo perche' ti ha riparato
il deretano ad un esame, non vuol dire che quel bypass sia
la soluzione del problema.


 con i tuoi occhi, e' ESATTAMENTE LO STESSO.
be', con la sua logica si potrebbe obiettare che allora e' il registro 
eax che non funziona ;)

 eax che non funziona ;)
Ma la cosa piu' bella e' che gcc produce, per le due versioni,
lo STESSO IDENTICO codice (non c'e' neanche il duetto eax ed ebx):
	.file	"fopen2.c"
	.section .text
LC0:
	.ascii "rt\0"
LC1:
	.ascii "\\frunlog.txt\0"
LC2:
	.ascii "errore nell'apertura del file\0"
	.p2align 4
.globl _main
_main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$168, %esp
	andl	$-16, %esp
	subl	$8, %esp
	pushl	$LC0
	pushl	$LC1
	call	_fopen
	addl	$16, %esp
	movl	%eax, -12(%ebp)
	cmpl	$0, -12(%ebp)
	jne	L2
	subl	$8, %esp
	pushl	$LC2
	pushl	$___dj_stderr
	call	_fprintf
	addl	$16, %esp
	movl	$1, %eax
	jmp	L1
	.p2align 4,,7
L2:
	subl	$4, %esp
	pushl	-12(%ebp)
	pushl	$128
	leal	-152(%ebp), %eax
	pushl	%eax
	call	_fgets
	addl	$16, %esp
	movl	$0, %eax
L1:
	movl	%ebp, %esp
	popl	%ebp
	ret
	.ident	"GCC: (GNU) 3.0.3"


Veramente chi mi sembra piu' limitato sei tu.
Io non ho fatto paragoni tra noi, e gradirei, come favore personale,
che tu non ne facessi, visto che non mi conosci.
Non ti sto sfidando a chi fa la pipì più lontano.
Non ho detto di essere meno limitato di te o superiore, posto che IMHO
*tutti* siamo più o meno limitati.
Sempre IMHHHO un tuo tuo limite è, in questo caso specifico, negare la
semplice evidenza, in favore di tesi più probabili e meno
problematiche.
Poi io posso sicuramente avere limiti maggiori... conoscenze
inadeguate... tutto quello che vuoi...
Secondo me l'accaduto si può riassumere come segue:
si è verificato un errore;
ho verificato che non era colpa mia;
ho trovato una singolare soluzione locale, che mi ha salvato il culo e
mi sono adattato di conseguenza;
a posteriori ho riprovato, e la patologia si è mantenuta (sempre
localmente, su *quella* stessa macchina ed alcune altre vicine, con la
stessa configurazione).
Il fatto si è verificato, ma tu neghi a priori, e preferisci pensare
ad un mio errore. E' un tuo rifiuto, e se non sei possibilista, mi
pare che la discussione perda ogni significato.
Io non ho mai detto di non essere interessato a conoscere il motivo
della stranezza, ma ho affermato di non esserne *attualmente* in
grado. Supera le mie capacità.
Ho tentato di formulare un'ipotesi basata su argomentazioni logiche,
giuste o sbagliate che fossero.
E' ben diverso.
Infine, per favore, non parlare di Hare Krishna, di magia ed altro. Ho
usato la magia come *metafora*, ma insisti a prendermi alla lettera.
Il sarcasmo gratuito non mi piace, quindi ti chiedo, sempre per
favore, di smetterla.

sistema operativo.
Mi va benissimo, ma dopo averti assicurato almeno cinque o sei volte
che il codice è corretto, e dopo averlo anche verificato per
sicurezza, mi aspetto che tu possa maturare un onesto dubbio, ed
iniziare a prendere per vere le mie parole, invece di continuare a
darmi addosso.

Che linguaggio e' ? 
A cosa ti riferisci? :-P ;-)

giuste o sbagliate che fossero.
Quale ***logica*** ?
Vuoi forse convincerci che hai spostato le istruzioni su due
righe in seguito a un ragionamento LOGICO ?
Se cosi' fosse, vorrebbe dire che hai capito il perche' del
problema e i tuoi neuroni hanno agito di conseguenza.
Viceversa, mi sembra che le tue sinapsi si siano arrestate
di fronte alla foto di San Programmatore, gridando "grazie !
ora funziona tutto per miracolo !".


che il codice è corretto
La tua assicurazione non mi basta: facci vedere il sorgente
assembly del codice con le due versioni.


HTH
Questa non è una risposta.
Spero io che la mia risposta ti aiuti a capirmi meglio ed a superare i
preconcetti.
HTH

eax che non funziona ;)
Non ci avevo pensato!
8-D

NO [cut...] CERCA DI FICCARTELO IN TESTA.
No.

quale non funziona, sul tuo PC. 
Boh... proverň domani, ma non vedo quale differenza dovrebbe esserci.
:-) 
Ma del resto questa č tutta una storia tanto strana...

la soluzione del problema.
Ma quale problema?
In tutto questo ti chiedo QUALE PROBLEMA?
Ho solamente raccontato un'esperienza cui *non credi*... pazienza!
Pazienza... non me ne puň fregar di meno, ad un certo punto... Sto
solamente dicendoti che č *accaduto*, a dispetto di tutto quello che
mi puoi portare come prove (disassemblati etc.). Non credermi...
d'accordo, ma piantiamola lě. Mettiamoci una pietra sopra.
Era solamente un problema locale, e non ne parlerň *MAI PIU'*, per
somma tua gioia.
Ti lascio la gioia dell'ultima parola... e ti prometto che non
risponderň ad eventuali reply a questo od altri msg (salvo offese
gratuite...), ma please, che sia l'ULTIMA!
Ne ho le palle davvero piene.

assembly del codice con le due versioni.
Proverò a farlo.

lettura delle risposte di Laforgia mostrano *a te* questo.
Non attribuire a me la sensazione di aura magica che
circonda i tuoi metodi di soluzione dei problemi.
Questa idea di te stesso la stai dando TU, non io.


No.
Rimani nella tua ostinata ignoranza del C, allora.
Mi spiace per te, davvero.


Ne ho le palle davvero piene.
Separale in due, vedrai, funziona.


	printf("Impossibile aprire il file\n");
[autoquoting OFF]
Ho raccontato un aneddoto personale, non l'ho presentato come una
soluzione universalmente valida.
Ho specificato che la cosa si verifica su alcune macchine windows, e
basta. Non ho mai detto che di avere la verità tra le mani, ma un caso
episodico.
Scrivevo spinto dal desiderio di fornire un'indicazione utile o
neutra, nella peggiore delle ipotesi, non di certo di ostacolare o di
imporre superstizioni.
Dal momento che nel peggiore dei casi la mia affermazione era
ininfluente (spero che ne converrai), non mi sono preoccupato troppo.
L'espressione "è meglio" era legata alla precedente "ho sperimentato"
e non andava presa in assoluto.

 ininfluente (spero che ne converrai), non mi sono preoccupato troppo.
Le affermazioni ininfluenti si fa meglio a non esprimerle, 
perche', in un contesto come quello sulla programmazione C,
possono condurre a fraintendimenti.  Un newbie ha potuto 
intendere che cio' che affermi fosse vero e cioe' che e'
effettivamente meglio separare il comando in due.
Tra l'altro, tu stesso ti ostini a non voler capire (
ribattendo con dei secchi e stupidi "No") che in C non c'e'
assolutamente alcuna differenza tra i due casi, ribatti 
dicendo che "nella pratica ci puo' essere" quando NON E'
ASSOLUTAMENTE VERO.  Ora, per cortesia, riprendi le tue
convinzioni sbagliate e mantieni le promesse fatte, come
quella di non continuare a postare.


quella di non continuare a postare.
Non posterò più su questo argomento, ma non ho la minima intenzione di
sparire solamente per soddisfare il tuo gusto estetico.
Se ti urto così tanto, killami.

sparire solamente per soddisfare il tuo gusto estetico.
A me basta che ci risparmi le idiozie.


A me basta che ci risparmi le idiozie.
Potevi evitare, ma lasciamo perdere.
Pace fatta dunque?