Warum so häufig malloc

berniebutt

malloc ist nun einmal eine dynamische Anforderung von Speicherplatz, der auf allen Plattformen stets begrenzt ist, auch auf Grossrechnern.
Man fordert den Speicherplatz während der Laufzeit an und gibt ihn bei Bedarf wieder frei. Das sollte auch einem COBOL-Programmierer soweit klar sein.
Für einfache in der Länge bekannte Dinge nutzt man das besser nicht, nur für wesentliches mit tatsächlich völlig unbekannter Länge.

Wer etwas bequemeres haben möchte, wählt einen anderen Compiler als C mit besserer Unterstützung durch Objekte und darauf anwenbare Methoden.

CJosef

hilft stabilität schrieb:

Wenn das Programm mit beliebigen Größen umgehen kann, dann stürzt es wegen übergroßen Daten nur dann ab, wenn der Speicher des Computers sowieso nicht mehr ausreicht.

Wenn malloc NULL liefert und das Programm deshalb abstürzt, dann liegt das am Programmierer.

pointercrash**

berniebutt schrieb:

malloc ist nun einmal eine dynamische Anforderung von Speicherplatz, der auf allen Plattformen stets begrenzt ist, auch auf Grossrechnern. ...

Macht ja auch Sinn, weil irgendwann der Speicher voll ist und irgendwann die Festplatte oder der logische Speicherraum. Viele von uns schreiben Code aufgrund des Glaubens, der Speicher wäre unendlich - aber es ist ein Irrglaube.
Also die Rückgabewerte von malloc/realloc haben durchaus ihren Sinn.
@edit: Natürlich meinte ich die Prüfung auf NULL

hustbaer

Und was das mit der Textverarbeitung angeht - da nimmt man variabel lange Sätze mit Zeilenzähler als Bestandteil des Keys - hab ich selbst schon mal innerhalb der CICS-Umgebung programmiert - eine Textverarbeitung für die Fachabteilung mit Variablenergänzung über eine IMS-Datenbank.

Wenn du die Daten dagegen im RAM hältst, dann läuft das Ding halt 100x schneller.

Versuch mal einen Compiler mit "fixed-length + DB" zu implementieren.
Das wird schon irgendwie gehen, nur wird der so langsam sein, dass keiner damit arbeiten mag.

Morle schrieb:

Vermutlich liegt der Grund ultimativ in der Plattform. PC Programme laufen auf vielen unterschiedlichen Rechner mit einer großen Palette an verschiedener Hardware. Für das SQL Beispiel bedeutet das:
Warum sollte ich Leuten mit schwachen Rechnern den Zugang zu meinem Programm verwehren, weil es auf die "maximal denkbaren Speicherverbrauch" designt wurde, obwohl im Durchschnitt der Normalnutzer vielleicht nur einen Bruchteil davon wirklich benötigt (z.B. weil er halt nur 1000 Zeichen lange SQL Statements hat)?

und

berniebutt schrieb:

malloc ist nun einmal eine dynamische Anforderung von Speicherplatz, der auf allen Plattformen stets begrenzt ist, auch auf Grossrechnern.
Man fordert den Speicherplatz während der Laufzeit an und gibt ihn bei Bedarf wieder frei. Das sollte auch einem COBOL-Programmierer soweit klar sein.
Für einfache in der Länge bekannte Dinge nutzt man das besser nicht, nur für wesentliches mit tatsächlich völlig unbekannter Länge.

Wer etwas bequemeres haben möchte, wählt einen anderen Compiler als C mit besserer Unterstützung durch Objekte und darauf anwenbare Methoden.

Nicht ganz. Wenn ich auf dem Mainframe ein Batchprogramm ausführe, also ein Programm, das keinen Bildschirmdialog hat, ist das in der Regel ein Job, der je nach Systemlast zwischen 1-15 Min "elapsed time" (es gibt auch Langläufer) und ein paar Sec. "CPU Time" verbratet. Sprich: Hier wird das Programm vom Batchenvironment gesteuert und bekommt nur soviel an Ressourcen (Storage, CPU, Start I/O usw), wie verfügbar sind, ohne das Gesamtsystem zu stressen.

Anders sieht es im Online Transaction Environment aus. Im CICS etwa muss ein Programm reusable programmiert werden. Das heisst sehr vereinfacht ausgedrückt, dass das System via einer "Linkage-Section" den Storage zur Verfügung stellt. Um das muss sich der Programmierer i.d.R. nicht kümmern (allenfalls TS- oder TD-Queues), da ihm diese Arbeit ein Preprocesser abnimmt und den Code generiert. Eigentlich schlau... der Programmierer kann so beim Speichermanagement keine Fehler machen...

Ich könnte jetzt noch mehr Szenarien aufzählen - aber dieses Thema füllt ganze Schrankwände mit IBM-Literatur und kann hier nur oberflächlich angekratzt werden.
Klar, man kann so etwas nicht mit einem Windows oder Linux vergleichen. Und die Argumentation mit schwacher Hardware hat mich eigentlich überzeugt, warum man mallocs und reallocs benötigt.
Ach ja, wenn man auf dem Mainframe Assembler programmieren muss, gibts auch einen "Getmain" resp. "Freemain".

berniebutt

Das heisst für mich: Ihr macht heute auf Grossrechnern immer noch diese Klimmzüge mit Batchdaten = Stapelverarbeitung nur eben ohne Lochkarten?
Aber erstaunlich, dass jemand von COBOL auf C umsteigen möchte. Für mich sind das zwei verschiedene Welten!

LordJaxom

berniebutt schrieb:

Das heisst für mich: Ihr macht heute auf Grossrechnern immer noch diese Klimmzüge mit Batchdaten = Stapelverarbeitung nur eben ohne Lochkarten?

So ist es. Ich bin zwar nicht Cobolfreak, aber ich weiß aus Erfahrung, dass jede Deiner Steuererklärungen und -bescheide sowie vermutlich auch jede Überweisung bei Deiner Bank in Form von einer elektronischen Lochkarte durch so ein Batchsystem läuft

Aber erstaunlich, dass jemand von COBOL auf C umsteigen möchte. Für mich sind das zwei verschiedene Welten!

Genau das sieht man immer wieder, wenn Leute aus dem COBOL-Umfeld nach ein- bis zweiwöchigen C- oder Java-Umsteigerkursen anfangen zu programmieren. Eine Klasse, 200 statische Variablen und eine Methode mit 600 Zeilen Code.

Bitte ein Bit

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.

pferdefreund

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.

Belli

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.

knivil

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...

LordJaxom

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

pferdefreund

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.

Odatas

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.

Belli

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.

berniebutt

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!

LordJaxom

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.

Belli

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 Datentyp

comp-3

fü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.