Virtuelles File System in C schreiben

Hmm ich dachte, dass ich einen c-Compiler hätte...wie finde ich das denn raus? Arbeite mit Visual Studio 2010 Express

C_Mond schrieb:

Hmm ich dachte, dass ich einen c-Compiler hätte...wie finde ich das denn raus? Arbeite mit Visual Studio 2010 Express

Ich programmiere nicht unter Windows, deshalb kann ich dir nicht sagen, welche Einstellungen du vornehmen musst um mit dem integrierten Windows Compiler wirklich natives C zu compilieren.

Ich würde da MinGW als Compiler empfehlen. Das ist der GCC Compiler auf Windows. Entweder du kompilierst da per Konsole und Makefiles, oder falls dir das zu schwer ist, nehm statt Visual Studio die Code::Blocks IDE. Auf der Seite gibt es einen Installer wo MinGW schon integriert ist. http://www.codeblocks.org/

Lg

Wutz

Mit __cplusplus kann man herausfinden, ob ein C oder C++ Compiler aktiv ist.

#ifdef __cplusplus
#error C++ Modus
#else
#error C Modus
#endif

C_Mond schrieb:

int *p;

p = malloc(sizeof(int));
Das "=" wird immer rot unterstrichen und ich bekomme den Hinweis, dass malloc den Rückgabetyp void hat und es deswegen nicht zugeordnet werden kann

Weil Microsoft zu faul ist, im VisualStudio für C ein eigenes Intellisense zu spendieren und somit auch für reinen C Code das C++ Intellisense verwendet.

hustbaer

Mechanics schrieb:

databasa schrieb:

Mechanics schrieb:

Was willst du denn überhaupt schreiben? Ein richtiges "Dateisystem", also einen Treiber, der dein Dateisystem dann allen Programmen zur Verfügung stellt (z.B. wie True Crypt) oder eine Containerdatei, auf die nur dein Programm zugreifen direkt kann?

Wo ist der Unterschied?

Das ist ein gewaltiger Unterschied. Es gibt keine "Containerdateien", die ein Betriebssystem von Haus aus mounten könnte, schon gar nicht Windows.

Bei Windows 7 SP1 gibt's den "Windows Image File System Filter Driver" (muss man allerdings dazuinstallieren). Der kann WIM Files mounten. Und WIM Files sind Container-Files, keine File-System Images. (Man kann ja keine Partition im WIM Format formatieren, und WIM ist auch kein einfaches Block-Mapping Format wie sparse VHD Files o.ä.)

Wobei man natürlich streiten kann ob man den "Windows Image File System Filter Driver" jetzt zum OS rechnet oder nicht.

hustbaer

Wutz schrieb:

Weil Microsoft zu faul ist, im VisualSudio für C ein eigenes Intellisense zu spendieren und somit auch für reinen C Code das C++ Intellisense verwendet.

Alter Schwede, bin ich froh' dass ich nie in C programmiere! Ich glaube ich würde Amok laufen wenn ich so arbeiten müsste.
(OK, würd ich nicht, ich würd anfangen lauter unnötige Casts zu schreiben, was aber fast genau so schlimm ist.)

LordXearo

Tag zusammen,

bin an der gleichen Aufgabe dran. Leider bin ich auch kein Profi was C angeht, drum hoffe ich auf etwas Unterstützung.

Ich reserviere mir auch den Speicher für den Dateipfad:

Store = (char malloc(strlen(argv[i])+6);

und hänge am ende mit strcat das ".store" an den Pfad dran.

Mit einem abschließenden "free(Store)" knallt es dann natürlich.

Ich dachte mir durch die "+6" hab ich mir genug Speicher für den Pfad und die Endung reserviert. Könnte mich da jemand aufklären?

Desweiteren, beim einlesen einer ganzen Zeile steh ich noch was auf dem Schlauch.
Wenn ich nun eine Datei habe, die sich über zich Tausend oder mehr Blöcken erstreckt, benötige ich auch Millionen oder mehr Zeichen um eine ganze Zeile einzulesen:

while(fgets(Buffer,10000000,Struct) != NULL){

Da ist dann auch irgendwann mal ende. Danach Zerteile ich den Buffer mit strtok.
Hat jemand eine Idee wie ich es machen muss, wenn eine Zeile noch größer ist?

Viele Grüße

Xearo

LordXearo schrieb:

Ich dachte mir durch die "+6" hab ich mir genug Speicher für den Pfad und die Endung reserviert. Könnte mich da jemand aufklären?

Xearo

Nein, das ist nicht genug, du brauchst noch ein Platz für den 0-Terminator.

LordXearo

Autsch...ja klar. So oft gelesen und trotzdem macht man es manchmal falsch.

Nun scheint es zu klappen, bekomme jedenfalls keinen Fehler mehr beimAufruf von "free()".

Noch eine Frage...

Ich habe Zeilen mit unterschiedlichen längen. Ich würde diese dann wiederverwenden bzw. überschreiben. Wenn die neue Zeile länger als die alte Zeile ist, überschreibt mir das Programm natürlich noch die nächste Zeile mit.

Gibt es da eine Möglichkeit das zu ändern, OHNE, eine weitere Datei anzulegen?

LordXearo

Schon wieder ein Problem beim freigeben vom Speicher. Diesmal kann ich mir keinen reim drauf machen.

Ich reserviere mir erstmal Speicher

uint64_t *Anzahl = (uint64_t *) malloc (sizeof(uint64_t) );

Später wird der Speicherplatz immer um 1 erhöht.

realloc(Anzahl ,( (AnzDateien) * sizeof(uint64_t) ) );

Während der Speicherplatz erhöhrt wird, werden auch die Stellen beschrieben.

Anzahl[AnzDateien-1] = _strtoi64(TeilString,NULL,10);

Wenn ich mit der Verarbeitung (die korrekt ausgeführt wird) fertig bin, möchte ich den Speicher freigeben free(), womit mir das Programm abschmiert.

Ich kann mir das nicht erklären.

LordXearo

Hab es doch geschafft.

Hab mir den Befehl "realloc" wohl von einer schlechten Quelle angeschaut.

Nun sieht es so aus:

Anzal = (uint64_t *) realloc(Anzahl,( (AnzDateien) * sizeof(uint64_t) ) );

Ist das eigentlich C Konform?
Bzw. ist das so sinnvoll oder mache ich es unnötig schwer?

SeppJ

LordXearo schrieb:

Hab mir den Befehl "realloc" wohl von einer schlechten Quelle angeschaut.

Dann sei sicher, dass du nur gute Quellen benutzt. Bekannt schlechte Quellen sind leider die meisten (original) deutschsprachigen Bücher und ganz allgemein Internettutorials.

Nun sieht es so aus:
Anzal = (uint64_t *) realloc(Anzahl,( (AnzDateien) * sizeof(uint64_t) ) );
Ist das eigentlich C Konform?

Streng genommen: Ja.

Bzw. ist das so sinnvoll oder mache ich es unnötig schwer?

Da ist vieles dran schlecht:
-Rechtschreibung
-unnötiger Cast
-sizeof mit festem Typ
-keine Behandlung eines fehlgeschlagenen reallocs

Die ersten drei korrigiert:

Anzahl = realloc(Anzahl, AnzDateien * sizeof(*Anzahl));

Der letzte Punkt ist subtiler aber wichtig. Schlägt realloc fehl, so wird 0 zurück gegeben. Aber worauf Anzahl zeigt wird nicht freigegeben! In diesem Fall wäre der Wert des Zeigers Anzahl mit 0 überschrieben und der ursprünglich referenzierte Speicher unwiederbringlich verloren. Ganz schlecht.

Eine oberflächliche Behandlung des Problems wäre ein temporärer Zwischenwert:

uint64_t* temp = realloc(Anzahl, AnzDateien * sizeof(*Anzahl));
if (temp)
  Anzahl = temp;
else
  Fehlerbehandlung;

Das ist äußerst unschön und auch temporäre Zwischenwerte sind oft ein Zeichen von ungünstiger Programmierung. Schöner wäre eine Abkapselung der gesamten Speicherverwaltung. Ist aber im Moment wohl noch ein zu fortgeschrittener Themenkomplex für dich.

LordXearo

Danke für deine Hilfe Seppj.

ich mache noch eine Fehlerbehandlung, ich prüfe ob der Speicher reserviert werden konnte.

if ( Speicher == NULL) ...

Wenn ich das (uint_64t vor malloc oder realloc weglasse, mekert visual studio.
Freu mich schon wenn ich soweit bin, das ganze auch in gcc zum laufen zu bekommen....

Sorry bin gerad kurz angebunden.
Erstmal danke.

SeppJ

LordXearo schrieb:

Wenn ich das (uint_64t vor malloc oder realloc weglasse, mekert visual studio.

Wenn du meinst, es gäbe eine Fehlermeldung bei der Übersetzung, dann benutzt du einen C++-Compiler. Tu das nicht.

Wenn du meinst, dass deine IDE meinst, das wäre falsch, dann liegt das da dran, dass VS eine IDE für C++ ist und der Hersteller ihm keinen Modus für C spendiert hat. Da kann man nichts machen, außer es zu ignorieren, da man es besser weiß oder kein VS für C zu benutzen.

Hallo, auch ich bin an der gleichen Aufgabe dran und habe ein ähnliches Problem.

Das mit dem malloc funktioniert bei mir aber das Problem ist wie bekomme ich es hin, den Pfad aufzuteilen?
Also in 2 Pfade, damir ich sie dann einzeln ergänzen kann?

Also wenn ich zB jetzt in Java wäre:

pfad1 = pfad
pfad2 = pfad

store = pfad1 + store
structure = pfad2 + structure

oder so in der Art

SeppJ schrieb:

Wenn du meinst, dass deine IDE meinst, das wäre falsch, dann liegt das da dran, dass VS eine IDE für C++ ist und der Hersteller ihm keinen Modus für C spendiert hat.

Das stimmt so nicht.

Visual Studio unterstützt zumindest C89, die Dateien müssen dafür aber die Endung .c haben (oder man stellt die Kompilierung explizit auf C um).

TagBoz schrieb:

aber das Problem ist wie bekomme ich es hin, den Pfad aufzuteilen?

Schau dir mal die C-Stringverarbeitungsfunktionen an.

LordXearo

TagBoz schrieb:

Also wenn ich zB jetzt in Java wäre:

pfad1 = pfad
pfad2 = pfad

store = pfad1 + store
structure = pfad2 + structure

oder so in der Art

Hol dir den Speicher mit malloc für beide Pfade.
Dann den Pfad mit strcpy in den reservierten Speicher schreiben.
Als letztes noch mit strcat die Dateiendungen hinzufügen.

Ich schau mal, wie ich VS 2012 auf C umstellen kann.

Wutz

Unter Projekteigenschaften / C/C++ / Komplilierungsart = "/TC".

LordXearo

Das ist ja grauenvoll....dann wird es im C98 standard kompiliert, d.h. sowas

for(int i; ... ) ist nicht mehr gültig...

Un wenn ich den Typcast bei malloc weglasse mekert er trotzdem.....

Hilft wohl nichts als das Programm nochmal separat für gcc zu bearbeiten.

SeppJ

C'ler schrieb:

SeppJ schrieb:

Wenn du meinst, dass deine IDE meinst, das wäre falsch, dann liegt das da dran, dass VS eine IDE für C++ ist und der Hersteller ihm keinen Modus für C spendiert hat.

Das stimmt so nicht.

Visual Studio unterstützt zumindest C89, die Dateien müssen dafür aber die Endung .c haben (oder man stellt die Kompilierung explizit auf C um).

Ich weiß, dass der Compiler C89 kann, das habe ich doch im Satz davor gesagt. Ich meinte, dass der Editor Sachen als falsch ankringelt, die in C richtig sind, in C++ aber falsch.

Da ich VS nicht benutze kann ich beides nur weitergeben aus anderen Quellen, aber ich vertraue den häufigen Beschwerden im Forum darüber eher als dieser einen einzigen Meldung des Gegenteils, von der ich mal annehme, dass du dich auf den Compiler bezogen hast.