Wie ihr euch Frust, Zeit & beschädigte Einrichtungsgegstände sparen könnt

Servus.
Also, ich gebe hier jetzt mal zwei grundlegende Programmiertipps, die dermaßen logisch klingen, jedoch bei mir immer zu Problem führen (vgl. Titel, gerade eben schon wieder*):

1. Wenn ihr euch dynamischen Speicher holt, dann fügt auch SOFORT IMMER den Befehl zum Freigeben von diesem in euer Programm ein.
2. Wenn ihr ein Feld vergrößert, MÜSST ihr auch die Routine mitverändern, die das Feld initialisiert (Feldgrenzen!).

Gruß, Florian

* Ich mach einen Testlauf für mein Programm (das mogen 100% korrekt funktionieren muss): SIGSEGV.
Ich wäre gerade eben fast durchgedreht :ugly:
Dann ist mir aufgefallen (nach 1.5 h) das die SChleife, die eine Feld initialisiert falsch war (es wurden nicht alle Elemente initialisiert). Arg!

Ein Tipp, wie man sich sowas ganz erspart:

1. Eine Sprache mit Garbage Collection benutzen.

SCNR

fs111

x86-Assembler + Boehm-GC ;-)

zum finden solcher probleme hilft

valgrind --tool=memcheck --num-callers=958282 --leak-check=yes --show-reachable=yes -v binary

http://valgrind.kde.org/

Zitat:

---

Zitat von florian hanisch

...
2. Wenn ihr ein Feld vergrößert, MÜSST ihr auch die Routine mitverändern, die das Feld initialisiert (Feldgrenzen!).
...

---

Dafür sorgt man, in dem man Felder (Arrays und sonstiges Geraffel) grundsätzlich über vordefinierte Konstanten initialisiert und Größen von structs usw. z. B. per sizeof abfragt:

Code:

---

/* C */
#define ARR_SIZE 16
...
char arr[ARR_SIZE];
struct t_st {
  int x;
  char y;
  float z;
} st;
...
memset(arr, 0, sizeof arr);
memset(st, 0, sizeof(struct t_st));

int i;
for (i = 0; i < ARR_SIZE; i++)
    arr[i] = '0' + i;
...

---

Code:

---

// Java
private static final int ARR_SIZE = 16;
...
String[] arr = new String[ARR_SIZE];
for (int i = 0; i < ARR_SIZE; i++)
    arr[i] = "" + i;

---

Jan

Zitat:

---

1. Eine Sprache mit Garbage Collection benutzen.

---

Steinigt Ihn ! :eek:
Ich mag schon selber bestimmen koennen, wann und wie mein speicher wieder freigegeben wird ... und MT sicherheit dann noch einhalten wird sicher nicht leichter :-)

ALternativ halt c++ und seine moeglichkeiten nutzen anstatt c oder c style in c++ verwenden ...
vectoren statt arrays, autoptr fuer quellen und senken

Ciao ...

Aber jetzt mal im Ernst: Programme werden immer grösser und komplexer. Was hast du da lieber: Etwas nicht freigegebener Speicher, den der GBC später freigibt oder bei jedem Durchlauf ein Speicherleck, das dir dann irgendwann das ganze RAM zumüllt?

Ich meine: Klar kannst du die schnellsten Programme mit Assembler schreiben - nur wer macht das heute noch? (Ausnahmen bestätigen wie immer die Regel - es gibt sicherlich Beispiele, bei denen du die "lasche" Art des GBC nicht verkraftest...)

MfG Bischi

Zitat:

---

Zitat von bischi

Aber jetzt mal im Ernst: Programme werden immer grösser und komplexer. Was hast du da lieber: Etwas nicht freigegebener Speicher, den der GBC später freigibt oder bei jedem Durchlauf ein Speicherleck, das dir dann irgendwann das ganze RAM zumüllt?...

---

Sehe ich auch so. Warum soll man dem Computer nicht überlassen, was er (meist) besser kann als die Fehlerquelle 80 cm vor dem Bildschirm? Garbage Collection ist eine rein mechanische Zählerei (wieviele Referenzen auf dieses Objekt gibt es noch?), sowas ist öde, langweilig und fehlerträchtig - und zählen kann ein Rechner i. a. besser als ich.

Jan

Zitat:

---

Aber jetzt mal im Ernst: Programme werden immer grösser und komplexer. Was hast du da lieber: Etwas nicht freigegebener Speicher, den der GBC später freigibt oder bei jedem Durchlauf ein Speicherleck, das dir dann irgendwann das ganze RAM zumüllt?

---

Wenn man von anfang an aufpasst , das das zeug freigegeben wird ? Also wenn man sich bei der erzeugung gleich wieder gedanken ueber die zerstoerung macht ? Damit laesst sich das Problem IMHO gut haendeln ... Modulare programmierweisse, damit die projekte ned unuebersichtlich werden tun ihr uebriges ....

OK, ich nutz gern und oft multithreading, da sind cow und gc soweieso kritisch zu betrachten. die machen dann meist mehr aufwand als wie sie nutzen bringen. Deshalb hab ich lieber einfachere Typen wo ich immer weiss, welchen status was grad hat ....

Und GC in der Art wie JAVA sie verwendet, sind eher auch augenwischerei .... ob die GCs den SPeicher am Ende des Prozesses legetim wieder freigeben, oder ob die ordnungsgemaess implementierte c /c++ runtime bei proezessende die memoryleaks anmeckert und dann doch wieder freigibt, iss meist ned so der unterschied in der Praxis.

Also wir ham hier Parser zu laufen, einige in c++ und mit xerces, und paar in java mit der xerces java impl (glaub ich zumindest), also die machen das selbe, nur wenn ich mir die verbreuchten ressourcen waehrend dem c++ parsen und dem java parsen anschaue (der laufzeitunterschied iss gar ned mal so gross) dann sind mir die ressourcen doch so viel wert das ich lieber auf GC's verzichte :-) Ob die Java Coder da nu richtige arbeit gemacht haben, kann ich leider ned beurteilen.
Aber bei 15 GB xml file parsen, kann ich beim c++ parser nebenbei bequem browsen auf unseren Messrechnern, bei der java engine wird das browsen zur qual ....

Ach ja, und es gibt eben nicht nur Desktop rechner ... sondern momentan "im kommen" sind auch kleine handliche geraete, wo eher auf stromverbrauch, temperaturfestigkeit als auf leistung und spreicher geachtet wird.

Ciao ...

Zitat:

---

Zitat von RHBaum

...Und GC in der Art wie JAVA sie verwendet, sind eher auch augenwischerei .... ob die GCs den SPeicher am Ende des Prozesses legetim wieder freigeben, oder ob die ordnungsgemaess implementierte c /c++ runtime bei proezessende die memoryleaks anmeckert und dann doch wieder freigibt, iss meist ned so der unterschied in der Praxis....

---

Der GC von Java gibt mitnichten Objekte nur am Prozessende wieder frei. Wie kommst Du darauf, dass das Augenwischerei ist? Er räumt nur den Speicher erst dann auf, wenn er meint, Zeit dazu zu haben - darum geht es bei GC aber nicht nur - es geht auch darum, dass jemand überwacht, welche Objekte ich wann und wo noch brauche (wenn ich z. B. Objekte an andere Objekte übergebe, die diese wiederum intern weiterführen usw. - wenn ich da jedesmal das Objekt kopiere, sehe ich noch schneller alt aus mit Speicherverbrauch).

Und wenn Du meinst, dass es keinen Unterschied mache, wann Speicher freigegeben wird, dann hast Du wohl noch nie langlaufende Prozesse programmiert (Dienste / Dämons, ...)

Zitat:

---

...Also wir ham hier Parser zu laufen, einige in c++ und mit xerces, und paar in java mit der xerces java impl (glaub ich zumindest), also die machen das selbe, nur wenn ich mir die verbreuchten ressourcen waehrend dem c++ parsen und dem java parsen anschaue (der laufzeitunterschied iss gar ned mal so gross) dann sind mir die ressourcen doch so viel wert das ich lieber auf GC's verzichte :-) Ob die Java Coder da nu richtige arbeit gemacht haben, kann ich leider ned beurteilen.
Aber bei 15 GB xml file parsen, kann ich beim c++ parser nebenbei bequem browsen auf unseren Messrechnern, bei der java engine wird das browsen zur qual ....

---

Das ist dann wohl eher das Problem der falschen Parsing-Methode als der Programmierumgebung. Nutzt Du DOM? Schau Dich mal im Web um mit den Stichworten "xerces" und "big xml file". Mit DOM versucht nämlich Xerces, die ganze Struktur auf einmal in den Speicher zu kriegen.

Zitat:

---

Ach ja, und es gibt eben nicht nur Desktop rechner ... sondern momentan "im kommen" sind auch kleine handliche geraete, wo eher auf stromverbrauch, temperaturfestigkeit als auf leistung und spreicher geachtet wird.

Ciao ...

---

Ja und? Dann brauchst Du keine saubere GC?

Jan