Verfügbarkeit öffendlicher Units

[LarsSchwencke]

Hallo,

mit der verfügbarkeit öffendlich deklarierter Units stehe ich
offensichtlich auf Kriegsfuß.
Auch scheint das Kapittel 6.1.2 im Borland Delphi 7 Grundlagen und Profiwissen
bei Delphi XE4 nicht zu funktionieren.

Mein Problem, 3 Units.
Die Unit 2 verwendet die Unit 3.
Die Unit 1 die Unit 2 und sollte aber auch die Funktionen der Unit 3 nutzen können.

Sollte es nicht so funktionieren?

Unit3:

Delphi-Quellcode:

unit Unit3;

interface

function Test3(): integer;

implementation

function Test3(): integer;
begin
...
end;

end.

Unit2

Delphi-Quellcode:

unit Unit2;

interface

uses Unit3;

function Test2(): integer;

implementation

function Test2(): integer;
var
  iCounter2: integer

begin
 iCounter2 := Test3();
end;
end.

Unit1

Delphi-Quellcode:

unit Unit1;

interface


function Test1(): integer;

implementation

uses Unit2;

function Test1(): integer;
var
  iCounter1: integer

begin
 iCounter1 := Test3();     // E2003 Undeklarierter Bezeichner: 'Test3' 
end;
end.

Kann mir jemand mitteilen, wie sich dies realisieren läßt?

Vielen Dank für alle Infos.

MfG
Lars

[DeddyH]

Wenn Unit1 Funktionen aus Unit3 benutzen soll, muss sie auch Unit3 kennen.

[baumina]

Alle die Units, die du nicht innerhalb des interfaces brauchst in der uses-Liste unterhalb der implementation angeben.

Delphi-Quellcode:

unit xxx;

Interface

uses ..., ...; // hier wenn es im Interface gebraucht wird

implementation

uses ..., ...; // hier wenn es Nicht im Interface gebraucht wird

[EWeiss]

Zitat:

Zitat von DeddyH (Beitrag 1244067)

Wenn Unit1 Funktionen aus Unit3 benutzen soll, muss sie auch Unit3 kennen.

Sag ihm doch das er sie unter Uses in der unit 1 noch mit einbinden muss. ;)

gruss

[DeddyH]

Das ist ja die logische Konsequenz des Gesagten.

[LarsSchwencke]

Ja sicher,

das kann ich machen, war nur nicht meine Idee,
und in dem Buch steht:

Ich zietiere aus dem Buch Borland 7 Grundlagen und Profiwissen:

"Öffendlich (public) Deklaparion
In diesem Fall erscheint die uses-Klausel unmittelbar nach dem Wort interface.
Programme bzw. andere Units, die die Aktuelle Unit benutzen, können also auch zusätzlich
auf die hier angeführten Units zugreifen."

Dann sollte es ja auch funtionieren, die Frage, ist es bei Delphi XE4 anders?

MfG
Lars

[DeddyH]

Das wäre mir jetzt neu, in dem Punkt scheint im Buch einfach etwas Falsches zu stehen.

[jaenicke]

In den Büchern waren mir auch noch ein paar andere Punkte aufgefallen. Die hatte ich damals auch an die Autoren geschickt, habe aber keinerlei Antwort bekommen.

Das war eines der wenigen Bücher, die ich beim Lernen von Delphi in die Hand genommen hatte. Geholfen haben sie mir nicht wirklich. Ausprobieren, die mitgelieferten Beispiele und Quelltexte und die Hilfe haben mir viel mehr geholfen.

[himitsu]

Du kannst dir einfach merken, daß man nur das sieht, was "direkt" in den in Uses angegebenen Units enthalten ist
und zwar in der Reihenfolge von der letzten zur ersten Unit.


Das ist also ganz einfach komplett falsch, was da steht.

Von dem, was im Interface ist, wird alles, was nicht private (in Klassen), grundsätzlich auch erstmal nicht protected und was auch keine Unit ist, in der aufrufenden Unit verfügbar sein,
also nur das, was auch "wirklich" da drin "sichtbar" ist.

Was man machen kann, ist z.B. einen Alias von einem Typ oder die Kopie einer Konstante, bzw. die Umleitung einer Funktion aus der Unit3 in Unit2 anzulegen und diese dann in Unit1 zu nutzen.

Bei einem gleichnamigen "Alias" ist es dann egal, ob das Original aus Unit3 oder der Alias aus Unit2 in Unit1 verwendet wird, da es intern der selbe Typ ist.

[p80286]

Das angesprochene Verhalten war unter TP noch vorhanden.

ERin Blick in die D7 OH hilft hier weiter:

Zitat:

Die Reihenfolge der Units in der uses-Klausel bestimmt die Reihenfolge der Initialisierung dieser Units (siehe Der initialization-Abschnitt) und wirkt sich auf die Suche des Compilers nach den Bezeichnern aus. Wenn zwei Units eine Variable, eine Konstante, einen Typ, eine Prozedur oder eine Funktion mit identischem Namen deklarieren, verwendet der Compiler die Deklaration der in der uses-Klausel zuletzt angegeben Unit. Wollen Sie auf den Bezeichner in einer anderen Unit zugreifen, müssen Sie den vollständigen Bezeichnernamen angeben: Unitname.Bezeichner.

Eine uses-Klausel muss nur die Units enthalten, die direkt vom Programm bzw. von der Unit verwendet werden, in dem bzw. der die uses-Klausel steht. Referenziert beispielsweise Unit A Konstanten, Typen, Variablen, Prozeduren oder Funktionen, die in Unit B deklariert sind, muss die Unit B explizit in der uses-Klausel von Unit A angegeben werden. Referenziert B wiederum Bezeichner aus Unit C, ist Unit A indirekt von Unit C abhängig. In diesem Fall muss Unit C nicht in einer uses-Klausel in Unit A angegeben werden. Der Compiler benötigt jedoch Zugriff auf die Units B und C, während Unit A verarbeitet wird.

Das folgende Beispiel illustriert diese indirekte Abhängigkeit:

program Prog;
uses Unit2;
const a = b;
...
unit Unit2;
interface
uses Unit1;
const b = c;
...
unit Unit1;
interface
const c = 1;
...

Hier hängt das Programm Prog direkt von Unit2 ab, die wiederum direkt von Unit1 abhängig ist. Prog ist also indirekt von Unit1 abhängig. Da Unit1 nicht in der uses
-Klausel von Prog angeben ist, sind die in Unit1 deklarierten Bezeichner für Prog nicht verfügbar.

Damit ein Client-Modul compiliert werden kann, muss der Compiler Zugriff auf alle Units haben, von denen der Client direkt oder indirekt abhängt. Sofern der Quelltext dieser Units nicht geändert wurde, benötigt der Compiler nur die .DCU-Dateien (Windows) bzw. die .DCU/.DPU-Dateien (Linux), nicht jedoch die Quelltextdateien (.PAS). Wenn es sich bei dem Linkpartner um ein Package handelt.

Werden im interface-Abschnitt einer Unit Änderungen vorgenommen, müssen die von dieser Unit abhängigen Units neu compiliert werden. Werden die Änderungen dagegen nur im implementation- oder einem anderen Abschnitt einer Unit vorgenommen, müssen die abhängigen Units nicht neu compiliert werden. Der Compiler überwacht diese Abhängigkeiten und nimmt Neucompilierungen nur vor, wenn dies erforderlich ist.

Gruß
K-H

[jaenicke]

Das Verhalten ist ja in jeder Delphiversion da, hat aber nichts mit dem Verhalten zu tun, das der Satz aus dem Buch impliziert. Dass man nämlich nicht nur über Code in einer zweiten Unit auf Bezeichner einer dritten Unit zugreifen kann, sondern direkt auf diese Bezeichner zugreifen kann. Das ging weder in Turbo Pascal noch in Delphi, zumindest nicht seit Turbo Pascal 6, früher kenne ich nicht.

[ASM]

Zitat:

Zitat von p80286 (Beitrag 1244097)

Das angesprochene Verhalten war unter TP noch vorhanden.

Unsinn, das war noch nie in Turbo Pascal so vorhanden. Jedenfalls definitiv nicht unter TP7, mit dem ich das sicherheitshalber soeben noch einmal verifiziert habe, und das ja unmittelbarer Vorläufer von BP7 war.

In dieser Hinsicht ist die ganze Diskussion, beruhend auf der angeblichen Falschaussage der zitierten Quelle, allein durch die mangelhafte Wiedergabe des Zitats verursacht. Die ist nämlich in jeder nur denkbaren Weise unqualifiziert und fehlerhaft gemacht worden, sowohl inhaltlich als auch formal (und von der Rechtschreibung allein schon in der Wiedergabe des "Zitats" ganz zu schweigen).

In der Beschreibung der Autoren wird auch rein gar nichts fälschlich impliziert, wie leichtfertig unterstellt worden ist. Vielmehr beschreiben die Autoren des Buches (übrigens Walter Doberenz & Thomas Gewinnus, und der Titel heißt korrekt: "Borland Delphi 7. Grundlagen Profiwissen Kochbuch", erschienen im Verlag Hanser, München 2007) auf Seite 282 (Kapitel 6.1.2) das Vorgehen bei der querübergreifenden Verwendung mehrerer Units unmissverständlich korrekt, so wie das auch unverändert in allen Delphi-Versionen weiterhin der Fall ist.

Da der Verlag ausdrücklich die Wiedergabe auch nur von Teilen des Buches und dies selbst zum Lehrzweck ausdrücklich strikt untersagt hat, werde ich den betreffenden, oben angeblich "zitierten" Abschnitt hier natürlich nicht im kompletten und richtigen Wortlaut zitieren können.

[Lemmy]

Zitat:

Zitat von ASM (Beitrag 1244150)

In dieser Hinsicht ist die ganze Diskussion, beruhend auf der angeblichen Falschaussage der zitierten Quelle, allein durch die mangelhafte Wiedergabe des Zitats verursacht. Die ist nämlich in jeder nur denkbaren Weise unqualifiziert und fehlerhaft gemacht worden, sowohl inhaltlich als auch formal (und von der Rechtschreibung allein schon in der Wiedergabe des "Zitats" ganz zu schweigen).

hm... wenn ich mir das bei Amazon anschaue steht da genau das (inhaltlich und natürlich ohne die Rechtschreibfehler) was der Threadersteller hier "zitiert" hat. Könnte es sein, dass hier unterschiedliche Versionen des Buches im Umlauf sind?

Grüße

[LarsSchwencke]

Es gibt zwei Bucher.
Habe beide.

Grundlagen und Profiwissen

und Kochbuch.

[Lemmy]

@Lars: Danke!

[LarsSchwencke]

@ASM

nur ist es so, dass ich das Buch, das Du hier aufführst gar nicht meine.
Es ist schon richtig wie ich es geschrieben habe.

Der Titel des Buches lautet:

Borland Delphi 7 Grundlagen und Profiwissen,
die Autoren, Walter Doberenz und Thomas Kowalski.

Da Du ja über das Wissen verfügst, könntest Du uns doch, ohne zu zitieren, mitteilen was mit diesem Satz gemeint ist.
Ich habe es so verstanden wie ich es oben beschrieben habe.

Erleuchte mich.:idea:

MfG
Lars

[ASM]

Ok, also 2 Bücher ± gleichen Inhalts:
2002: "Borland Delphi 7 - Grundlagen und Profiwissen" = ISBN 978-3-446-22316-5
2007: "Borland Delphi 7 -- Grundlagen, Profiwissen, Kochbuch" = ISBN 978-3-446-41216-3
zu letzterem: O-Ton Hanser Verlag "Diese Neuauflage vereint die erfolgreichen Bücher "Borland Delphi 7 - Grundlagen und Profiwissen" und "Borland Delphi 7 - Kochbuch" des bekannten Autorenduos Walter Doberenz & Thomas Gewinnus in einem Band."

Wie dem auch sei: die Autoren sind ausgewiesen als Professor Dr.-Ing. habil Walter Doberenz, Altenburg, und Dipl.-Ing. Thomas Gewinnus, Frankfurt/Oder. Sie entstammen also beide weder der philosophischen noch der theologischen Fakultät. Es ist daher nicht anzunehmen, dass beide so unbedarft sind, den korrekten Sachverhalt nicht zu kennen oder womöglich ignorieren zu wollen - unabhängig von unterschiedlichen Editionen des Buches. Und wenn solche Autoren ein derartiges Fachbuch - gleich welcher Version - schreiben, dann doch zweifelsohne nicht derart, dass ihre Ausführungen etwas kontrahär wesentlich anderes implizieren als was sie gemäß dem konkreten, authentischen Sachverhalt aussagen wollen. Und dieser Sachverhalt hinsichtlich der Verwendung multipler Units ist nun einmal seit TPs seeligen Zeiten absolut eindeutig klar (s.o.).

Der Sachverhalt ist von den Autoren zwar in aller Kürze, jedoch völlig korrekt beschrieben, wenn man die Ausführungen komplett liest, vor allem auch logisch konsequent nachvollzieht und man sie nicht auf einen einzigen Satz aus dem Kontext herausgerissen reduziert. In der vollständigen Aussage heißt es nämlich unmittelbar vor dem in #6 zitierten Satz explizit (ich riskiere dieses Zitat jetzt einmal ohne ausdrückliche schriftliche Genehmigung des Verlags): "Ebenso wie ein Programm kann auch eine Unit auf andere Units zugreifen. Letztere müssen, durch Kommas getrennt, nach dem reservierten Wort uses aufgelistet werden." Und in diesem kompletten Kontext kommt dem dann folgenden Satz (siehe in #6) eine ganz andere logische, nämlich auf dieses sozusagen imperative Mandat bezogene Beschreibung des zutreffenden Sachverhaltes zu als hier fälschlicherweise unterstellt worden ist.

Letztlich entscheidend ist aber hier wohl doch, dass es diese eingangs vermutete Divergenz im Verhalten von TP vs. D7ff. niemals gab und vielmehr alles auf einem Missverständnis infolge fehlerhafter Interpretation beruhte.

[jaenicke]

Ich habe das betreffende Zitat im genannten Buch einmal nachgelesen. Es ist dort sicherlich nicht so falsch gemeint, ist allerdings unglücklich formuliert. Die danach folgenden Absätze stellen das zwar klar, aber in der Hilfe zu Delphi ist das in der Tat besser beschrieben:
http://docwiki.embarcadero.com/RADSt...amme_und_Units

[Perlsau]

Zitat:

Zitat von ASM (Beitrag 1244200)

"Ebenso wie ein Programm kann auch eine Unit auf andere Units zugreifen. Letztere müssen, durch Kommas getrennt, nach dem reservierten Wort uses aufgelistet werden." Und in diesem kompletten Kontext kommt dem dann folgenden Satz (siehe in #6) eine ganz andere logische, nämlich auf dieses sozusagen imperative Mandat bezogene Beschreibung des zutreffenden Sachverhaltes zu als hier fälschlicherweise unterstellt worden ist.

Im Buch "Doberenz/Gewinnus - Grundlagen, Profiwissen, Kochbuch, Borland Delphi 7" (ISBN 978-3-446-41216-3) steht auf Seite 282 oben (Kapitel 6: Units und Objekte) unter der Überschrift Uses-Klausel folgendes:

Öffentliche (public) Deklaration In diesem Fall erscheint die uses-Klausel unmittelbar nach dem Wort interface. Programme bzw. andere Units, die die aktuelle Unit benutzen, können also auch zusätzlich auf die hier angeführten Units zugreifen. Allerdings sind im Interface-Teil so genannte "zirkulare" Deklarationen verboten (siehe unten). Wenn z.B. Unit A die Unit B öffentlich benutzt, darf das andererseits die Unit B nicht mit der Unit A tun (und umgekehrt). (Hervorhebungen von mir.)

Wenn ich davon ausgehe, daß mit "aktuelle Unit" genau die Unit gemeint ist, um deren öffenltiche Uses-Klausel es hier geht, behauptet der Autor unmißverständlich, daß andere Units, die diese aktuelle Unit verwenden, zusätzlich (zu den veröffentlichten Methoden der aktuelle Unit) auch auf die in der öffenltichen Uses-Klausel der aktuellen Unit stehenden Units zugreifen könnten. Das ist eindeutig falsch, das kann man unter keinen Umständen anders interpretieren.

Gerade ausprobiert:

In der öffentlichen USES-Klausel der MainUnit wird UnitTest eingebunden. In der öffentlichen USES-Klausel von UnitTest wird UnitNochEinTest eingebunden. Im Interface-Teil von UnitNochEinTest wird eine Konstante TestConst = 'TestString'; deklariert. Die kann ich nun von UnitTest aus lesen, jedoch nicht von der MainUnit aus.

[LarsSchwencke]

Hallo,

vielen Dank für alle Infos.
Ich möchte hier nicht Grund einer Missstimmung im
Forum sein. Meine Frage ist beantwortet.
So wie ich mir das dachte geht es nicht.
Das reicht.

Thema kann geschlossen werden.

Danke an alle.

MfG
Lars