Übergabe von dynamischen Arrays an Prozeduren

[eF-eS]

Hallo,

ich habe ein Problem mit der Übergabe von dynamischen Arrays an andere Prozeduren.

Wenn ich die größe eines dynamisches Array mit SetLength festgelegt habe, möchte ich von einer Prozedure ausgeben lassen, wie groß das Array ist.

Wenn die Prozedur innerhalb der eigenen Unit steht, ist das kein Prob; wenn ich die Prozedur in eine andere Unit verlege, wird das Projekt nicht mehr compiliert und unten erscheint die Meldung "inkompatible Typen: array und dynamic array".

Bitte seht Euch das angehängte Projekt an. Ich komme einfach nicht weiter.

Gruss Florian

[Helmi]

Hallo,

hier mal die geänderten Codestellen:

Main.pas:

Delphi-Quellcode:

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;                                                         //<== unit2 entfernt

type
  TDatenfelder = record
     a, b: extended;
     end;
  TForm1 = class(TForm)
    Edit1: TEdit;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Aus(var d: array of tDatenfelder);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

uses unit2;                                                                  //<== neu hinzugefügt

und in der Unit2.pas:

Delphi-Quellcode:

unit unit2;


interface
uses Dialogs, SysUtils, main;                                                //<== main hinzugefügt
                                                                             //<== type-deklaration entfernt
  procedure Auswertung(var d: array of tDatenfelder);

implementation

procedure Auswertung(var d: array of tDatenfelder);
Begin

  showmessage(inttostr(low(d)) +' bis ' + inttostr(high(d)));
End;

end.

[edit]
das geänderte Projekt angehängt!
[/edit]

[eF-eS]

Vielen Dank!

Ich schau's mir gleich an!

Es läuft - damit kann ich mir mein eigentliches Problem wieder ansehen.

[Der_Unwissende]

Hi,
was du hier siehst

Zitat von Helmi:

Main.pas:

Delphi-Quellcode:

...
implementation

uses unit2;                                                                  //<== neu hinzugefügt

und in der Unit2.pas:

Delphi-Quellcode:

interface
uses Dialogs, SysUtils, main;                                                //<== main hinzugefügt
                                                                             //<== type-deklaration entfernt

ist gaaaaaaaanz schlechter Stil. Natürlich wird das so funktionieren, aber es gibt keinen Grund, warum man so unsauber arbeiten sollte. Deshalb rate ich dir dringend davon ab. In vielen anderen Sprachen (die keine Unterscheidung zwischen einem Interface und einem Implementation Abschnitt haben) ist ein solches Konstrukt verboten und führt zu einer Fehlermeldung des Compilers. Immerhin wird hier über Kreuz eingebunden.
Das klingt nicht schön und ist auch nicht schön. Du hast hier eine Abhängigkeit geschaffen, die du vermeiden kannst. Die Nachteile wurden glaube ich schon woanders festgestellt und lassen sich leicht finden.

Zur Lösung: Verwende eine dritte Unit, in der du den Datentyp festlegst. Unit3 (als Beispiel) enthält dann nur noch die Typdeklaration. Diese Unit kann von den beiden anderen eingebunden werden und alles funktioniert (die Namen sollten natürlich besser als unit2 und unit3 gewählt werden).
Unit3 könnte also so aussehen:

Delphi-Quellcode:

unit Unit3;

interface

type
  TDatenfelder = record 
    a, b: extended;
  end;

  TDatenfelderArray = Array of TDatenfelder;

implementation

end.

Die kannst du dann wie gewohnt in allen Units verwenden (ist einfach sauberer!).

Gruß Der Unwissende

[himitsu]

Also als soo schlechten Stil seh ich das inzwischen garnicht mehr an.

Ich verschiebe jetzt eh alle Units, welcher nicht im Interface-Teil nötig sind in die Implementation, also dahin, wo sie wirklich gebraucht werden.

Außerdem hab ich z.B. in einem aktuellen Projekt Units, welche nicht nur einige Typen, sondern ganze Funktionen gegenseitig einbinden und das nicht nur über Kreuz (Dreieck, Viereck ... Zickzack).

Vorallem diese Funktionen jetzt noch in weitere Units auszulagern wäre nicht so schön,
da sie logisch in die entsprechenden Units reingehören.
Und beim Auslagern in weitere Units aus den eh schon über 50 noch viel mehr Units würden,
also alles auch noch unübersichtlicher würde.



Und zum Schluß: Wozu ein Featzre nicht nutzen, wenn es schonmal vorhanden ist

[Der_Unwissende]

Zitat von himitsu:

Und zum Schluß: Wozu ein Featzre nicht nutzen, wenn es schonmal vorhanden ist

Hm, da fällt mir doch der ?-Operator oder Zeiger auf Zeiger auf Zeiger auf Zeiger... Es gibt Möglichkeiten die ein Programm einfach unleserlich machen.
Klar, es ist von mir etwas übertrieben hier pauschal zu sagen ist schlecht. Ich denke aber, dass es sich in einem solchen Fall (insbesondere für Datentypen) sehr leicht vermeiden lässt.
Funktionen die logisch zusammen gehören denke ich kann man gut in eine Klasse stecken. Klar, es geht auch ohne OOP. So oder so kannst du die Gruppen von Units, die logisch zusammen gehören in einen eigenen Ordner packen. Trennst du hier sauber, nutzt du ein Feature und hast die Zusammengehörigkeit und keine Abhängigkeiten (also bei sauberem Design).

[DGL-luke]

Zitat von himitsu:

Und zum Schluß: Wozu ein Featzre nicht nutzen, wenn es schonmal vorhanden ist

Weil man sich dann dran gewöhnt und es vielleicht auch dann einsetzt, wenn es gar nicht die beste Möglichkeit wäre und sich vielleicht irgendwann wegen ein bisschen Faulheit schlecht wartbaren Code oder gar einen Designfehler ins Programm holt

Genauso wie break, exit, goto etc.
Alle diese Dinge, die nicht der "reinen Lehre" entsprechen sollte man eben nur einsetzen, wenn sie wirklich Sinn machen bzw. notwendig sind.

(Meine Meinung... aber diese Diskussion gabs ja auch schon mal )