Arthur Dent hat geschrieben: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.
Arthur Dent hat geschrieben:Ä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.
Arthur Dent hat geschrieben: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.
Arthur Dent hat geschrieben: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.
Arthur Dent hat geschrieben: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.
Arthur Dent hat geschrieben: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.