morly
19.09.2013, 19:56
Hi Leute,
warum so ein langes Post? Tja: möchte mal einen kleinen Einblick ins Programmieren geben und was die beteiligten Leute hier so treiben...
Zur Erklärung - das klingt alles so leicht: "kann das mal wer fixen" - "noch immer der Fehler" - "..."
Unsere Images werden mit 2 Programmiersprachen realisiert, Python und C++. C bzw. C++ ist meiner Meinung nach eine der besten Programmiersprachen die es gibt, allerdings keine triviale Geschichte.
Zum Beispiel ist hier der Programmierer alleine fürs komplette Speichermanagement verantwortlich. Speicher den ich anfordere (wird im sog. Heap abgelegt) wird dort reserviert und nicht mehr freigegeben - dafür bin ich selber verantwortlich. Viele programmieren voller Elan darauf los, wenn alles funktioniert sind alle happy - nur vergessen viele den angeforderten Speicher wieder freizugeben. Für alle die sich etwas auskennen:
Type *myVar;
myVar = new Type;
myVar = 0;
Also: hier wird ein Pointer mit dem Typ Type angelegt und mit der zweiten Zeile (new) Speicher (im Heap) reserviert. Nur den Zeiger auf Null setzen (3. Zeile) gibt den Speicher nicht frei, da fehlt folgendes:
delete myVar;
Also: Code funktioniert, nur der Speicher wird nicht freigegeben - je öfter sowas passiert, desto weniger Speicher ist vorhanden - und das delete kann man leicht mal vergessen. Was haben wir hier: ein sog. Speicherloch ("Memory Leak"). Dieser Fehler findet sich fast überall (auch bei komm. Software).
Darum haben andere Programmiersprachen auch die sog. "Garbage Collection" (Java, C#, ...). Da genügt es wie im ersten Beispiel den Zeiger auf 0 zu setzen oder noch einfacher, dass die Variable die Gültigkeit verliert (Unterprogramm zu Ende, ...). Der "Garbage Collector" erkennt das von selber und gibt den Speicher frei... Aber das benötigt natürlich CPU Resources (ist also langsamer) - darum verzichtet C++ darauf.
Tja - aber unsere Images sind nunmal in C bzw. C++ geschrieben und glaubt mir, da fehlen so einige "delete" ;)
Nun zum nächsten Punkt: wenn ihr etwas programmieren könnt und ich geb euch ne Aufgabe ist das wie das Lösen eines Rätsels - man arbeitet sich heran bis alles wie gefordert funktioniert. Viele vergessen den Code zu dokumentieren, also Kommentare hinzuzufügen, es geht ja eh alles. Und wenn man seinen eigenen (!!) Code ca. 4-6 Woche später wieder sieht weiss man nicht mehr was man geschrieben hat. Man benötigt auch für kleine Programme ne Weile wieder zu verstehen was man da so fabriziert hat. Sourcecode ist immer anders, auch für die selbe Aufgabe und vom selben Programmierer.
Jetzt machen wir das ganze noch schwieriger: ihr schreibt ein kleines C++ Programm und gebt es einen anderen - der soll es verstehen/Debuggen/Fehler finden. Das ist wirklich schwer und selbst für kleine Programme bedarf es grosser Übung. Wenn einer gut programmieren kann heisst es noch lange nicht das er auch gut Sources lesen kann - auch das muss man üben. Und gerade C bzw. C++ ist bekannt dafür extrem effizienten code zu schreiben - aber diese Dinger sind extrem schwer zu lesen. So wurde die Lösung des 8-Damen-Problems in 3 Anweisungen programmiert - irre!
So - und jetzt zu unseren Images: hier verstecken sich vieeeeeeeele C++ Files mit dazugehörigen Header Files - tausende und abertausende "Lines of Code" von vieeeeeelen verschiedenen Entwicklern. Zusätzlich noch Python Sources - die arbeiten natürlich zusammen. Jeder fixt etwas, dadurch entsteht was anderes, es wird was erneuert, altes bleibt bestehen, ... Seiteneffekte ohne Ende. Da muss man erst mal ansatzweise verstehen was die Programmierer alles so gemeint haben - dokumentiert ist ja auch nichts - das wird dann richtig komplex!!
Ich will nicht irgendwie den schlauen Michl mimen - aber mal einen kleinen Einblick bieten was die Leute hier machen. Und da sind mal schnell 100 Stunden vorbei ohne das man gross weiter ist. Ihr seht schon - das geht etwas weiter als ein Modellauto zu kleben oder sonstiges (nichts gegen Modellbau - ist spitze!). Kurzum, hier sind viele Leute beteiligt die in der IT-Branche richtig Geld machen könnten - die leisten super Arbeit.
Ich weiss auch, dass es niemand böse meint mit "blöder Tunerbug noch himmer nicht gefixt" oder so, aber vielleicht helfen die angeführten Zeilen einem "Nicht-Programmierer" etwas die Komplexität und Schwierigkeit zu verstehen.
Also dann,
bravo wer so weit gekommen ist und dieses riesige Post gelesen hat :)
wir fighten weiter und versuchen natürlich weiter Fehler auszubügeln und Neuerungen zu implementieren.
Happy Coding,
morly
warum so ein langes Post? Tja: möchte mal einen kleinen Einblick ins Programmieren geben und was die beteiligten Leute hier so treiben...
Zur Erklärung - das klingt alles so leicht: "kann das mal wer fixen" - "noch immer der Fehler" - "..."
Unsere Images werden mit 2 Programmiersprachen realisiert, Python und C++. C bzw. C++ ist meiner Meinung nach eine der besten Programmiersprachen die es gibt, allerdings keine triviale Geschichte.
Zum Beispiel ist hier der Programmierer alleine fürs komplette Speichermanagement verantwortlich. Speicher den ich anfordere (wird im sog. Heap abgelegt) wird dort reserviert und nicht mehr freigegeben - dafür bin ich selber verantwortlich. Viele programmieren voller Elan darauf los, wenn alles funktioniert sind alle happy - nur vergessen viele den angeforderten Speicher wieder freizugeben. Für alle die sich etwas auskennen:
Type *myVar;
myVar = new Type;
myVar = 0;
Also: hier wird ein Pointer mit dem Typ Type angelegt und mit der zweiten Zeile (new) Speicher (im Heap) reserviert. Nur den Zeiger auf Null setzen (3. Zeile) gibt den Speicher nicht frei, da fehlt folgendes:
delete myVar;
Also: Code funktioniert, nur der Speicher wird nicht freigegeben - je öfter sowas passiert, desto weniger Speicher ist vorhanden - und das delete kann man leicht mal vergessen. Was haben wir hier: ein sog. Speicherloch ("Memory Leak"). Dieser Fehler findet sich fast überall (auch bei komm. Software).
Darum haben andere Programmiersprachen auch die sog. "Garbage Collection" (Java, C#, ...). Da genügt es wie im ersten Beispiel den Zeiger auf 0 zu setzen oder noch einfacher, dass die Variable die Gültigkeit verliert (Unterprogramm zu Ende, ...). Der "Garbage Collector" erkennt das von selber und gibt den Speicher frei... Aber das benötigt natürlich CPU Resources (ist also langsamer) - darum verzichtet C++ darauf.
Tja - aber unsere Images sind nunmal in C bzw. C++ geschrieben und glaubt mir, da fehlen so einige "delete" ;)
Nun zum nächsten Punkt: wenn ihr etwas programmieren könnt und ich geb euch ne Aufgabe ist das wie das Lösen eines Rätsels - man arbeitet sich heran bis alles wie gefordert funktioniert. Viele vergessen den Code zu dokumentieren, also Kommentare hinzuzufügen, es geht ja eh alles. Und wenn man seinen eigenen (!!) Code ca. 4-6 Woche später wieder sieht weiss man nicht mehr was man geschrieben hat. Man benötigt auch für kleine Programme ne Weile wieder zu verstehen was man da so fabriziert hat. Sourcecode ist immer anders, auch für die selbe Aufgabe und vom selben Programmierer.
Jetzt machen wir das ganze noch schwieriger: ihr schreibt ein kleines C++ Programm und gebt es einen anderen - der soll es verstehen/Debuggen/Fehler finden. Das ist wirklich schwer und selbst für kleine Programme bedarf es grosser Übung. Wenn einer gut programmieren kann heisst es noch lange nicht das er auch gut Sources lesen kann - auch das muss man üben. Und gerade C bzw. C++ ist bekannt dafür extrem effizienten code zu schreiben - aber diese Dinger sind extrem schwer zu lesen. So wurde die Lösung des 8-Damen-Problems in 3 Anweisungen programmiert - irre!
So - und jetzt zu unseren Images: hier verstecken sich vieeeeeeeele C++ Files mit dazugehörigen Header Files - tausende und abertausende "Lines of Code" von vieeeeeelen verschiedenen Entwicklern. Zusätzlich noch Python Sources - die arbeiten natürlich zusammen. Jeder fixt etwas, dadurch entsteht was anderes, es wird was erneuert, altes bleibt bestehen, ... Seiteneffekte ohne Ende. Da muss man erst mal ansatzweise verstehen was die Programmierer alles so gemeint haben - dokumentiert ist ja auch nichts - das wird dann richtig komplex!!
Ich will nicht irgendwie den schlauen Michl mimen - aber mal einen kleinen Einblick bieten was die Leute hier machen. Und da sind mal schnell 100 Stunden vorbei ohne das man gross weiter ist. Ihr seht schon - das geht etwas weiter als ein Modellauto zu kleben oder sonstiges (nichts gegen Modellbau - ist spitze!). Kurzum, hier sind viele Leute beteiligt die in der IT-Branche richtig Geld machen könnten - die leisten super Arbeit.
Ich weiss auch, dass es niemand böse meint mit "blöder Tunerbug noch himmer nicht gefixt" oder so, aber vielleicht helfen die angeführten Zeilen einem "Nicht-Programmierer" etwas die Komplexität und Schwierigkeit zu verstehen.
Also dann,
bravo wer so weit gekommen ist und dieses riesige Post gelesen hat :)
wir fighten weiter und versuchen natürlich weiter Fehler auszubügeln und Neuerungen zu implementieren.
Happy Coding,
morly