Dynamische Arrays - ins negative Erweiterbar?

[schnullerbacke]

@Christian

Eben, eben. Der Variante Teil könnte ja auch aus Records bestehen. Abgesehen davon könntest du auf die anderen Felder nicht zugreifen wenn der Variantentyp nicht stimmt. Das führt zu einem Fehler. Aber im Falle von Adressen könnte man hier Länderabhängig z.B. auf unterschiedliche Formen und Längen der Postleitzahl reagieren.

@pluto

Am besten sind die Dinger geeignet wenn du viele gleiche Felder in einem Record hast und sich je nach Variante ein oder zwei Felder durch ihren Typ unterscheiden.

Variante Records nehmen übrigens immer genau soviel Speicherplatz ein, wie die größte Struktur braucht. Man kann also auch Speicher dadurch einsparen.

[ovidius]

Blöde Frage, weil ich das nicht wirklich verstehe. Wollt Ihr nicht eigentlich sowas wie Generische Klassen, also Klassen deren Methoden nicht explizit vom Typ abhängen, so wie die Container in STL unter C++?

Wenn ich das richtig aufgeschnappt habe, dann sollen die ab fpc 2.2 im Sprachumfang von FreePascal sein.

Mir hat man jedenfalls beigebracht von Varianten Records die Finger zu lassen, wenn es nicht absolut nötig ist, weil die Typsicherheit nicht mehr gewährleistet ist. Aber ich möchte auch keine Flammes hier starten. Ich sehe ja ein, dass es manchmal sinnvoll ist

Die Bemerkung zum Speicherplatz von Varianten Records will ich nochmal ergänzen, denn die Größe der des Records ist die größte Struktur plus die entsprechenden Auswahlvariablen( falls vorhanden?), sagt zumindest die Referenz:

If the record contains a variant part, the size of the variant part is the size of the biggest variant, plus the size of the tag field type if an identifier was declared for it.

[Christian]

Ja du hast völlig recht deswegen versteh ich nicht was schnuller hier damit anstellen will, zumal man in OO Zeiten kaum noch records brauch. Ich benutze mittlerweile fast nur noch persistente Typen mit TWriter/TReader.

Das mit dem Speicherplatz ist natürlich auch richtig geht ja nicht anders jeder Record muss nunmal eindeutig viel Speicherplatz belegen damit muss ein Varianter Record natürlich den Speicher belegen den die größten Variablen in ihm belegen.

[Euklid]

Nun mal wieder eine Anfängerfrage: Was bedeutet "Typenunsicherheit" und welche Nachteile sind damit verbunden?

[ovidius]

Je Varaible hat einen Typ und der Compiler kann prüfen, ob die Ausdrücke, die man hinschreibt mit den Typen auch sinnvoll sind. Das ganze heißt etwas vereinfacht Typsicherheit. Jede Variable hat immer genau einen Typ.

Variante Dinge haben genau diesen Vorteil nicht, dass heißt der Compiler kann bestimmte Fehler nicht schon bei der Programmierung feststellen, sondern erst zur Laufzeit oder gar nicht. Wenn Deine Variantes Record zwei Felder hat, sagen wir mal eine Ganzzahl und eine Fließkommazahl, dann kann der Compiler im Prinzip nicht wissen, als was die Variable jetzt benutzt wurde, also welcher Wert gerade sinnvoll gelesen werden kann.

Zur Vollständigkeit nochmal ein kurzer Artikel von Wikipedia zum Thema "Typsicherheit":
http://de.wikipedia.org/wiki/Typsicherheit

[Euklid]

Aha, das ist also der Haken: Man hat eine Fehlerquelle mehr - dann muss ich mir das nochmal überlegen. Danke!

Wenn man, wie von Pluto einst vorgeschlagen, Records mit fester Typenuzuweisung definiert, dürfte es hier doch keine Probleme geben?

[schnullerbacke]

@ovidius

Nicht ganz. Alle Zugriffe über die Referenzierung bleiben Typsicher. Lediglich die Übertragung mit dem Konstrukt:

(var InBuf);

ist für den Compiler nicht auflösbar. Zu diesem Zeitpunkt kann er ja nicht wissen was hier tatsächlich übertragen wird. Im Augenblick des Typecast ist wieder alles normal. Im Grunde ist das so etwas wie eine Zeigervariante. Allerdings eben mit dem Vorteil das man eine eindeutige Struktur hat.

[Euklid]

So. Bin heute wiedermal seit Langem zum Programmieren gekommen.
Habe mir inzwischen viele Gedanken über die Struktur gemacht. Das hier ist das Ergebnis:

Code: Alles auswählen

TermFeldTyp = record
    Opera: cardinal;                            //Operationen (Add, Mul, aber auch Zahl, Variable)
    Argument: array of cardinal;                //Pointer auf andere Komponenten des Terms
    Varname: string;                            //Enthaelt Variablennamen im Fall von Opera=002 (Variable)
    Zaehler,Nenner: array of cardinal;          //Fuer beliebig genaue Rechnung mit rationalen Zahlen
    ZaehlerAnz,NennerAnz:array of cardinal;     //Anzahl der Elemente der zugehoerigen Arrays
    ZahlenSystem:cardinal;                      //z.B. Binaer(2)-, Dezimal(10)- oder Hexadezimal(16)system
    GlKoZa:extended;                            //Fuer Gleitkommazahlen
   end;
  TermTyp = record
    TFeld:array of TermFeldTyp;                 //Hier ist der Term gespeichert.
    Termlaenge:cardinal;                        //Komponentenanzahl des Arrays.
  end;

Viele Grüße, Euklid

[Euklid]

Mal eine technische Frage:

Kann man auf einfache Weise einem Array a ein anderes Array b gleichen Typs hinzuaddieren? Ähnlich wie man Strings addieren kann (die ja im Grunde auch nur Arrays sind)?

Wenn ja, wie? - Danke!

Euklid

[theo]

Mal eine technische Frage:

Kann man auf einfache Weise einem Array a ein anderes Array b gleichen Typs hinzuaddieren? Ähnlich wie man Strings addieren kann (die ja im Grunde auch nur Arrays sind)?

Wenn ja, wie? - Danke!

Euklid

So wie du dir das vorstellst geht's glaub ich nicht.
Aber wenn's schnell gehen soll, kannst du mit System.Move arbeiten.
Dabei musst du aber selber schauen, dass das Ziel-Array gross genug ist und wieviele Bytes du schieben musst.
Oder nimm eventuell gleich ne TList, die schaut selber dass es passt.

[Euklid]

Ok, System.Move werde ich mir mal näher anschauen. Bisher hatte ich das so geregelt, dass ich die Komponenten des Feldes über eine for-Schleife einzeln übertragen hatte. War aber, wie ich finde, recht umständlich.