Warum so häufig malloc
-
Ein Nachteil an statischen Array's ist, das die Größe eines Array's immer durch den Worst-Case Szenario festgelegt wird, s.d. der Speicherverbrauch im Best-Case der Speicherverbrauch im Wort-Case ist. Bei dynamischen Array's ist dies nicht der Fall; jedoch benötigen diese einen Verwaltungsaufwand.
Bsp:
typedef struct { double x; double y; double z; char Comment[80]; } tPoint; typedef struct { tPoint Points[1000]; size_t Size; } tPolygon; typedef struct { tPolygon Polygons[1000]; size_t Size; } tPolygonArray;Ein tPolygonArray belegt bei mir satte 104.008.008 Bytes, wobei die Grenzen definitiv nicht groß sind. Auf kleinen, schwachen Rechnern hast du da ein Problem, denn diese cirka 100 MByte pro PolygonArray belegst du immer! Die kannst du nicht mehr auf den Stack schieben, sondern die must du global legen.
Dynamische Datenstrukturen sind ohne malloc() schwer zu realisieren.
-
Also 2 verschiedene Welten sind das nicht wirklich - auch in Cobol kann man in Funktionen auslagern, die hier halt perform heißen. Man kann das sogar im Assembler mit balr und br. Die Sprache ist eigentlich nur ein Syntaxproblem.
Ich habe jetzt von PL/1, Cobol, Assembler, Rexx, Abap, C , bash-Scripting so einiges in den letzten 30 Jahren durch und das Hautproblem ist nicht die Sprache, sondern der Weg ein Problem so zu lösen, dass man nach über 6 Monaten noch weiss, warum man was gemacht hat. Im Endeffekt wird eh - außer bei interpretierten Sprachen - alles Assembler.
-
pferdefreund schrieb:
Also 2 verschiedene Welten sind das nicht wirklich - auch in Cobol kann man in Funktionen auslagern, die hier halt perform heißen.
Du hast aber bei performs auf Paragrafen/Sections keine lokalen Variablen.
Und wenn ich mich richtig erinnere, habe ich mal auf einem IBM-Mainframe versucht, eine Section rekursiv zu performen, auch das hat glaube ich nicht funktioniert.Das in C oder C++ einfach zu lösende Problem:
Gib eine beliebige Anzahl an Buchstaben ein, berechne alle möglichen Wörter und gib sie aus, habe ich in COBOL nicht hingekriegt, weil mir die Rekursion fehlte, mal abgesehen davon, dass man nicht beliebig viele Buchstaben zu einem Wort zusammenfügen kann, weil man eben nicht dynamisch Speicher anfordern kann.
-
pferdefreund schrieb:
2 verschiedene Welten sind das nicht wirklich ... kann das sogar im Assembler ... die Sprache ... nur ein Syntaxproblem ... habe jetzt ... den letzten 30 Jahren ... das Hautproblem ist nicht die Sprache ... 6 Monaten noch weiss, warum ... eh ... alles Assembler.
Blablabla. Der ein oder andere hier hat mehr Erfahrung, kann mehr Sprachen, ... Denkst du, dass wir keine Ahnung haben? Typisch Troll.
-
berniebutt schrieb:
Aber erstaunlich, dass jemand von COBOL auf C umsteigen möchte. Für mich sind das zwei verschiedene Welten!
Richtig. Meinen ersten Kontakt mit OO hatte ich vor etwa 20 Jahren. Da erzählte in einem Referat ein Referent vor versammelter Mannschaft (alles Hostprogrammierer) etwas von einem Tier von dem man eine Kuh, ein Pferd oder einen Ochsen ableiten könne. Diese können verschiedene Farben haben und verschiedene Zustände (laufen, stehen, traben usw) und das habe etwas mit Klassen, Attributen und Methoden zu tun - ach ja - und mit Bank - IT... Na klasse.
Einen ähnlichen Schwachsinn erzählte man uns dann in einer anderen Grossbank im Zusammenhang mit Java etwa 10 Jahre später.
Nun gut - ich habe dann während einer Projektpause quasi in einer einsamen Berghütte mir das ganze mal näher angeschaut.. Aha - dann wurde das schon klarer: Einfach andere Begriffe für Unterprogramme, Funktionen und Variable (passt nicht ganz - aber das soll langen). Zudem ein Ansatz der Instanzierung, den es in der alten Mainftame Welt so nicht gibt. Zum Glück muss ich damit meine Brötchen nicht verdienen.
Was damals hängen blieb war C, da es einen ähnlichen Ansatz der strukturierten Programmierung wie etwa Cobol oder PL/I hat. Hobbymässig klappen mitlerweile sogar schon GUI Programme.
So kommt man also als Cobolprogrammierer zu C...
-
Auch COBOL entwickelt sich weiter. Inzwischen gibt es mit Object COBOL sogar auch dort dynamische Speicheranforderung, Konstruktion, Destruktion uvm. Nur die Formulierung ist nach wie vor ein Graus.
Ich habe immer gesagt COBOL kann man lesen wie ein Buch, aber um es zu schreiben muss man Schriftsteller sein
-
Blablabla. Der ein oder andere hier hat mehr Erfahrung, kann mehr Sprachen, ... Denkst du, dass wir keine Ahnung haben? Typisch Troll.
Ich wollte hier niemandem auf die Füße treten - hab nur mal so meine eigenen Erfahrungen geschildert. Das das mit dem malloc Sinn macht hab ich ja verstanden und mache ich ja auch nach Bedarf - aber halt nicht, wie so oft für jeden String.
Wenn ich aus ner Datenbank in eine Liste selektiere, weiss ich halt nicht, wieviel kommt - und bei sowas verwende ich schon malloc und realloc.
Nur in der Versicherungsbranche, wo ich herkomme arbeiten wir halt im Regelfall mit festen Satzformaten und Cobol, bez Assembler und da stellt sich das Problem halt nicht so.
-
Weiß nicht ob es schon gesagt wurde. Aber zum Beispiel an meiner Uni wird an einem System zur Container Suche geforscht.
Dabei hat jeder Container einen Chip. Und wenn man jetzt einen Bestimmten sucht dann würden normalerweiße die Signale nicht bis nach unten ins Schiff durchgehen.
Deshalb bekommt jeder Container ein Sender und ein Empfänger. Sobald der das Siganal empfängt Container x wird gesucht und er ist nicht container x dann gibt er das Siganal weiter. Bis Container x gefunden wird und der dann ein Signal zurück gibt.
Nun wäre es nicht lohnenswert in jeden Container einen PC zu stellen. Ausserdem wo soll der Strom dafür herkommen? Deshalb werden winzige Mikrochips entwickelt die völlig autonom arbeiten. Und wie ihr es schon vermutet haben die Chips nur sehr sehr begrenzte Speicher Mittel. Wenige 100 KB müssen da ausreichen.
Und genau für solche Anwendungen ist es wichtig speicher nur dann zu nutzen wenn man ihn braucht. Du hast Recht auf unseren Großrechner macht das vielleicht kein so großen unterschied. Wie soll man auch 100 GB Arbeitspeicher voll kriegen (Ja auch das kann man relativ einfach hinbekommen)?
Aber für Mikrosysteme macht es einen gewaltigen Unterschied.
-
Odatas schrieb:
Wenige 100 KB müssen da ausreichen.
Das ist doch eine ganze Menge. Vor knapp 30 Jahren hatte ich mal einen Rechner, der hatte 64KB Speicher, da war ein ganzer Basic-Interpreter schon drin und es gab eine große Menge durchaus komplexer Spiele, die dafür programmiert worden waren.
-
Odatas schrieb:
Deshalb werden winzige Mikrochips entwickelt die völlig autonom arbeiten. Und wie ihr es schon vermutet haben die Chips nur sehr sehr begrenzte Speicher Mittel. Wenige 100 KB müssen da ausreichen.
Und genau für solche Anwendungen ist es wichtig speicher nur dann zu nutzen wenn man ihn braucht.
Und genau bei so einer Anwendung sollte man mit mallc und dynamischer Speicherverwaltung sehr aufpassen. Was macht z.B. dein Microcontrollersystem wenn ihm der Speicher ausgeht? Hoffentlich nicht abstürzen. Seine Funktion sollte es aber auch nicht einstellen (du sagtest ja die Signale werden von Container zu Container weitergeleitet).
Von daher wirst Du vorher analysieren müssen was der maximale Speicherverbrauch deines Systems ist.
-
Frage am Rande dieses Themas: Warum sind die COBOL-Leute nicht wie die Mehrzahl der FORTRAN-Leute
vor etwa 20 Jahren auf neuere Compiler-Sprachen - seinerzeit überwiegend C - umgestiegen?
Müssen sie mit leben und ihre Saurier-Programmiersprache eben ständig anpassen oder für geeignete Schnittstellen sorgen.
Ich möchte im Sourcecode keine Lyrik lesen, die mich vom wesentlichen ablenkt!
-
berniebutt schrieb:
Frage am Rande dieses Themas: Warum sind die COBOL-Leute nicht wie die Mehrzahl der FORTRAN-Leute
vor etwa 20 Jahren auf neuere Compiler-Sprachen - seinerzeit überwiegend C - umgestiegen?Vielleicht, weil neuere Compiler-Sprachen erst 20 Jahre später auf den Mainframes ankommen. Ich betreue zur Zeit eine (Neu-)Anwendung für UNIX und BS2000, und die Macken des BS2000-C++-Compilers sind kein Spaß. Von C++98 kann man da nur träumen.
Dazu kommt vielleicht die Tatsache, dass viele Programme, die heute noch im Einsatz sind, alle Gesetze und Gesetzesänderungen seit 1954 enthalten, da entwickelt man nicht eben irgendwas neu. Und Interoperabilität zwischen C und COBOL ist auch eine Kunst für sich.
-
Vielleicht auch, weil es riesige Mengen an COBOL-Programmen gibt, die über eine (oft zu) lange Zeit gepflegt und erweitert worden sind, deren Ablauflogik schon ein COBOL-Programmierer häufig schwer folgen kann (GO TO lässt grüßen).
Außerdem fehlt in C erst mal von zu Hause aus der Datentypcomp-3für Finanzanwendungen.
Für Nicht-COBOL-Kenner:
Das ist ein bcd-Datentyp, mit dem sich Berechnungen mit Festkommazahlen ohne die bei float/double auftretenden Rundungsprobleme durchführen lassen.
-
LordJaxom schrieb:
Dazu kommt vielleicht die Tatsache, dass viele Programme, die heute noch im Einsatz sind, alle Gesetze und Gesetzesänderungen seit 1954 enthalten, da entwickelt man nicht eben irgendwas neu. Und Interoperabilität zwischen C und COBOL ist auch eine Kunst für sich.
Das ist klar: die alten Sachen laufen im oft täglichen Einsatz, haben viel Geld gekostet und müssen am Laufen gehalten werden. Eine Neuentwicklung kann zu teuer sein und ist ohne Unterbrechung schwer durchziehbar. Die Wartung der alten Programmschinken macht aber auch Probleme. Die ursprünglichen Entwickler sind in Rente gegangen und lassen auf den Kanarischen Inseln oder sonstwo die Beine in der Sonne baumeln.
Nun müssen aber doch gelegentlich oder immer wieder Anpassungen an die Aussenwelt erfolgen. Wie macht man das sinnvoll, wenn Programme nach 10 Jahren oft ausgedient haben?
Auch mit verbindlichen Schnittstellen und COBOL-Leuten - wie der Fragesteller - die sich erst nach C und dann hoffentlich nach OOP-Sprachen trauen.malloc und co. sind da meiner Meinung nach eine eher kleine Angelegenheit!