[gelöst] Units zusammenfassen

[Arthur Dent]

Hallo Zusammen!

Ich implementiere grad eine vielzahl von Klassen die von einer gemeinsamen Basisklasse abstammen. Um keine endlos lange Quelltextdatei zu erhalten habe ich bisher alle abgeleiteten Klassen in jeweils einzelnen Units angelegt. Weiterhin lassen sich vom Kontext her noch einige weitere Units zu diesen Klassen zuordnen.
Mein Problem damit ist nun, dass ich wenn ich das ganze Zeug nutzen will sehr viele Verweise im "uses" Abschnitt zu deklarieren. Gibt es irgendeine möglichkeit mehrere units zusammenzufügen?
Mein naiver Ansatz war zunächst einen neue Unit zu erzeugen die alle anderen Units einbindet welche ich zusammenfassen möchte. das hat allerdings nicht funktioniert.
Geht sowas überaupt? Wie mache ich das dann?
Vielen Dank im Voraus!

[Warf]

Hallo Zusammen!

Ich implementiere grad eine vielzahl von Klassen die von einer gemeinsamen Basisklasse abstammen. Um keine endlos lange Quelltextdatei zu erhalten habe ich bisher alle abgeleiteten Klassen in jeweils einzelnen Units angelegt. Weiterhin lassen sich vom Kontext her noch einige weitere Units zu diesen Klassen zuordnen.
Mein Problem damit ist nun, dass ich wenn ich das ganze Zeug nutzen will sehr viele Verweise im "uses" Abschnitt zu deklarieren. Gibt es irgendeine möglichkeit mehrere units zusammenzufügen?
Mein naiver Ansatz war zunächst einen neue Unit zu erzeugen die alle anderen Units einbindet welche ich zusammenfassen möchte. das hat allerdings nicht funktioniert.
Geht sowas überaupt? Wie mache ich das dann?
Vielen Dank im Voraus!

Kurze Antwort nein. Im Gegensatz zu z.B. java braucht man in Pascal nicht so viele kleine Units zu machen. Pascal ist so Strukturiert das man sich auch in einer 1000 Zeilen Unit noch gut zurechtfinden kann. Der Interface Teil gibt eine schöne Übersicht und in Lazarus kann man von Dort überall in die Implementierung Springen. Gleichzeitig steht bei jeder Funktion dabei zu welcher Klasse sie gehört und ist im gegensatz zu Z.B. java nicht durch die Position im Quelltext bestimmt.

Wenn die Units mir dennoch zu groß werden inlcude ich einfach Dateien für die Implementierung:

Code: Alles auswählen

Unit Test;
interface
type
  TFoo = class
  public
    procedure Bar;
  end;
 
implementation
 
{$I foo.inc}
 
end.

foo.inc:

Code: Alles auswählen

procedure Foo.Bar;
begin
  WriteLn('Hallo Welt');
end;

Und nur so am rand, warum zwei Units pro Subklasse?

PS: Du kannst auch einfach eine Wrapper Unit machen:

Code: Alles auswählen

Unit MyUnitAll;
uses
  MyUnit1, MyUnit2;
 
interface
 
type
  TFoo = MyUnit1.Foo;
  TBar = MyUnit2.Bar;
 
implementation
end.

[Arthur Dent]

Im Gegensatz zu z.B. java braucht man in Pascal nicht so viele kleine Units zu machen. Pascal ist so Strukturiert das man sich auch in einer 1000 Zeilen Unit noch gut zurechtfinden kann. Der Interface Teil gibt eine schöne Übersicht und in Lazarus kann man von Dort überall in die Implementierung Springen.

Tut mir leid, dass sehe ich nicht so, Auch in Java/C++/Python und vermutlich diversen anderen Sprachen mit denen ich mic nicht auskenne kann ich mit Hilfe der jeweiligen IDE genauso komfortabel im Code navigieren.
Ich finde unabhängig davon dass kleinere Quelltextdateien erheblich zur Verbesserung der Übersichtlichkeit des eigenen Codes beitragen, insbesondere in umfangreicheren Projekten.

Und nur so am rand, warum zwei Units pro Subklasse

Ich habe nie von zwei Units pro Subklasse gesprochen. Potentiell könnten hier beliebig viele Subklassen abgeleitet werden. Eine Aufteilung auf einzelne Quelltextdateien pro subklasse hat dann den Vorteil das der bereits implementierte Code nicht behr angefasst werden muss. Er muss nicht nur nicht neu kompiliert werden, sondern die betreffenden Units müssen noch nicht einemal geöffnet werden.

Die Idee mit der Wrapper-Unit scheint hier genau das zu sein was ich brauche. Vielen Dank für diesen Hinweis!

[Warf]

Tut mir leid, dass sehe ich nicht so, Auch in Java/C++/Python und vermutlich diversen anderen Sprachen mit denen ich mic nicht auskenne kann ich mit Hilfe der jeweiligen IDE genauso komfortabel im Code navigieren.
Ich finde unabhängig davon dass kleinere Quelltextdateien erheblich zur Verbesserung der Übersichtlichkeit des eigenen Codes beitragen, insbesondere in umfangreicheren Projekten.

Naja also C++ kann zur absoluten Hölle werden da du eine Klasse auf beliebig viele Dateien verteilen kannst. Gleichzeitig ist das mit den Headern extrem doof gelöst sodass bei größeren Projekten die IDE irgendwann nicht mehr ganz klar kommt (also bei vielen Projekte findet Visual Studio bei mir die Header dateien nur wenn es lust hat). Und klar kann man mit der IDE meist rumspringen, worum es mir aber ging ist das man ohne einen Header (der bei Pascal Praktischerweise in der selben datei ist) alles problemlos überblicken kann. In Java musst du um eine Klasse zu verstehen immer auf die Implementierung schauen statt auf eine Zusammenfassung. Gleichzeitig wenn du in einem Großen File eine Funktion toString findest die fast jede klasse hat musst du eventuell hunderte Zeilen hochscrollen um zu sehen in welcher Klasse das ist.
Und in Python ist es durch das wegfallen der Klammern sogar noch schlimmer.

Während ich bei Python schon die Kriese bekomme wenn ich mehr als eine Klasse in einem Java dokument habe habe ich bei meinen Pascal projekten für gewöhnlich mindestens 4-5 (logisch zusammenhängende) Klassen pro Unit, ohne dabei den Überblick zu verlieren

[Arthur Dent]

Also ich hatte mit Python nie probleme mich mit mehreren Klassen in einer Quelltextdatei zurechtzufinden. Da in Python den Kontrollfluss über Codeeinrückungen gesteuert wird, ist der Quelltext automatisch recht ordentlich formatiert und daher gut lesbar. Klammern sind Meiner meinung nach dabei absolut überflüssig. Es ist nur eine Frage wie gut man an das Aussehen von Python Quelltext gewöhnt ist. Ich hab mal ein umfangreichers Tool mit Python und eclipse entwickelt und bin nach einiger Eingewöhnung wirklich super zurecht gekommen.

Ähnliches kann ich aufgrund identischer IDE auch für Java sagen. Auch in eclipse gibt es ein Equivalent des "CodeExplorer". Damit lässt sich absolut komfortabel durch die Funktionen einzelner Klassen navigieren.

Das C++ das Aufteilen einer Klasse in mehrer Quelltextdateien erlaubt ist mir noch nichtmal in den Sinn gekommen. Das würde ich wahrscheinlich auch eher vermeiden. Bin aber auch nicht so der C++ experte. Hab mal n bissel mit codeblocks rumprobiert. Das auswerten der Header dateien hat diese IDE da absolut problemlos hinbekommen. habe allerdings auch kein umfangreiches Projekt implementiert.
Soweit ich es verstanden habe müssen in C++ auch die Funktionsprototypen nicht zwangsläufig in Header-Dateien ausgelagert werden, sondern können auch auf Modulebene stehen. Die Header-Datein bieten nur eine Form des Information-hiding. Sie erlauben es auf einfache weise eine Schnittstelle zu veröffenlichen ohne dabei die Implementation zu zeigen. Im C++ Kontext ist das wohl auch hilfreich aufgrund der C++ Linking-Strategie? K.A. Kenne mich nicht so richtig aus.

Grundsätzlich stimme ich auch zu dass es Sinn ergibt inhaltlich zusammenhängende Klassen in einer Datei zu behalten. Ich bin aber gleichzeitig der Meinung dass es auch gründe geben kann einzelne Klassen strikt in einzelne Quelltextdateien aufzuteilen. M.E. ist dass z.B. sinnvoll wenn bei abgeleiteteten Klassen potentiell sehr viele Subklassen entstehen und die genaue Anzahl zunächst unbekannt ist bzw. sich über die Projektlebensdauer von Zeit zu Zeit erweitert. So braucht wie zuvor schon angeführt der bereits geschriebene code überhaupt nicht mehr angefasst werden.

Bitte versteht mich nicht Falsch! Ich habe großen Respekt vor der Programmiererfahrung die hier im Forum vertreten ist und ich bin Dankbar für die viele Hilfsbereitschaft. Ich habe nur das Gefühl das viele Antworten von einem relativ starkem Information-Bias ala "Pascal ist viel Geiler als die andrern" durchsetzt ist. Das nervt mich als pragmatischer Pascaleinsteiger schon relativ dolle.
Pascal ist sicherlich eine hervoragende Programmiersprache die es vom aspekt des Sprachdesigns sicher locker mit C/C++ aufnehemn kann. Ich habe die Sprache auch nicht ohne Grund für mein derzeitiges Projekt gewählt. Die Gründe, welche allerdings häufig für die Überlegenheit von Pascal angeführt werden scheinen für mich nur Geschmackssache zu sein.
Die anderen Sprachen, insbesondere die modernerneren die zunächst auf virtuelle maschinen kompiliern sind auch auf ihre Art elegant und haben ihre verdiente existenzberechtigung.

Wie auch immer. Mein Ursprüngliches Problem ist auf jeden fal gelöst. Vielen Dank nochmal!
Da das hier nicht mehr wirklich zum Thema gehört können wir das bei interesse auch an anderer Stelle weiterdiskutieren.
Auf jeden Fall nichts für ungut!

[Warf]

Also ich hatte mit Python nie probleme mich mit mehreren Klassen in einer Quelltextdatei zurechtzufinden. Da in Python den Kontrollfluss über Codeeinrückungen gesteuert wird, ist der Quelltext automatisch recht ordentlich formatiert und daher gut lesbar. Klammern sind Meiner meinung nach dabei absolut überflüssig. Es ist nur eine Frage wie gut man an das Aussehen von Python Quelltext gewöhnt ist. Ich hab mal ein umfangreichers Tool mit Python und eclipse entwickelt und bin nach einiger Eingewöhnung wirklich super zurecht gekommen.

Na dann hast du aber noch nie mit jemandem zusammengearbeitet der einen etwas anders Konfigurierten Editor hat. Z.B. jemand erstellt ein Script mit Tabs und an manchen stellen 4 leerzeichen. Bei seinem Editor hat er nicht eingestellt das Tabs zu Leerzeichen konvertiert werden sollen. Ich will nun dieses Script laden, hab ein Tabbreite von 2 und eingestellt das Tabs automatisch zu Leerzeichen Konvertiert werden. Jetzt lade ich das Script und mein Editor macht aus allen Tabs 2 leerzeichen und tada das gesammte script ist kaputt. Ich finde Einrückung ist die beschissenste Möglichkeit Blöcke zu trennen, da das komplett vom Editor abbhängig ist.

Ähnliches kann ich aufgrund identischer IDE auch für Java sagen. Auch in eclipse gibt es ein Equivalent des "CodeExplorer". Damit lässt sich absolut komfortabel durch die Funktionen einzelner Klassen navigieren.

Klar zusammen mit den JavaDoc kommentaren ist das ganz praktisch. Aber nur solange man Eclipse hat. Wenn ich über ssh meine Software fernwarten muss und kein GUI zur verfügung hab (aktuell hab ich sehr oft den Fall) kann ich immernoch mit VIM in den Header schauen und über die Suchen funktion zu Klasse.Funktion springen (selbes gilt natürlich auch für C(++) wo man nach Klasse::funktion suchen muss). In Java braucht man eine IDE um sich zurrecht zu finden sobald man mehrere Klassen mit funktionen mit gleichem Namen in einem Dokument hat.

Das C++ das Aufteilen einer Klasse in mehrer Quelltextdateien erlaubt ist mir noch nichtmal in den Sinn gekommen. Das würde ich wahrscheinlich auch eher vermeiden. Bin aber auch nicht so der C++ experte. Hab mal n bissel mit codeblocks rumprobiert. Das auswerten der Header dateien hat diese IDE da absolut problemlos hinbekommen. habe allerdings auch kein umfangreiches Projekt implementiert.

Man kann das machen wenn man z.B. Plattformabbhängigen Code hat, das man dann den in eigenen Dateien implementiert, und dann im Makefile angibt welches bei welcher Plattform verwendet werden soll. Empfehlen würde ich es aber auch nicht

Und ich arbeite grade mit einem Projekt bei dem KDevelop und CodeBlocks die include files gar nicht findet, in XCode ich alle einzeln angeben muss, und VisualStudio für die Completion und Syntax Highlight zwar alles findet, zum Jumpen durch den Code aber plötzlich nichts mehr findet. Liegt aber vor allem daran das die Include dateien in verschiedenen ordnern liegen und das CMAKE script mittlerweile so komplex ist das VS es nicht mehr korrekt verstehen kann.

Soweit ich es verstanden habe müssen in C++ auch die Funktionsprototypen nicht zwangsläufig in Header-Dateien ausgelagert werden, sondern können auch auf Modulebene stehen. Die Header-Datein bieten nur eine Form des Information-hiding. Sie erlauben es auf einfache weise eine Schnittstelle zu veröffenlichen ohne dabei die Implementation zu zeigen. Im C++ Kontext ist das wohl auch hilfreich aufgrund der C++ Linking-Strategie? K.A. Kenne mich nicht so richtig aus.

Genau in C/C++ ist externes Linken nicht teil der Sprache. Wenn man Funktionen aus anderen Dateien verwenden will, muss man dafür einen Prototypen im eigenen Code implementieren der dann gegengelinkt werden kann. Das gegenlinken macht man dann aktiv beim Kompilieren:

Code: Alles auswählen

# Kompilieren:
$ gcc -c main.c other.c
# linken
$ gcc -o execname main.o other.o

Weshalb die Verwendung von IDE's oder makefiles praktisch pflicht ist.

#include lädt dann einfach nur den Inhalt einer Datei und fügt ihn an dieser stelle ein. Daher dürfen im header nur Typen und virtuelle (bzw auch inline in C++) funktionen stehen, da man sonst den tatsächlichen Code mehrfach unter selben namen kompilieren würde.

Man kann sogar die Prototypen ganz weglassen und die Funktionen einfach so aufrufen, man wird dann aber (zurecht) mit Warnings überschüttet

In Pascal oder Java wird durch das Importen einer Unit im Quelltext bereits dem Compiler gesagt was er zu linken hat, ist daher alles auf Sprachebene gelöst, weshalb man sich als Programmierer darum keine gedanken machen muss.

Grundsätzlich stimme ich auch zu dass es Sinn ergibt inhaltlich zusammenhängende Klassen in einer Datei zu behalten. Ich bin aber gleichzeitig der Meinung dass es auch gründe geben kann einzelne Klassen strikt in einzelne Quelltextdateien aufzuteilen. M.E. ist dass z.B. sinnvoll wenn bei abgeleiteteten Klassen potentiell sehr viele Subklassen entstehen und die genaue Anzahl zunächst unbekannt ist bzw. sich über die Projektlebensdauer von Zeit zu Zeit erweitert. So braucht wie zuvor schon angeführt der bereits geschriebene code überhaupt nicht mehr angefasst werden.

Ich geh da anders ran. Ich fang immer mit einer Unit an und sobald ich eine neue Art von Klassen schreibe oder mir die Datei zu groß wird erstell ich dann eine neue und kopiere eventuell ein paar Sachen in die Neue Datei.

Bitte versteht mich nicht Falsch! Ich habe großen Respekt vor der Programmiererfahrung die hier im Forum vertreten ist und ich bin Dankbar für die viele Hilfsbereitschaft. Ich habe nur das Gefühl das viele Antworten von einem relativ starkem Information-Bias ala "Pascal ist viel Geiler als die andrern" durchsetzt ist. Das nervt mich als pragmatischer Pascaleinsteiger schon relativ dolle.
Pascal ist sicherlich eine hervoragende Programmiersprache die es vom aspekt des Sprachdesigns sicher locker mit C/C++ aufnehemn kann. Ich habe die Sprache auch nicht ohne Grund für mein derzeitiges Projekt gewählt. Die Gründe, welche allerdings häufig für die Überlegenheit von Pascal angeführt werden scheinen für mich nur Geschmackssache zu sein.
Die anderen Sprachen, insbesondere die modernerneren die zunächst auf virtuelle maschinen kompiliern sind auch auf ihre Art elegant und haben ihre verdiente existenzberechtigung.

Ich bin da vollkommen bei dir und Pascal ist definitiv nicht die beste Sprache und ich entscheide mich für jedes neue Projekt das ich starte immer für die beste Sprache für das Projekt. Und tatsächlich ist Java eine meiner Lieblingssprachen. Java zwingt einen Zwar dazu extrem viele Dateien mit einzelnen Klassen zu erzeugen, ist (wie ich oben erklärt habe) aber ja auch notwendig, daher sehe ich das auch nicht als Problem an. Bei Java muss ich mir kaum Gedanken machen ob ein Paket seit Jahren veraltet ist, weil einfach das meiste Teil des Java Frameworks ist. Noch dazu ist Java extrem simpel gehalten kann aber dennoch alles was man braucht.
Aber wenn es um Code Organisation und Lesbarkeit geht ist Pascal (und auch Ada und konsorten) deutlich besser als praktisch alle anderen Sprachen die ich kenne. Pascal wurde als Lehrsprache konzipiert und das merkt man deutlich, alles ist strikt organisiert und forciert damit eine gewisse Lesbarkeit. Unter den C-Artigen Sprachen ist das am ehesten vergleichbar mit Java, welches ja auch sehr strikt ist (im vergleich zu C++), aber insgesamt muss ich sagen, Wenn ich keine IDE habe und mir ein C++, ein Java und ein Pascal Projekt ansehe, ist das Pascalprojekt definitiv das dessen struktur ich am einfachsten verstehen werde.

Ich arbeite mittlerweile sehr oft nur mit Vim in C++ und muss sagen, ohne Header als praktische (und kommentierte) zusammenfassung würde man da komplett wahnsinnig werden.

[Arthur Dent]

Ich bin da vollkommen bei dir

Puh da bin ich foh! Wollte echt keine schlechte Laune verbreiten aber manchmal kommt das ja auch falsch an.

Wenn ich keine IDE habe und mir ein C++, ein Java und ein Pascal Projekt ansehe, ist das Pascalprojekt definitiv das dessen struktur ich am einfachsten verstehen werde.

OK, das kann ich nachvollziehen.
Zu meiner Schande muss ich gestehen dass ich diesbezüglich evtl. selber ein wenig einseitig geprägt bin. Anwendungsfälle bei denen ich ohne IDE arbeiten muss sind für mich quasi nicht existent. Daher wäre mir nicht in den Sinn gekommen darüber nachzudenken. Dein Punkt finde ich aber total plausibel.

[kupferstecher]

Bitte versteht mich nicht Falsch! Ich habe großen Respekt vor der Programmiererfahrung die hier im Forum vertreten ist und ich bin Dankbar für die viele Hilfsbereitschaft. Ich habe nur das Gefühl das viele Antworten von einem relativ starkem Information-Bias ala "Pascal ist viel Geiler als die andrern" durchsetzt ist.

(Free-)Pascal ist aber viel geiler als die anderen!

Nach meiner Empfindung ist es jedoch gerade nicht so, dass eine Haltung "alles andere ist Sch#*%e" dahintersteckt, sondern eher eine gegenseitige- und Selbstbestärkung. Die auch notwendig ist, schließlich handelt es sich bei der Pascalcommunity nicht gerade um die größte.