Hellihello

für mich stehen mittlerweile zwei Fragen eher abstrakter Art im Raum.

C reizt ja dazu, den Speicher, wenn man ihn schon selbst verwalten muss/kann, auch optimal zu nutzen. Bei so einer String-Action ist für mich nicht klar, wie sowas optimal zu lösen ist. Schon beim Einlesen mit fgets Zeilenweise wird ja Speicher belegt. In Zeilenlänge. Da ich beim CSV bestenfalls nur die Kommas in '\0' umzuwandeln muss, könnte ich ja die Zeile so lassen, die Kommas durch Nullen ersetzen und Stringpointer für die einzelnen Zellen auf diesen Zeilenspeicher setzen. Ist es aber möglich, den beim Einlesen durch fgets automatisch reservierten Speicher per malloc persistent zu machen. Oder denk ich da was falsch. Muss man immer ein Kopie davon irgendwo anlegen? Und weiter, ist es besser, den Zelleninhalt einzeln zu allokieren, oder besser eine größeres Stück in einem (Zeile fortlaufend, darin die Zellen). Platzmäßig ist das ja wohl egal. Eher eine Fragmentierungsfrage. Oder aber ist es am Besten, gleich die komplette Größe der einzulesenden CSV-Datei zu ermitteln und soviel en-bloc im Arbeitsspeicher zu definieren?

Da es keine Objekte/Strukturen mit Methoden gibt, in denen dann per "this" oder "self" auf Klassen/Strukturvariablen zugreifen kann, muss man das zu bearbeitende Objekt ja immer per Speicheradressenangabe rumreichen. Entweder man lässt sich eine Speicheradresse zurückgeben, oder man übergibt eine,  deren Inhalt mit der Funktion dann manipuliert wird. Sind denn größere Projekte damit dann objektorientierungslike genauso übersichtlich realisierbar. Relativ abstrakt gesehen sind Klassen ja zum Teil "nur" Namensräume innerhalb derer dann interne "globale" Variablen definierbar sind. Diese Strukturierungsmöglichkeit fehlt ja bei C. Mit der Funktionsbenennung lässt sich da vermutlich noch ein Teil strukturieren. Ist also ObjectivC oder C++ dann die Folge, oder gibt es Gründe, bei C zu bleiben?

Dank und Gruß,

frankx

Hello,

einen Zeiger auf ein Array kann ich nicht returnen?

Doch kannst Du. Aber Du musst dafür sorgen, dass das Array nach dem Ende der Funktion auch noch da ist. Das schrieb ich Dir schon in https://forum.selfhtml.org/?t=177894&m=1172341

Wie funktioniert das mit dem Funktionsaufruf?

Auf dem Stack wird Platz reserviert für

• Rückgabewert (Anzahl der Bytes nach Typ, denn der eigentliche Wert ist ja noch nicht bekannt)
• Aufrufparameter
• Register
• Return (far)-Befehl  mit Anzahl der Bytes die später wieder entfernt werden müssen

Dann wird die Kontrolle (BP) an den Funktionskörper übergeben.

Wenn Du nun innerhalb dieser Funktion weitere Variablen aufmachst, werden die ebenfalls auf den Stack draufgepackt. Wenn die Funktion endet, wird der Stack wieder bereinigt, oder genauer gesagt, der Stackpointer wieder auf den Wert vor dem Funktionsaufruf zurückgesetzt. Dein Array liegt zwar nun noch auf dem Stack, aber außerhalb des referenzierten Bereiches, also im nächsten Moment vermutlich schon innerhalb des Arbeitsbreiches der nächsten aufgerufenen Funktion.

Nur der Rückgabewert, und das war ja nur ein Zeiger auf das Array, bleibt der Parent-Funktion auf dem Stack solange erhalten, bis sie ihn abgeholt hat.

Wenn Du nun über diesen Zeiger auf das Array zugrifen willst, greifst Du in den Stack hinein, an eine Stelle, von der Du nicht weißt, welchem Programmteil dieser inzwischen zugeordnet ist.

Daher musst Du Dir den Speicher mit malloc() oder  mit new oser sonstigen Methoden auf dem Heap beschaffen. Dort bleibt er solange für den zeiger erhalten, bis er mit delete, dispose, free oder wie der Rückgabebefehl sonst auch immer heißt, wieder freigegeben wird. Deshalb darf dir der Zeiger auf den allokierten Speicher auch nicht verloren gehen, weil dieser gleichzeitig der Key für den Eintrag in der Speicherverwaltung ist. Diese weiß, wieviel Speicher zu welchem Zeiger allokiert wurde.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

Hallo,

*
* Seiteneffekt: Speicher auf dem Heap wird allokiert
*/
int SplitLinesCsv(char* line, char** result) {

warum "char* line" und nicht "char *line"?

Reine Geschmackssache, für den Compiler ergibt sich kein Unterschied.
Meine Variable heißt line und hat den Typ "Zeiger auf char". Sie ist nicht vom Datentyp char und heißt *line. Für *mich* ist meine Notation verständlicher und lesbarer.

auf "char"?

Wie werden denn in "C" Variablen per Referenz übergeben? Müssen sie vorher global definiert sein.

Nein, natürlich nicht, wieso auch? Für globale Variablen gilt (sprachunabhängig): So wenige wie möglich, nur so viele, wie unbedingt notwendig. In vielen Fällen kommt man ohne globale Variablen aus.

C verwendet call by value. Willst Du den Inhalt einer "übergebenen" Variablen ändern, so übergibst Du eben einen Zeiger auf den Speicher, in dem diese Variable steht, d.h. die (Speicher)adresse dieser Variablen.

Typisches Beispiel für so einen Zweck ist eine Tauschfunktion:

  
/**  
 * tausche  
 * tauscht den Inhalt der beiden übergebenen Variablen  
 *  
 * @param a: Zeiger auf die erste Zahl  
 * @param b: Zeiger auf die zweite Zahl  
 * Anmerkung: C kann maximal einen Wert zurückgeben,  
 * es müssen aber zwei Variablen geändert werden. Daher erfolgt der  
 * Aufruf über call by reference, indem Zeiger auf die Variablen übergeben  
 * werden.  
 *  
 * Code ungetestet, vermutlich wie vor etwa 20 Jahren mal in der ersten oder  
 * zweiten Woche der C-Programmierung gelernt ...  
 */  
void tausche(int* a, int* b) {  
    // wir benötigen einen Zwischenspeicher  
    int merker;  
    // schreibe den Inhalt der Variablen a in den Zwischenspeicher  
    merker = *inhalt;   // schreibe in merker das, auf was inhalt zeigt.  
    // schreibe in den Speicher, auf den a zeigt, das was dort steht, worauf  
    // b zeigt  
    *a = *b;  
    // schreibe nun an die Stelle, auf die b zeigt, das Zwischengespeicherte.  
    *b = merker;  
}  
  
// Aufruf:  
  
// auf argc und argv verzichte ich einfach mal ...  
int main(void) {  
    int x = 4;  
    int y = 17;  
  
    // übergebe der Tauschfunktion die Adressen der zu tauschenden Variablen  
    tausche(&x, &y);  
  
    // gebe die beiden aus ...  
    printf("x = %d, y = %d \n", x, y);  
    // Ausgabe:  
    // x = 17, y = 4  
}  

Wenn Du nun bei Deinem CSV-Kram von vornherein einen Puffer anlegst:

// Wir reservieren Platz für maximal 20 Spalten. Jeder Eintrag darf maximal
// 1024 Zeichen Nutzinhalt haben (plus ein Zeichen für das Nullbyte, das die
// Zeichenkette beendet)
char csv[20][1024+1];

Wenn Du so den Speicher vorbereitest, brauchst Du keinen Speicher dynamisch anzufordern (und wieder freizugeben), dafür hast Du etwas mehr als 20 Kilobyte verbraten und bist unflexibel, weil Du nicht mehr als 20 Spalten verarbeiten kannst und kein einziger Eintrag mehr als ein Kilobyte Nutzdaten enthalten darf (sonst kommt es ruckzuck zu einem buffer overflow, wenn Du nicht aufpasst) ...

Dagegen hat die dynamische Speicherverwaltung den Nachteil, dass *nichts und niemand* Dir die Arbeit abnimmt, den von Dir angeforderten Speicher wieder freizugeben. Da kommt es gern einmal zu Speicherlecks, d.h. die Anwendung fordert immer wieder (meist kleine) Speichermengen an, die nicht mehr freigegeben werden, obwohl sie nicht mehr verwendet werden. Viel schlimmer, Du hast wahrscheinlich keinen Zeiger mehr auf diesen Speicher und kannst ihn daher auch nicht mehr freigeben. Das erfolgt erst mit Beendigung des Programmes.

Freundliche Grüße

Vinzenz

Hallo,

bitte prüfe, ob die Präprozessor-Makros nicht schon definiert sind:

if not defined SEPARATOR ','

#define SEPARATOR ','

//reset Pointer
line -= totalStringSize+1;

merktest Du Dir den Anfang, dann müsstest Du ihn nicht wieder ermitteln.

printf ("alloziere Speicher für %d Zeiger auf Strings\n", seperatorCount);
stringlist[0] = (char*)malloc(seperatorCount*sizeof(int));

Viel Glück: Wenn Du Speicher für "Zeiger auf int" reservieren willst, dann solltest Du nicht die Größe von int, sondern die Größe von Zeiger auf int angeben. Mit etwas Glück sind beide gleich groß (32 Bit z.B.) Außerdem möchtest Du Dir eigentlich Zeiger auf char reservieren.

// Leerzeichen helfen Anweisungen zu strukturieren:
stringlist = (char*) malloc(seperatorCount * sizeof(char*));

für den Rest habe ich momentan keine Zeit, erst am späten Abend wieder ...

Freundliche Grüße

Vinzenz

Hallo,

ist 'ne Menge Code so auf einmal ...

while (*line++ != '\0') {
  if (*line == SEPARATOR)
   seperatorCount++;
}

Diese Vergleichsoperation ist umständlicher als nötig.
Eine Prüfung eines Wertes auf nicht-null ist genau das, was die if-Anweisung sowieso tut. Außerdem ist es IMHO für die Lesbarkeit des Quellcodes ungünstig, '\0' zu schreiben, wo es eine einfache 0 genauso täte. Insgesamt also:

while (*line++) {

//reset Pointer
line -= totalStringSize+1;
printf("Pointerreset Test, inputline: %s\n", line);

Das sieht korrekt aus, nachdem du ja vorher die Stringlänge bestimmt hast; trotzdem habe ich bei dieser Operation ein ungutes Gefühl.

stringlist[0] = (char*)malloc(seperatorCount*sizeof(int));

Abgesehen davon, dass der Typecast (char*) den Ausdruck für den Leser unnötig verkompliziert: FEHLERQUELLE! Auf 32bit-Intel-kompatiblen Systemen geht das gut. Es ist aber nicht auf allen Systemen sizeof(int)==sizeof(*).

Aber was noch viel schlimmer ist: Du reservierst hier nicht Speicher für stringlist, sondern für stringlist[0]! Das sollte aber schon der Zeiger auf den ersten String sein. Anhand der Logik deiner Funktion gehe ich davon aus, dass stringlist beim Aufruf undefiniert sein darf - du greifst aber schon auf das erste Element zu, auf das dieser undefinierte Zeiger zufällig verweist. Das dürfte dein entscheidender Fehler sein.

// Ermittle die Teilzeichenketten
int stringBufferCounter = 0;
char stringBuffer[totalStringSize];
int stringlistCounter = 0;

Es ist schlechter Stil, mitten in der Funktion neue Variablen einzuführen. Das ist eine Schlamperei, die mit C++ erst aufgekommen ist; bei einem reinen C-Compiler ergibt das eine Fehlermeldung. Variablen müssen immer am Anfang eines Blocks deklariert werden.

// Allokiere für jede Teilzeichenkette den notwendigen Speicher
while (*line != '\0') {

Siehe oben.

else {
   stringBuffer[stringBufferCounter++] = '\0';

Auch hier: Warum '\0' und nicht 0? Schließlich ist C von Haus aus schon in manchen Punkten umständlich, man muss es ja nicht noch übertreiben. :-)

printf("gepuffert wurde %s\n", stringBuffer);
   printf("alloziere %d*%d Speicher für stringlist[%d]\n", stringBufferCounter, sizeof(char), stringlistCounter);
   stringlist[stringlistCounter]=(char*)malloc(stringBufferCounter*sizeof(char));

Hier ist die Indizierung richtig.

printf("setze stringlist[%d]\n", stringlistCounter);
   stringlist[stringlistCounter]=stringBuffer;

Hier nicht. Du überschreibst den Zeiger auf den eben reservierten Speicherblock wieder mit dem Zeiger auf deinen lokalen (und damit temporären) Speicherplatz stringBuffer.
An dieser Stelle willst du vermutlich strcpy() oder eine der Varianten davon einsetzen.

stringBuffer[1] = '\0';

Was will mir die Konstante 1 hier sagen?

"stringlist[stringlistCounter]=(char*)malloc(stringBufferCounter*sizeof(char));"
soll eigentlich jedem Element des String-Arrays einen weiteren freien Speicher zuordnen. Das ist aber immer die selbe Adresse.

Aber nur, weil du die von malloc() gelieferte Adresse gleich wieder überschreibst.

Wie man sieht, bleibt der Pointer "hängen". Was mach ich falsch? Ich dachte schon, ich blick durch, aber jetzt kurz vor Schluss den Wald vor lauter Bäumen nicht.

Es sind meistens nur Kleinigkeiten ...

Übrigens: In Zeile 58 "stringBuffer[1] = '\0'"; hatte ich zum Testen gesetzt, um die Ausgabe in Main nachvollziehen zu können (

Ach so. Mich hat's jetzt verwirrt.

So long,
 Martin