Welche Programmiersprachen gefallen euch neben C und C++?



  • Zeus schrieb:

    zufallswert schrieb:

    muemmel schrieb:

    Das ist in Delphi um Welten besser gelöst:
    Da hat jede Datei einen "Headder-Teil" und einen "Programm-Teil"

    und was ist, wenn man an eine externe Library linken will, deren Quellcode nicht offen ist? In C/C++ reichen dem Compiler dazu die Header. Wie ist das in delphi?

    Du weisst schon dass die VCL in der Starter Edition ohne Quellcode geliefert wird? Es ist kein Problem...

    davon gehe ich mal aus, daß es kein Problem ist. Aber wenn muemmel erklärt, daß es ein Vorteil von delphi sei, daß der Header Teil des Implementationsfiles ist, wie geht das dann beim Anbinden von nicht-offenen Libraries? In C/C++ braucht man dazu nur den Header, nicht die Implementation.



  • muemmel schrieb:

    Hi Artchi,

    Artchi schrieb:

    Der Header-Quatsch ist so ziemlich das einzige wofür ich C++ hasse.

    Eindeutig schlechtes Sprachdesign. 😉

    Das war der schwachen Hardware damals geschuldet.



  • Artchi schrieb:

    Schlangenmensch schrieb:

    Zee++ schrieb:

    Ist eigentlich mal anzusehen ob bei C und C++ dieser Header/Source Quatsch weg fällt? Wir haben 2017, da muss man sich sowas nun wirklich nicht mehr freiwillig antun.

    Zwingt dich ja keiner zu. Kannst doch alles in cpps schreiben... 🙄

    Nein, kann man eben nicht. Außer du willst ihn in die Pfanne hauen, das er eine riesige Datei hat. Was aber keine Lösung ist. Es geht um Lösungen, nicht um Unsinn.

    Selbstverständlich war das nicht 100%ig ernst gemeint. Aber es ist perfekt legal auch cpp Dateien zu includen. Dann hat man nicht mal alles in einer Datei, auch wenn der Kompiler das dann alles zusammen zieht.

    Aber ansonsten finde ich die C++ Lösung gar nicht mal so schlecht. Ich kann mir in der einen Datei in Ruhe anschauen, welche Funktionalität bereit gestellt wird, muss mich aber um die Implementierungsdetails nicht kümmern, welche schön gekapselt in einer cpp Datei liegen.



  • Naja, es gibt ja heute IDEs die einem eine super Übersicht über die Schnittstellen anzeigen, da muss ich nicht extra eine Header-Datei schreiben/anbieten. Das Argument ist doch heute obsolet.

    Viele Argumente sind doch welche aus den 1970er Jahren, als es keine Rechenleistung gab. Geschenkt! Die Argumente kommen mir immer trotzig vor, und nicht ehrlich. Aber heute langweilen sich die Entwicklungs-PCs die meiste Zeit.

    Und die Header-Dateien widersprechen dem DRY-Prinzip (Don't Repeat Yourself). Ich muss code doppelt pflegen und synchron halten. Damals musste man da den Compiler und Computer unterstützen, weil der zu wenig Leistung hatte. Aber heute erwarte ich, das die Sprache mir verdammt nochmal die Arbeit abnimmt in dem ich nur eine Datei habe! Ich will am eigentlichen zu lösenden Problem arbeiten und nicht an einem Problem aus den 1970er. Sobald ich eine Signatur ändere/hinzufüge, muss ich das in einer zweiten Datei tun? Horror!



  • Hi Zufallswert,

    zufallswert schrieb:

    Aber wenn muemmel erklärt, daß es ein Vorteil von delphi sei, daß der Header Teil des Implementationsfiles ist, wie geht das dann beim Anbinden von nicht-offenen Libraries? In C/C++ braucht man dazu nur den Header, nicht die Implementation.

    Dafür gibts dann extra .pas-Dateien, bei denen der Implementierungsteil leer ist.

    Gruß Mümmel



  • Hi Artchi,

    Artchi schrieb:

    Ich muss code doppelt pflegen und synchron halten.

    Ja und es besteht immer die Gefahr, dass man zwei nicht zueinander gehörende Dateien verwendet.

    Gruß Mümmel



  • Artchi schrieb:

    Ich muss code doppelt pflegen und synchron halten. Damals musste man da den Compiler und Computer unterstützen, weil der zu wenig Leistung hatte. Aber heute erwarte ich, das die Sprache mir verdammt nochmal die Arbeit abnimmt in dem ich nur eine Datei habe! Ich will am eigentlichen zu lösenden Problem arbeiten und nicht an einem Problem aus den 1970er. Sobald ich eine Signatur ändere/hinzufüge, muss ich das in einer zweiten Datei tun? Horror!

    Zum Glück haben sich Programmiersprachen weiterentwickelt. Kotlin macht das nicht schlecht, zumal mit Kotlin Native auch noch nach Bare Metal gegriffen wird. Ich finde es toll, wenn eine Sprache sowohl mit einem JIT als auch native verwendet werden kann. Was für Smartphones reicht, sollte auch für das meiste andere reichen.

    Ich denke C++ in der jetzigen Form wird immer mehr zur Nische, die gern gemieden wird. Das macht man nur noch wenn es gar nicht anders geht. Da wird dann ausgelost wer ins C++ Team muss. 😃



  • Zee++ schrieb:

    Ich denke C++ in der jetzigen Form wird immer mehr zur Nische, die gern gemieden wird.

    Träum weiter 😉



  • Zee++ schrieb:

    Welche Programmiersprachen gefallen euch neben C und C++?

    Echte Männer programmieren in APL. 😉



  • Hi Fytch,

    Fytch schrieb:

    Zee++ schrieb:

    Welche Programmiersprachen gefallen euch neben C und C++?

    Echte Männer programmieren in APL. 😉

    Ne FORTRAN

    Gruß Mümmel



  • Assembler :p 🙄 😮 😕 🕶 🤡 😋 👍 💡 ➡



  • Artchi schrieb:

    Und die Header-Dateien widersprechen dem DRY-Prinzip (Don't Repeat Yourself).

    Tun sie im allgemeinen nicht. Die Funktions-Prototypen in den Headern zum Beispiel sind ein *Versprechen* gegenüber dem Compiler, daß der Linker später irgendwo Objectcode mit den zugehörigen Implementationen finden wird. Ähnlich mit extern deklarierten Variablen.

    Der Compiler kann es nicht prüfen, weil er nicht alle beteiligten Object files kennt - die kennt erst der Linker. Der kommt aber erst zum Schluß dran, nachdem der Compiler Objectcode erzeugt hat.

    Um alle Prototypen überflüssig zu machen, müßte der Compiler Objectfiles lesen können, um aus diesen die Funktions-Signaturen etc. der darin definierten Funktionen auszulesen. Das ist aber nicht seine Aufgabe.

    Oder der Compiler würde eben die Prüfung unterlassen, daß Funktionsaufrufe externer Funktionen zu deren Signaturen passen; dann könnte Objectcode mit Funktionsaufrufen entstehen, die nicht zu den Signaturen der Funktionen passen.
    Auch nicht gut - dann lieber frühzeitige Prüfung.

    Ich sehe also keinen widerspruch zum DRY-Prinzip auf der Grundlage einer 3-stufigen Kompilierung (Präpro, Compiler, Linker).

    Wäre der Compiler gleichzeitig Linker, wäre es etwas Anderes.

    Class Templates in Header-Dateien widersprechen erst recht nicht dem DRY.



  • zufallswert schrieb:

    und was ist, wenn man an eine externe Library linken will, deren Quellcode nicht offen ist? In C/C++ reichen dem Compiler dazu die Header. Wie ist das in delphi?

    Delphi folgt nicht dem klassischen C-Compilermodell mit preprocessing, compiling, linking stage; der ganze Buildprozeß wird auf Sprachmittel abgebildet und vom Compiler gesteuert. Es wird unterschieden in Units (.pas, einzelne Source-Dateien), Programme (.dpr, die zentrale Source-Datei eines Anwendungsprogramms) und Packages (*.dpk, sowas wie eine Klassenbibliothek in .NET):

    unit MyUnit;
    
    interface
    
    uses
      SomeOtherUnit;
    
    procedure PublicProcedure;
    
    implementation
    
    uses
      SomePrivatelyUsedUnit;
    
    procedure PrivateProcedure;
    begin
      Writeln('Hello, world!');
    end;
    
    procedure PublicProcedure;
    begin
      PrivateProcedure;
    end;
    
    end.
    
    package MyPackage;
    
    requires
      SomeOtherPackage;
    
    contains
      MyUnit,
      SomeOtherUnit;
    
    end.
    
    program HelloWorldVCL;
    
    uses
      MyUnit;
    
    begin
      PublicProcedure;
    end.
    

    Beim Übersetzen einer Unit erzeugt der Delphi-Compiler ein compiled unit (*.dcu). Das ist ein binäres Zwischenformat, das sowohl die Schnittstellendefinition der interface-Sektion als auch den compilierten Code enthält.

    Beim Übersetzen eines Packages erzeugt der Compiler ein compiled package (.dcp) und eine package library (.bpl). Ersteres enthält die Schnittstellendefinition, letzteres den compilierten Code. Aus Sicht des Betriebssystems ist die package library eine DLL.

    Beim Übersetzen eines Programms erzeugt der Compiler eine ausführbare Datei (*.exe).

    Da der Compiler den Abhängigkeitsgraphen für Units und Packages kennt, weiß er, welche Units er neu übersetzen muß, wenn sich etwas geändert hat. Bei Änderungen im implementation -Teil einer Unit müssen davon abhängige Units gar nicht neu übersetzt werden, sondern nur die ausführbare Datei bzw. die Package-Library wird neu erzeugt.

    Will man eine Komponente ohne Quellcode ausliefern, so kann man die compiled units oder die compiled packages zusammen mit den package libraries verteilen. (Für die Kompatibilität mit C++Builder sollte man zusätzlich die automatisch erzeugten *.hpp-, *.obj-, *.lib- und *.bpi-Dateien ausliefern.)

    Dieses schöne Konzept hat leider den Makel, daß das Dateiformat für compiled units und compiled packages recht volatil und compiler-versionsspezifisch ist. Ein Komponentenhersteller muß also einen Satz *.dcu-, *.dcp- und *.bpl-Dateien für jede unterstützte Delphi-Version ausliefern, und die interface-Abschnitte aller ausgelieferten Units dürfen in Updates nicht verändert werden.

    .NET löst das Versionierungsproblem, indem Offsets (z.B. VMT-Slotindices, Feld-Offsets, Sprungadressen) erst vom Type-Loader zur Laufzeit festgelegt werden, was wiederum für effiziente Ausführung einen JIT-Compiler erfordert.



  • interessant!



  • Und die Header-Dateien widersprechen dem DRY-Prinzip (Don't Repeat Yourself). Ich muss code doppelt pflegen und synchron halten.

    Naja Header Dateien sind bei mir eine Art dokumentierte Schnittstellen-Definition. Ein Blick in die Doxygen Doku zu ABC.h und du weißt was ABC.cpp macht.

    Ist aber reine Geschmackssache.

    ---

    Ich wäre ansonsten für C# da die Lib bzw. das .Net Framework riesig ist. Aber eigentlich finde ich Java cool. :p

    Kotlin mag ich aufgrund des Namens schon nicht.

    PS:
    Richtige Männer programmieren auf einer neunbändigen Turingmaschine. 🤡



  • kriegst du da Mengenrabatt beim Einkauf von Endlosband?



  • Würde hier wirklich einen ein neues Projekt in C++ anfangen, wenn sich auch einen anderen Sprache wie Java oder C# anbieten würde?

    Allein gute Programmierer zu finden, die C++ wirklich gut beherrschen, ist ja wohl schon fast unmöglich. So wie ich es bis jetzt verstanden habe, sind selbst viele Autoren von C++ Fachbücher total überfordert und bringen da so einiges durcheinander. Und solch einer Sprache soll ich dann der Zukunft meiner Firma freiwillig anvertrauen? Wer ist denn bitte soooo blöd?



  • Zee++ schrieb:

    Würde hier wirklich einen ein neues Projekt in C++ anfangen, wenn sich auch einen anderen Sprache wie Java oder C# anbieten würde?

    Ja, glaubs halt, ich würde auf jeden Fall C++ bevorzugen 😉 Und ich hab jahrelang in C# programmiert, ich vermisse das nicht.



  • Zee++ schrieb:

    Würde hier wirklich einen ein neues Projekt in C++ anfangen, wenn sich auch einen anderen Sprache wie Java oder C# anbieten würde?

    Ja, u.a. ich. C++ ist die Lingua Franca im Bereich des High Performance Computing, weil sie sehr hohe Abstraktionen ohne Performanceeinbußen erlaubt. Ferner zwingen einem Java und C# einen GC auf und laufen in einer VM. Nein, danke!

    Zee++ schrieb:

    Allein gute Programmierer zu finden, die C++ wirklich gut beherrschen, ist ja wohl schon fast unmöglich.

    Nein.

    Zee++ schrieb:

    Und solch einer Sprache soll ich dann der Zukunft meiner Firma freiwillig anvertrauen? Wer ist denn bitte soooo blöd?

    lol. Nenn mir (außer C) eine Sprache mit besseren Tools (Compiler, Debugger, IDEs, Sanitizer, ...) und besseren Bibliotheken.



  • Hi Fytch,

    Fytch schrieb:

    , Nenn mir (außer C) eine Sprache mit besseren Tools (Compiler, Debugger, IDEs, Sanitizer, ...) und besseren Bibliotheken.

    Delphi. 🙂

    Gruß Mümmel


Anmelden zum Antworten