C- dateipointer mit fopen
bleicher
- programmiertechnik
0 Christoph0 bleicher0 Christoph0 Der Martin0 bleicher
0 Christoph
Grüße,
wie immer schlauche ich so gern ;)
was mich verrückt macht -
FILE* datei;
(...)
datei=fopen(eigenpfad,"r");
es liefert wie erwartet NULL wenn die Datei nicht existiert, aber "BadPtr" wenn die Datei da ist - mit "a+" genauso - die Datei wird angelegt, aber "datei" bleibt "schlechtes pointer". ich habe in der referenz geblättert aber keine Lösung gefunden ;(
"eigenpfad" stimmt auch - die Datei wird wie erwartet in dem Verzeichnis angelegt, bzw nullpointer erzeugt wenn die nicht existiert - das Problem entsteht nur, wenn die Textdatei unter dem Pfad angelegt wird ;(
MFG
bleicher
Moin.
es liefert wie erwartet NULL wenn die Datei nicht existiert, aber "BadPtr" wenn die Datei da ist [...]
Was bitte ist ein 'BadPtr'? Was sagen dir printf("%i\n", ferror(datei))
und perror(NULL)
?
Christoph
Grüße,
Was bitte ist ein 'BadPtr'? Was sagen dir
printf("%i\n", ferror(datei))
undperror(NULL)
?
0 und No error respektive
problem aber gelöst - es hilft, die variable "datei" am anfang der main() zu deklarieren - zwischendrin in der funktion führt es zu seltsamen reaktionen - zeiger verhielt sich wie "null" - datei==NULL war "false" - aber mit dem zeiger ies sich auch nichts anstellen - weder datei auslesen noch schreiben.
ist aber gelöst.
was ich mich frage - MS VIsualStudion zeigt da öfters seltsames verhalten - teilweise werden fehler durch löschen von leerzeilen "gelöst" - ist es normal?
MFG
bleicher
Moin.
was ich mich frage - MS VIsualStudion zeigt da öfters seltsames verhalten - teilweise werden fehler durch löschen von leerzeilen "gelöst" - ist es normal?
Ich arbeite mit MinGW und nicht mit VS, aber normal sollte das nicht sein. Ohne Quelltext (vor- und nach Beheben des Fehlers) kann man jedoch schlecht beurteilen, wer da Mist gebaut has (du oder Microsoft).
Christoph
Hallo,
es hilft, die variable "datei" am anfang der main() zu deklarieren - zwischendrin in der funktion führt es zu seltsamen reaktionen
ja, wenn du eine Variable "zwischendrin" deklarierst, gilt sie nur in dem durch {} begrenzten Block, in dem sie deklariert ist. Von außerhalb dieses Blocks dürfte sie dann aber nicht einmal "sichtbar" sein.
zeiger verhielt sich wie "null" - datei==NULL war "false" - aber mit dem zeiger ies sich auch nichts anstellen - weder datei auslesen noch schreiben.
Sehr merkwürdig, in der Tat. Ich kann mir gut vorstellen, dass das eine Eigenheit von MSVS ist, aber sicher bin ich mir nicht.
So long,
Martin
Grüße,
ja, wenn du eine Variable "zwischendrin" deklarierst, gilt sie nur in dem durch {} begrenzten Block, in dem sie deklariert ist. Von außerhalb dieses Blocks dürfte sie dann aber nicht einmal "sichtbar" sein.
hey - soweit verstehe ich die ganze sache schon -
ich meine - innerhalb einer funktion - wenn ich die variablen direkt am anfang deklariere, ist es ok, aber mitten im rumpf - führt es zu problemen.
main(){
int a;
}
ist demnach ok - aber
main(){
...
(paar zeilen code und ausgabe)
...
int a;
}
führt zu seltsamen verhaltensformen.
MFG
bleicher
main(){
int a;
}ist demnach ok - aber
main(){
...
(paar zeilen code und ausgabe)
...
int a;
}führt zu seltsamen verhaltensformen.
MFG
bleicher
Kannst Du dazu mal ein vollständiges (ggf. gekürztes)
Beispiel posten, das compiliert werden kann?
Andernfalls fällt es sehr schwer, nachzuvollziehen,
welche Verhaltensformen seltsam sind ... ;-)
Viele Grüße
Andreas
Grüße,
Kannst Du dazu mal ein vollständiges (ggf. gekürztes)
Beispiel posten, das compiliert werden kann?
Andernfalls fällt es sehr schwer, nachzuvollziehen,
welche Verhaltensformen seltsam sind ... ;-)
Posten ja - aber das ist nicht zwingend hilfreich - ich habe es gelöst - und selbst wenn ich den code in die alte form bringe - ist dieses verhalten nicht garantiert. diese fehler treten nicht ganz so leicht reproduzierbar auf.
wobei ich nicht der einzige bin der damit zu kämpfen hat - habe noch von ca einem dutzend anderer im kurs gehört, dass MS VStudio Express 2005 auf variablen die nicht am anfang des funktionsrumpfes deklariert wurden allergisch reagiert.
inklusive "critical error" ohne fehlercode u.ä. -allesamt nicht reproduzierbar, diese fehler treten tatsächlich nur auf "diesem rechner" mit "diesem code" auf. kleinste änderung kann die beseitigen - insofern kann ich mich höchstens dummstellen wenn ich allerlei code poste - nichtreproduzierbarkeit ist gewährlieistet ;/
MFG
bleicher
Posten ja - aber das ist nicht zwingend hilfreich - ich habe es gelöst - und selbst wenn ich den code in die alte form bringe - ist dieses verhalten nicht garantiert. diese fehler treten nicht ganz so leicht reproduzierbar auf.
So ist es: Die Fehler sind (scheinbar) nicht reproduzierbar und
können zahlreiche, teils sehr unerwartete Ursachen haben.
Genau deswegen wäre es hilfreich, wenn Du ein konkretes, ggf. reduziertes
Code-Beispiel hier der Allgemeinheit präsentieren würdest, anstatt
Kaffeesatz-Leserei zu betreiben.
wobei ich nicht der einzige bin der damit zu kämpfen hat - habe noch von ca einem dutzend anderer im kurs gehört, dass MS VStudio Express 2005 auf variablen die nicht am anfang des funktionsrumpfes deklariert wurden allergisch reagiert.
Das ist es, was ich unter Kaffeesatz-Leserei verstehe...
Viele Grüße
Andreas
Grüße,
ok hier ein ausschnitt, wie er in MSVS2008 nicht funktionieren wollte, bis man ein neues project mit exact gleichem cod edrin anlegte (ctrl-c/ctrl-v versteht sich)
#include<stdio.h>
struct club{
int num;
char name[20];
};
int main(void){
club a;
return 0;
}
an der stelle "club a" beschwerte sich coimpiler über "nicht deklarierter bezeichner" , wie gesagt - bis ein neues project angelegt wurde. ist es normal?
MFG
bleicher
Moin.
an der stelle "club a" beschwerte sich coimpiler über "nicht deklarierter bezeichner" , wie gesagt - bis ein neues project angelegt wurde. ist es normal?
Die Fehlermeldung ist berechtigt: Korrekt wäre struct club a
- in C liegen zusammengesetze Typen in verschiedenen Namensräumen, d.h. struct foo
ist etwas anderes als union foo
.
Möchtest du die kurze Schreibweise nutzen, benötigst du ein zusätzliches typedef
, z.B.
typedef struct {
int num;
char name[20];
} club;
was eine Zusammenfassung von
struct club {
int num;
char name[20];
};
typedef struct club club;
darstellt.
Dass neue Projekte ohne Fehler kompilieren ist entweder ein Bug oder liegt an irgendwelchen Einstellungen, die sich zwischen den Projekten unterscheiden (Kompilieren als C++?).
Christoph
Nochmal ich:
Ich hatte noch die URL einer netten Übersicht über die Unterschiede zwischen C und C++ als Lesezeichen rumfliegen, nebst passenden Eintrag:
Christoph
an der stelle "club a" beschwerte sich coimpiler über "nicht deklarierter bezeichner" , wie gesagt - bis ein neues project angelegt wurde. ist es normal?
Das kann ich hier auch mit anderen Compilern, wie z. B. dem gcc / g++
nachvollziehen:
~/tmp$ cat beispiel.c
#include<stdio.h>
struct club{
int num;
char name[20];
};
int main(void){
club a;
return 0;
}
~/tmp$ gcc beispiel.c
beispiel.c: In function ‘main’:
beispiel.c:9: error: ‘club’ undeclared (first use in this function)
beispiel.c:9: error: (Each undeclared identifier is reported only once
beispiel.c:9: error: for each function it appears in.)
beispiel.c:9: error: expected ‘;’ before ‘a’
~/tmp$ g++ beispiel.c
~/tmp$
Der C++ - Compiler nimmt es, der C-Compiler nicht. Schreibt
man vor die Zeile 'club a;' ein 'struct', funktioniert es
in beiden Compilern.
MfG
Andreas
Grüße,
Der C++ - Compiler nimmt es, der C-Compiler nicht. Schreibt
man vor die Zeile 'club a;' ein 'struct', funktioniert es
in beiden Compilern.
danke - habe ich nicht gewusst^^
aber sollte VisualStudio2008 nicht c++ unterstützen? und vor allem - soll das bedeuten, die c/c++ unterstützung wird beim projectanlegen sporadisch gewählt?
MFG
bleicher
Moin.
problem aber gelöst - es hilft, die variable "datei" am anfang der main() zu deklarieren - zwischendrin in der funktion führt es zu seltsamen reaktionen [...]
Das freie Mischen von Deklarationen und Code ist erst in C99 möglich, in C89 müssen Variablen zu Beginn eines Blockes, d.h. vor anderweitigen Anweisungen, deklariert werden.
Die C99-Unterstützung des MS-Compilers ist dem Hörensagen nach quasi nicht-existent, d.h. das könnte tatsächlich die Fehlerquelle sein. Was mich allerdings wundert, ist, dass der Compiler keine entsprechende Fehlermeldung oder Warnung ausgibt...
Christoph