Welche Programmiersprachen gefallen euch neben C und C++?

muemmel

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.

audacia

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!

Bitte ein Bit

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?

Zee++ 0

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?

Mechanics

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.

Fytch

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.

muemmel

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

Burkhi

muemmel schrieb:

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

...sowie C++ Builder

muemmel

Hi Burkhi,

sind ja fast eineiige Zwillinge. Keine Ahnung, wie es derzeit ist, aber in früheren Ausgaben waren die Compiler bis auf den Parser identisch.
Wenn man das RAD-Studio hat, kann man beide ja nach Bedarf und jeweiligem Einsatzzweck einsetzen.
Tempomäßig muss sich auch Delphi nicht groß hinter der C++-Version verstecken.
Man kann problemlos eigene Komponenten erstellen, für die aus meiner Sicht Delphi die passendere Sprache ist, weil auch die Ausgangskomponenten in Delphi geschrieben sind.
Undfür kleine Anwendungen mit Formularoberfläche und Datenbankanbindung ist Delphi aus meiner Sicht das geeignetere, wären für große Projekte die Leistungsfähigkeit von C++ dann ausschlaggebend sein dürfte.
Soweit ich das sehe, sind damit sogar Mischprojekte möglich.

Gruß Mümmel

audacia

muemmel schrieb:

in früheren Ausgaben waren die Compiler bis auf den Parser identisch.

Dafür hätte ich gerne einen Beleg.

muemmel

Hi Audacia,

audacia schrieb:

muemmel schrieb:

in früheren Ausgaben waren die Compiler bis auf den Parser identisch.

Dafür hätte ich gerne einen Beleg.

Meinst Du wirklich, wenn ich das irgendwo in der Ct oder iner Dokumentation von borland lese mache ich mir gleich einen Hinweis auf ein ganz großes Merkblatt, für den Fall dass Audacia das 15 Jahre später vielleicht mal wissen möchte?

Gruß Mümmel

SLx64

Chapel hat viele interessante Features und für wissenschaftliche Anwendungen sehr angenehm.

audacia

muemmel schrieb:

Meinst Du wirklich, wenn ich das irgendwo in der Ct oder iner Dokumentation von borland lese mache ich mir gleich einen Hinweis auf ein ganz großes Merkblatt, für den Fall dass Audacia das 15 Jahre später vielleicht mal wissen möchte?

Nun, eingedenk der Tatsachen, daß die beiden Sprachen nur sehr überschaubare oberflächliche Gemeinsamkeiten haben, daß Delphi noch recht lange single-pass kompiliert werden konnte, daß das Übersetzungsmodell wie oben beschrieben vollkommen anders ist (Makefile, Headerdateien, Compiler & Linker vs. ordentliches Modulsystem und integrierter Buildprozeß) etc., sollte diese Behauptung jedem mit beiden Sprachen einigermaßen Vertrauten als eine steile These vorgekommen sein. Es kann sein, daß die beiden Compiler irgendwo im 32-Bit-x86-Backend ein bißchen Code teilen. Aber "bis auf den Parser identisch"? Deshalb hatte ich hinter einer solchen Tatsachenbehauptung etwas Fundierteres erhofft als "irgendwo mal gelesen".

Auch die Entwicklungsgeschichte spricht nicht für solch eine These. Soweit ich weiß, ist der moderne 32-Bit-Delphi-Compiler eine Fortentwicklung des Compilers, der für Delphi 2 eigens zugekauft wurde. Der 16-Bit-Vorgänger in Delphi 1 war noch der in Assemblercode geschriebene, für Delphi um ein neues Objektmodell erweiterte alte Turbo Pascal-Compiler. Der ursprüngliche C++Builder-Compiler hingegen war der um die bekannten Delphi-kompatiblen Spracherweiterungen angereicherte Nachfolger von Borland C++, und die nachfolgenden Versionen waren Weiterentwicklungen davon. Mittlerweile wurde er von Clang abgelöst.

Bei dieser Informationslage bin ich zu schließen geneigt, daß es sich wohl um ein Mißverständnis handelt.

muemmel

HI Audacia,

da war ich tatsächlich einer Zeitungsente aufgesessen. Das war eine Erfindung "Postfaktischer Journalisten".
Aber wenn ich Herrn Eissing von Embarcadero richtig verstanden habe, können die aktuellen Compiler wohl auch Ausdrücke der jeweils anderen Sprache auswerten. Aber da will ich mich jetzt nicht festlegen, dass ich ihn jetzt richtig verstanden habe.

Dumm nur, wenn man Rad-Studio nur in der Verison XE2 hat, und der CLang-Compiler erst ab Version XE3 inbegriffen ist. Vom aktuellen hab ich leider nur Delphi. Na kommt Zeit kommt RAD.

Gruß Mümmel