C Programmierung, Datei anlegen

ITSE · 16. Mai 2003

Zitat

Original geschrieben von !ND
alles was du in der string.h findest ist nicht sicher in der hinsicht. es reicht einen string ohne abschließenden ascii 0 zu übergeben und das ding liest/schreibt munter bis zum ende des adressraumes... wenns vorher nicht abstürzt

auch wenn man unbedingt wissen sollte wie c-standard strings funktionieren: imho sind sie total veraltet. heute gibts dafür klassen.

hi.... naja. schliesslich gehts hier um plain old C.... da gibt es halt keine Klassen....

XlF42 · 17. Mai 2003

Hi,

Zitat

Original geschrieben von DirkP
Grad eben bin ich auf den Befehl strcat gestoßen, der mir mein Problem gelöst hat.
Geht es auch anders?
strcat soll nicht sicher sein in hinsicht auf Buffer Overflow.

Sicher vor BufferOverflows waerest Du mit dynamischer Allozierung:

Code

char *path = "/wo/hin/auch/immer";
 char *name = "wieauch.immer";
 /*  complete = path + "/" + name + zero-termination */
 char *complete = (char*)malloc (strlen(path) + strlen(name) + 2);
 
  if (complete != NULL) {
     strcpy (complete, path);
     strcat (complete, "/");
     strcat (complete, name);
  }


  .....


  free (complete);

Alles anzeigen

was mir noch eingefallen ist:
- anstatt strcpy + 2xstrcat waere in diesem Fall auch sprintf sicher
- fopen ist in ansi so spezifiziert, betriebssystem-unabhaengig mit "/" als verzeichnistrenner zu verarbeiten, man kann also unbesorgt auch unter windows verzeichnisnamen mit "C:/bla/fasel/laber/suelz.txt" benutzen.

cu
XlF

DirkP · 19. Mai 2003

XlF42: Danke. Probiere ich aus.

stadolf · 21. Mai 2003

Code

char buffer[255];
const char *filename = "foo.bar";


//UNIX
sprintf(buffer, "/home/dirkp/%s", filename);


//Win32
sprintf(buffer, "C:\\folder\\dirkp\\%s", filename);


//fileio mit buffer als Dateiname
//...

Alles anzeigen

ist die Methode, die ich für sowas in ANSI-C am ehesten wählen würde. Dynamische Alloziierung sollte man so weit es geht in (unmanaged ) C vermeiden. Es ist besonders für Umsteiger manchmal schwierig, sich an die Vermeidung von new-Operatoren zu gewöhnen (esp. Java-Hansels wie mich...), aber es geht ! Es lebe der Stack.

Diese ganze String-Kopiererei ist übrigens vorsintflutlich (sofern man sich nicht wirklich auf ANSI-C Ebene ohne STL bewegt). Mit der STL wird alles viel einfacher und bleibt zum Glück in den meisten Fällen plattformunabhängig (SunOS / Solaris mal ausgenommen ). Stichwort: strstream, string

XlF42 · 21. Mai 2003

Hi,

Zitat

Original geschrieben von stadolf

ist die Methode, die ich für sowas in ANSI-C am ehesten wählen würde. Dynamische Alloziierung sollte man so weit es geht in (unmanaged ) C vermeiden. Es ist besonders für Umsteiger manchmal schwierig, sich an die Vermeidung von new-Operatoren zu gewöhnen (esp. Java-Hansels wie mich...), aber es geht ! Es lebe der Stack.

Ein wenig Beschaeftigung mit dynamischen Speicher schadet ueberhaupt nicht, wenn man C (und auch C++) koennen will. Beim ernsthaften Einsatz der Sprachen kommt man um pointer-jonglieren eh nicht herum (und kann vieles deutlich effizienter machen als mit STL, insbesondere wenn es noetig wird).

Zitat

Diese ganze String-Kopiererei ist übrigens vorsintflutlich (sofern man sich nicht wirklich auf ANSI-C Ebene ohne STL bewegt). Mit der STL wird alles viel einfacher und bleibt zum Glück in den meisten Fällen plattformunabhängig (SunOS / Solaris mal ausgenommen ). Stichwort: strstream, string

Aber es gibt Dinge, wo Du als "unbedarfter" nicht darauf achtest, zB ein konstrukt wie

Code

{
string str;
   ...
   for (<schleife mit VIELEN durchlaeufen>) {
      str += <irgendwas>;
   }
}

und dich dann wunderst, warum sich eine quadratische Ordnung fuer die Laufzeit ergibt (vor dem Problem stand ich schonmal).
Wenn Du Dich schonmal mit dem (hundserbaermlichen) String-handling der C-Welt beschaeftigt hast, ist das schnell offensichtlich.

cu
XlF

stadolf · 21. Mai 2003

dazu fällt mir ein Spruch ein:

first make it run, then make it work.

Optimierung ist ja ne feine Sache, aber die Laufzeitprobleme, die beim einmaligen Erzeugen einer Datei mit der STL auftreten würden, sind mehr als vernachlässigbar.

Ich arbeite seit über 5 Jahren nach oben genannten Spruch. Mit geeigneten Profiling-Methoden (zB auch einfache Timer-Abfragen mit Logging) kann man später immer noch herausfinden, wo die Flaschenhälse sind. Bei XIFs Schliefe mit <VIELEN> Durchläufen ist es offensichtlich, dass da die STL Geschwindigkeitsprobleme machen wird. Ein Refactoring auf ANSI-C Zeichenketten sollte aber meistens machbar sein in diesem Fall.

wg. dynamischer Alloziierung: natürlich ist einer der erheblichen Vorteile von C-Derivaten die explizite Nutzung von Zeigern inkl. Zeigerarithmetik, etc. Aber man neigt als Ein- / Umsteiger / Unerfahrener oft dazu, alle Objekte dynamisch zu alloziieren. Ich denke, man kann viele Speicherlecks und Arbeit sparen, wenn man Objekte wo möglich auf dem Stack erzeugt und seine Methodensignaturen mit Referenzübergabe versieht:

Code

void MyFunc(MyObject & object)
{
  object.DoSth();
}


MyObject obj;
MyFunc(obj);


/// -- anstatt von


void MyFunc (MyObject *object)
{
  object->DoSth();
}


MyObject *obj = new MyObject;
MyFunc(obj);
delete obj;

Alles anzeigen

Weiterer Vorteil: Alleine durch die Referenz in der Signatur kommt der Entwickler der MyFunc-Funktion garantiert nicht auf den Gedanken object löschen zu wollen oder sowas (alles schonmal erlebt...)

C Programmierung, Datei anlegen

Jetzt mitmachen!

Teilen