Welche Programmiersprachen gefallen euch neben C und C++?

Zeus

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...

So Ähnlich ... warum in D DI File existieren.

Finnegan

Artchi schrieb:

Das ist ja mal das blödeste Argument: OOP in einer Nicht-OO-Sprache durch zusätzliche Krücken betreiben. Nein, da kann ich ja auch sagen "Das tolle an C und ASM ist, das ich da auch mit Hilfsmitteln OOP machen kann."

Das ist ein sehr oberflächliches Urteil: Das Kernargument war nicht dass man OOP irgendwie dazufrickeln kann, sondern dass man es am Ende "gar nicht mehr merkt, dass die Sprache kein OOP direkt unterstützt". Mein Satz war zwar etwas holprig formuliert, aber die Information lässt sich durchaus noch herausdestillieren. Das C-Analogon dazu wäre dass man nach einem "#include <oop.h>" glaubt, in C++ weiter zu programmieren (zumindest was Objektorientierung angeht).

Artchi schrieb:

Eine Sprache soll MIR Arbeit abnehmen! Warum soll ich der Sprache Arbeit abnehmen? Wenn ich OOP machen will, nehme ich eine OO-Sprache. Davon gibt es reichlich zur Auswahl, z.B. AngelScript.
Und wenn Lua mir keine OO-Features anbietet, dann mache ich das damit auch nicht. Ich benutze Lua so, wie es gedacht wurde: für Scripte und Konfigurationen. Dafür ist Lua 1A geeignet.

Ich sehe das nicht so eng: Ich empfinde die Abstraktionen, die OOP ermöglicht, auch in kleineren Skripten als sehr praktisch. Es reicht die Funktionalität einmal zu implementieren, und dann eine kleine Datei einzubinden, wenn man sie benötigt (include von einmal geschriebenen ~100 Zeilen). Sicher braucht man das nicht immer, und ich bin auch kein Freund davon, es mit der OOP allzu wild zu trieben, wie es beispielsweise Java tut. Ich implementiere in Lua allerdings die Logik diverser Objekte in einer 3D-Welt, und dort kommt mir das durchaus gelegen, da man damit von der Programmstruktur her elegant ein Interface and die "Weltobjekte" flanschen kann.

Artchi schrieb:

Finnegan schrieb:

Was ich an Lua nicht mag, ist dass Indizes mit 1 beginnen - bei den ganzen zusätzlichen "+1/-1" zur Korrektur bei Index-Berechnungen merkt man schon, dass bei 0 zu beginnen, die "natürlichere" Variante ist, besonders wenn man viel mit Indizes und "Ranges" hantiert.

Ehm, jeder nicht Informatiker oder C-lastige Programmierer fängt bei 1 an zu zählen. Sage einem Schüler "Zähl mal bitte bis 10!", und er wird nicht mit "0" anfangen. Selbst jeder Informatiker wird in der Freizeit bei 1 anfangen zu zählen.

Ich verstehe die Argumentation dahinter, mit 1 anzufangen, geschenkt. Meine persönliche Erfahrung damit ist allerdings, dass damit Indexberechnungen oft komplizierter wurden, so dass ich es letztendlich eher als Nachteil empfand. Das kann allerdings auch vornehmlich an dem liegen, was ich implementiert habe, vielleicht fällt es in anderdem Code weniger auf. Als typisches Beispiel sei hier die Adressierung von Elementen in einem eindimensionalen Array genannt, welches ich als zweidimensionale, x/y-adressierte Matrix interpretieren möchte:
So etwas wie i = ((y - 1) * width + (x - 1)) + 1 anstatt i = y * width + x ist mir halt oft genug untergekommen*, um meinen Mißmut über die Array-Adressierung auf das derzeitige Level zu steigern. Ich komme damit klar, aber "mögen" tue ich es deshalb nicht.

*Nachtrag: Wenn ich mir das gerade nochmal so ansehe, fällt mir auf, dass ich die Berechnung nicht wirklich vereinfacht habe, das Beispiel ist also nicht so gut gewählt ... dennoch hatte ich immer den Eindruck, dass solche -1/+1-Korrekturen für den Index häufiger notwendig sind, als in vergleichbarem Code in Sprachen, wo Arrays bei 0 beginnen. Für mich sind dadurch einige Algorithmen oft ein wenig unübersichtlicher geworden, obwohl ich zugebe, dass das auch Gewöhnungssache sein kann. Und auch wenn es subjektiv sein mag: Das "nicht mögen" ist nicht unbegründet

Artchi schrieb:

Finnegan schrieb:

Auch dass alle numerischen Berechnungen mit double -Werten erfolgen stört mich, allerdings auch nur da ich die Sprache in einem System einsetze, wo ich viel mit int64 -Werten zu tun habe, deren Wertebereich auch voll ausgenutzt wird. Diese lassen sich in Lua in Gegensatz zu int32 , nur sehr umständlich korrekt mit double -Werten abbilden.

Verstehe ich nicht, wie das funktionieren soll? Da sollten doch irgendwann falsche Berechnungen bei dir auftauchen?

Man bildet den int64 mit zwei number -Werten ab, und kümmert sich "manuell" um Übertrag bei Berechnungen (auch hier ist selbstgebaute OOP mit überladenen Operatoren hilfreich). Unterm Strich ist das de facto schon eine kleine BigInt-Implementierung, daher "umständlich". Ich denke dass sich 32-bit-integer-Operationen korrekt mit double -Werten implementieren lassen ist dir bewusst (?).

Artchi schrieb:

Warum kompilierst du das Lua nicht einfach mit dem passenden int64? Immerhin kann man das durch ein Makro bei Lua machen. Auf alten Systemen ohne FPU wird Lua meistens mit int32 kompiliert, weil Fließkomma da nur mit Emulation funktionieren würde und zu langsam wäre. Dann solltest du Lua auch an deine Bedürfnisse anpassen können...

Das wäre eine Möglichkeit, allerdings benötige ich auch Fließkommaberechnungen*, daher ist den number -Typen komplett durch int64 zu ersetzen keine gute Lösung. Da ich LuaJIT verwende, nutze ich derzeit den von dieser Implementation zur Verfügung gestellten 64-bit-Datentypen. Dennoch wäre es mir lieber wenn so etwas von der Sprache direkt unterstützt würde.

* Das hägt in meinem Fall mit den absoluten Weltkoordinaten zusammen, die ich verwende. Das System unterstützt sehr große Welten, daher ist eine absolute Weltkoordinate ein ( int64 , float )-Paar, da reine Fließkomma-Werte auf große Entfernungen eine zu hohe Ungenauigkeit hätten. Die meisten Berechnungen werden zwar in relativen Koordinaten und definitiv nicht mit Lua durchgeführt, dennoch ist es hilfreich, wenn sich solche Koordinaten ohne allzu viel Gepfriemel auch mit Lua handhaben lassen.

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.

Tyrdal

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.

Schlangenmensch

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.

Artchi

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!

muemmel

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

muemmel

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

Zee++ 0

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.

Mechanics

Zee++ schrieb:

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

Träum weiter

Fytch

Zee++ schrieb:

Welche Programmiersprachen gefallen euch neben C und C++?

Echte Männer programmieren in APL.

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.