Welche Sprache kann C++ Konkurrenz machen?
-
Die Entwicklung in C++ geht weiter, aber für mich persönlich hat es zu viele Stolperfallen und sie ist alles andere als schlank, was zu einem "Mental Overhead" führt. Man muss viele Kapazitäten der Sprache anstatt dem Problem widmen und selbst wenn man selbst versucht modernes C++ anzuwenden, gibt es immer noch Kollegen, die
#define
und alte Features verwenden und es kostet einen immer wieder Zeit darauf hinzuweisen, man soll bspw.constexpr
verwenden etc.Ich finde Rust hat auch viel Mental Overhead, dafür garantiert es Speichersicherheit und Freiheit von Data Races zur Compilezeit.
Zig will das bessere C sein und hat auch C++ Features wie Metaprogramming, ist aber noch in den Kindernschuhen.Welche der Sprachen findet ihr am interessantesten oder seid ihr 100 Prozentige C++ Enthusiasten?
-
Stimme ganz und gar zu. C++ ist "zu aufgebläht". Es gibt eigentlich nur einen Grund, um es zu verwenden, und das ist dessen Schnelligkeit und Hardwarenähe.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
Welche der Sprachen findet ihr am interessantesten oder seid ihr 100 Prozentige C++ Enthusiasten?
Lazarus/FPC, ich bin ein voller Enthusiast dieser Sprache.
Der Code der BIN ist vergleichbar mit der welche von C/C++ erzeugt wird. Der Compiler selbst ist zig mal schneller als der von C/C++. Dies merkt man besonders bei grossen Projekten.
Das mühsame herumschlagen mit Code und Headern entfällt.Strenge Typenprüfung, daher weniger Memory-Fehler.
Sehr gute Untersützung von dynamischen Arrays und String.Sehr gute Plattformübergreifbarkeit zwischen Linux/Mac und Windows, dies auch bei sehr komplexen GUI-Anwendungen. Sehr kurze Entwicklungszeit, da man sich ums wesentliche kümmern kann, anstelle das man viel Zeit verliert, eine GUI zusammenzustellen. Betrifft auch die Kompilierzeit.
Auch Programmierung von Mikrocontrollern möglich.
Gute Anbindung möglich an libs, welche mit C erstellt wurden (POSIX).
Ich wüsste nichts, was Pascal nicht kann, was C kann, ausser Treiber-Entwicklung.
Aber unter dem Strich ist es auch Geschmacksache, mit was man codet.
-
@Mathuas Gibt es einen Grund, weshalb Pascal nie der Durchbruch gelungen ist? Kenne einige, die davon schwärmen.
-
Für HPC ist es bei mir Fortran, aber nur in der Version Fortran2003 und neuer. (Man soll bitte die Welt mit F77 oder F66 verschonen, schlimmer kann man Programme kaum schreiben.) Man muss ggf. einige Routinen mit Inline Code in C schreiben, aber für simple Funktionen ist C gut genug. In Kombination mit OpenMP, OpenACC und OpenMPI ist es für diesen Zweck sehr gut geeignet.
Was das Thema Algol artige Sprachen betrifft (Pascal, ObjectPascal(das von Apple), Modula-II, Oberon, Oberon-2, Ada83, Ada95, …) nur auf dem PC hatte sich damals Pascal in Form von TurboPascal so lange gehalten. Auf anderen Plattformen wurde es relativ schnell von Modula-II abgelöst, was wesentlich stringenter von Wirth entworfen war. Auf dem Mac wurde anfangs in einer speziellen ObjectPascal Version programmiert, die aber so ihre Macken hatte. Pascal typisch gab es keine dynamische Speicherverwaltung, sondern nur feste Arrays, die man beim Übersetzen festlegen musste. Gleiches gibt es auch bei F77.
Das DoD hat dann Ada in Auftrag gegeben, die erste noch nicht OOP Version kam 1983 heraus. Damals galt das als Monstersprache, weil es umfangreich war. Mittlerweile ist Ada sogar relativ klein im Vergleich zu anderen Sprachen. Das ist neben Rust eine der wenigen Sprachen, die sehr strenge Typisierung erlaubt und es gibt mit SPARK einen Subset für spezielle formal zu prüfende Softwareanwendungen.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
Welche der Sprachen findet ihr am interessantesten oder seid ihr 100 Prozentige C++ Enthusiasten?
Ich bin ein Freund von C++20 für offline Anwendersoftware und Python für administrative Sachen.
Jede Programmiersprache hat meines Erachtens Vor- und Nachteile und eigene Stilblüten.
Nehmen wir mal die Sprache C. Diese Sprache ist definitiv nicht aufgebläht. Dafür arbeitet man aber relativ schnell auf niedriger Ebene und muss sich so um Dinge kümmern, welche in anderen Sprachen automatisch gelöst sind. Beispiele sind da z.B. Speicherverwaltung, Container, usw. Und so sieht man relativ oft verkettete Listen in C Code oder Structs mit Pointer. Eine weitere Stilblüte finde ich z.B. auch den Zoo an
sprintf
Funktionen (bei der WinAPI). Wievielesprintf
Varianten gibt es?Oder nehmen wir mal C# (auch Java). Bei beiden Sprachen muss man nicht auf Speicherverwaltung achten und beide Sprachen kommen mit einer riesigen Lib, s.d. viele Dinge einfach sind. Jedoch hat das Schlüsselwort
new
eine andere Bedeutung wegen des Garbage Collectors. Und so ist man öfters dazu geneigtnew
inflationär zu verwenden. Ferner scheint gerade bei C# der Rückgabewert durch Exceptions ausgetauscht zu sein. Achtet man nicht darauf, so wird die Software schnell zur Absturz-freudigen Software. Und noch ein Problem welches gerade C# betrifft. Auch wenn das Ergebnis eine .exe Datei ist, so darf man doch nicht vergessen dass das Dekompilat sehr gut lesbar ist und nicht alle Namen gelöscht werden. Es dauert also nicht länger als 5 Minuten bis ein übereifriger Kunde den Kopierschutz sieht.Ein weiteres extremes Beispiel ist die Skriptsprache Visual-Lisp welche z.B. bei AutoCAD verwendet wird. Die Sprache ist auf einem uraltem Standard und dadurch tauchen diverse Stilblüten auf. Funktionen verhalten sich wie C Makros, Structs können nicht definitiert wenden, sondern müssen über assoziative Listen emuliert werden, Deklarationen können Funktionen überlagern, Klammer Orgien sind durchaus normal,...
Erkenntnisse:
- Eine gute Programmiersprache schützt nicht vor schlechten Entwicklern.
- Jede Programmiersprache hat eine eigene Sichtweise und einen eigenen Verwendungsbereich. Stellenweise trifft dies auch für Standards zu,
- Egal welche Programmiersprache besser oder schlechter ist, man ist von der lokal verwendete Sprache abhängig. Ich kann z.B. Rust nicht einführen, wenn meine aktuelle Codebasis Fortan ist.
- Je älter der verwendete Programmierstandard, desto schlechter ist meistens das Programmieren.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Mathuas Gibt es einen Grund, weshalb Pascal nie der Durchbruch gelungen ist? Kenne einige, die davon schwärmen.
Das Typensystem, in dem Arrays immer eine beim Programmieren feststehende Größe haben müssen (selbst bei indirekten Verweisen!), macht es unmöglich, generischen Code zu schreiben. Das ist ein absolutes Killerfeature, das man nicht genug betonen kann. Es gibt auch keinen Mechanismus a la void-Pointer & Casts, über den man diese Beschränkung irgendwie umgehen könnte. Das macht dann auch Libraries entsprechend schwerer/unmöglich und so führt eines schnell zum anderen und die Sprache wird bedeutungslos. Selbst wenn dann später diese Beschränkungen aufgehoben werden (wurden sie das je? Ich folge der Sprache nicht, aber das illustriert ja gerade den Punkt) interessiert das dann niemanden mehr.
Außerdem ist die Ästhetik des Codes einfach nicht gut. Es ist einfach ein Block Text ohne Zeichensetzung. Man mag Lachen, dass ich solch einen oberflächlich wirkenden Punkt aufzähle, aber ich bin sicher, die längliche Ausschreiben wesentlicher Syntaxelemente, hat der Sprache geschadet. Gerade C ist da das absolute Gegenteil, und auch hier wette ich, dass so einige frühe Fans direkt durch die prägnante Syntax überzeugt wurden.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Mathuas Gibt es einen Grund, weshalb Pascal nie der Durchbruch gelungen ist? Kenne einige, die davon schwärmen.
Mal ein paar Jahreszahlen mit den ersten Versionen der jeweiligen Programmiersprachen bzw. wann die ersten Computer der jeweiligen System auf den Markt kamen für den Überblick.
- 1957 Fortran
- 1959 Cobol
- 1964 IBM S/360
- 1970 Pascal
- 1973 UNIX außerhalb der Bell Labs
- 1977 VMS
- 1978 Modula-II, PL/I
- 1981 IBM PC
- 1983 Ada, TurboPascal
- 1984 Macintosh
- 1985 Amiga, Atari ST, Windows 1.0
- 1987 Acorn Archimedes
- 1988 IBM AS/400, NeXT Computer mit NeXTSTEP
- 1993 Windows/NT
UNIX, VMS, AmigaOS und Atari TOS hat man vornehmlich in C programmiert. Nur beim Atari hatte man keine dynamische Speicherverwaltung durch das OS, es lief immer nur ein Programm. Die anderen Systeme haben ein OS gehabt, dass das für einem übernahm. Amiga und Atari waren Heimcomputer, während man UNIX und VMS in den 1980er nur auf entsprechend teurer Hardware laufen lassen konnte, die bereits abgesicherte Speicherbereiche hatte. D.h. hat man sich auf UNIX System eine Speicherfehler eingebaut, wurde das Programm bloß mit einem Segfault rausgeworfen bzw. man konnte bequem mit einem Debugger arbeiten, der schon ähnlich (halt nur mit Consolen Output und keinen GUI) wie heute funktionierte. Beim Amiga (oder auf dem Mac, Atari ST) durftest Du den Rechner rebooten und sehen wie Du den Fehler findest. Denn das Geld für einen zweiten Computer, den Du an den seriellen Port hängen konntest, um den Post Mortem Debugger benutzen zu können, hatte kaum jemand.
Auf den IBM Hosts (S/360 und Nachfolger bzw. Clone) wurden damals vornehmlich Fortran und Cobol genutzt. Die AS/400 wurden in PL/I programmiert. UNIX wurde in C selbst entwickelt, und alle APIs sind für C definiert. Das gleiche findet sich bei VMS, AmigaOS, AtariTOS und Macintosh System 6 bis 9 (vorher wurde ObjectPascal genutzt). NeXTSTEP hat selbst C APIs, aber die umfangreichen FrameWorks von NeXT sind in Objective-C geschrieben.
Auf dem PC mit DOS gab genauso wie bei den meisten anderen 8Bit Homecomputern keine richtige API sondern LowLevel Interrupts und es lief immer nur ein Programm. Daher waren die Nachteile von Pascal nicht so gewichtig, wie bei den anderen OS. Daher war TurboPascal eine der wichtigsten Programmiersprachen auf dem DOS PC. Ein weiterer Grund dafür war, dass es schon so etwas wie eine IDE gab und es somit sehr viel einfacher war Programme zu schreiben.
Pascal Programme mussten immer recompiliert werden, wenn man eine Arraygröße ändern wollte. Modula-II und Ada hatte das Problem bereits nicht mehr, und sind erlaubten es dynamische Speicherverwaltung zu machen. Wer also eines der Systeme nutzte, die bereits dynamische Speicherverwaltung und das Ausführen mehrerer Programme erlaubte, wollte garantiert nicht mehr mit Pascal herumhantieren, weil das eher umständlich war. Bei Fortran gab es wegen des umfangreichen Programmcodes damals gute Gründe diese Nachteile zu akzeptieren. Wobei bei Fortran90 wurde das schon geändert. Nur gab es viele Jahre keinen freien Fortran90 Compiler und so wurden insbesondere in den Universitäten noch lange F77 programmiert, damit Studenten den Code leicht auf eigener Hardware ausführen konnten.
In den 1980er verlange das DoD, dass Programme für öffentliche Aufträge in Ada geschrieben sein mussten. D.h. für alle der wichtigen Systeme gab es Ada Compiler. Und was in Bezug auf C++ nicht uninteressant ist, die ersten Entwürfe zur „STL“ wurden in Ada geschrieben, und waren dann die Vorlagen für die Entwicklung der STL für C++.
-
@SeppJ Das mit der Syntax ist wirklich Geschmacksache. Wenn du dir Ruby oder irgendwelche funktionale Sprachen anschaust, dann wirkt das für den Mainstream-Programmierer auch erst einmal seltsam.
Das mit den fixen Array-Größen finde ich allerdings krass, scheint aber gelöst zu sein.
Aus Kundensicht wäre Lazarus tatsächlich die beste Sprache für viele Anwendungsfälle, da man schnell zu Ergebnissen kommt. Persönlich will ich mich mit einem halbtoten Projekt allerdings nicht auseinandersetzen.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
Das mit den fixen Array-Größen finde ich allerdings krass, scheint aber gelöst zu sein.
Dies ist schon recht lange gelöst, wen ich mich nicht täusche, seit Delphi 32Bit wurde.
Und dies sogar sehr gut, ich wüsste in der Schnelle nicht, wie ich folgendes in C lösen sollte.
function gtk_clist_new_with_titles(columns: gint; titles: ppchar): PGtkWidget; cdecl; external gtklib;
const list_Titel: array of string = ('N', 'Name', 'Spalte3', 'Spalte4'); begin list_Titel[0] := list_Titel[0] + 'ummer'; Insert('vergessen', list_Titel, 2); clist := gtk_clist_new_with_titles(Length(list_Titel), PPChar(list_Titel));
Eine weitere Stilblüte finde ich z.B. auch den Zoo an sprintf Funktionen (bei der WinAPI). Wieviele sprintf Varianten gibt es?
Ja, da gibt es viele, aber die kann ich als Pascal Coder alle auch nutzen, ich muss nur die entrechende lib einbinden.
const lib_stdio='c'; function printf(str:PChar):cint;varargs cdecl;external lib_stdio; function fprintf(stream:cFILE; str:PChar):cint;varargs cdecl;external lib_stdio;
Für die meisten fällen reicht das gewöhnlich Writeln. Und da entfällt das mühsame hantieren mit %x.
Writeln('Raster: x: ', x, ' y: ', y);
Aus Kundensicht wäre Lazarus tatsächlich die beste Sprache für viele Anwendungsfälle, da man schnell zu Ergebnissen kommt. Persönlich will ich mich mit einem halbtoten Projekt allerdings nicht auseinandersetzen.
Definitiv, mit der LCL erzeuge ich innert kürzester Zeit eine Dialog-Maske, welche dann auch sehr einfach genutzt werden kann. Würde ich dies mit nativen GTKx machen, bräuchte ich viel länger. Und wie schon gesagt, man kann unter Linux entwickeln und lässt es über eine Cross-Compiler laufen und schon hat man eine Windows-App.
Und Tot ist es überhaupt nicht, das Project ist quick lebendig, fast täglich Neuerungen.
Und wen man sich mal an Lazarus gewöhnt hat, verteufelt man alle Editoren wie Codeblook und co.
Mit dem kommerziellen Delphi sieht es ein wenig anders aus, seit es nicht mehr Borland ist kann ich mich nicht mehr anfreunden.Was ein Manko von FPC ist, C++ - Libs kann man (noch) nicht anbinden. Aber da gibt es zum Glück sehr wenige, einzig bekanntes was mir gerade in den Sinn kommt ist QT.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
Das mit den fixen Array-Größen finde ich allerdings krass, scheint aber gelöst zu sein.
Jetzt wäre es interresant zu wissen, ob es sich auch wie
std::vector::push_back()
verhält, heißt ob neue Capacity gleich alte Capacity × 1.5 ist.
-
@Mathuas sagte in Welche Sprache kann C++ Konkurrenz machen?:
Ja, da gibt es viele, aber die kann ich als Pascal Coder alle auch nutzen, ich muss nur die entrechende lib einbinden.
Möchte man dies?
Es geht hier weniger um
fprintf
sondern um Funktionen wiesprintf_s
,snprintf_s
,sprintf
,StringCbPrintf
,... Ich glaube in der Summe gibt es 30-50 sprintf Varianten bei Visual Studio, aufgeteilt in ASCII, Unicode und TCHAR Varianten.Unter C++20 gibt es
std::format
und damit kann man sehr viele Fälle erschlagen. Vor C++20 nutzte ich eine selbst geschriebene Printf Variante basierend auf densprintf
Funktionen, wie z.B._vscprintf
.
-
@Quiche-Lorraine sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
Das mit den fixen Array-Größen finde ich allerdings krass, scheint aber gelöst zu sein.
Jetzt wäre es interresant zu wissen, ob es sich auch wie
std::vector::push_back()
verhält, heißt ob neue Capacity gleich alte Capacity × 1.5 ist.Meinst du sowas ?
const ia: array of integer = (1, 2, 3); var i: Integer; begin Insert(4, ia, Length(ia)); for i := 0 to Length(ia) - 1 do begin WriteLn(ia[i]); end; end.
FPC kann die array verlängern, bis es keinen Platz mehr gibt, wen dies erreicht wird, bekommt die array einen neuen Speicherbereich und die alten Daten werden dann ins neue Array kopiert.
Nachtrag:
Habe gerade ein Experiment mit folgendem Code gemacht.const ia: array of integer = (1, 2, 3); var i: SizeInt; p: Pointer; begin Insert(4, ia, Length(ia)); p := @ia[0]; WriteLn(PtrUInt(p)); for i := 0 to 1000000000000 do begin Insert(i, ia, Length(ia)); if i mod 100000000 = 0 then begin Write('.'); end; if p <> @ia[0] then begin p := @ia[0]; WriteLn(PtrUInt(p)); end; end; end.
Ausgabe:
$ ./project1 140377880358992 .140377880326224 140377880293456 140377880031328 140377879703648 140377879048288 140377877737568 140377875116128 140377869873248 140377859387488 140377838415968 140377796472928 140377712586848 140377544814688 140377209270368 .140376538181728 ..140375196004448 ...140372511649888 .......140367142940768 .............140356405522528 ...........................140334930686048 ......................................................140291981013088 .......................................................Getötet
Am Ende, war mein Speicher inklusive Swap-Disk voll.
-
@Quiche-Lorraine meint den internen Vergrößerungsfaktor der Kapazität (>= Size), damit nicht bei jedem Einfügen jedesmal ein neues Array erzeugt werden muß.
Selbst bei C++ variiert dieser Faktor aber je nach Implementierung der Standard-Library (meist1.5
oder2
), der beste Wert ist aber wohl der Goldene Schnitt1.618...
(bzw.(1+sqrt(5))/2
), s.a. die Konversation vector growth factor of 1.5.@Mathuas: Die Frage ist also, wie dieser bei Pascal umgesetzt ist (denn das sieht man aus deinem Code nicht direkt - nur, daß sich der Zeigerwert verändert)?
Edit: Schreib den Code mal um, daß er (nur) bis z.B. 1000 einfügt und gib dann die Größe aus, wenn sich der Zeigerwert ändert. Dann sollte sich dieser Faktor ermitteln lassen.
-
@Th69 sagte in Welche Sprache kann C++ Konkurrenz machen?:
damit nicht bei jedem Einfügen jedesmal ein neues Array erzeugt werden muß.
Ich dachte, dies sieht man bei meinem Beispiele. Die Anzahl der ... verdoppelt sich in etwa, besonders ab einer Grösse von 64KByte.
Ich habe den Code ein wenig abgeändert, so das man es besser sieht.
$ ./project1 . 6 30 78 65506 147426 311266 638946 1294306 2605026 5226466 10469346 20955106 41926626 83869666 . 167755746 .. 335527906 ... 671072226 ....... 1342160866 ............. 2684338146 ........................... 5368692706
Änderung im Code:
// WriteLn(PtrUInt(p)); WriteLn(i:15);
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Mathuas Gibt es einen Grund, weshalb Pascal nie der Durchbruch gelungen ist? Kenne einige, die davon schwärmen.
Pascal hatte doch den Durchbruch und war in den 80ern und frühen 90ern auf DOS Mainstream.
-
@Tyrdal sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
@Mathuas Gibt es einen Grund, weshalb Pascal nie der Durchbruch gelungen ist? Kenne einige, die davon schwärmen.
Pascal hatte doch den Durchbruch und war in den 80ern und frühen 90ern auf DOS Mainstream.
Ich habe mich vll. ungenau ausgedrückt: Pascal hatte seine Höhen, aber hat sich letztendlich nicht durchgesetzt.
Ich muss aber sagen: Wäre ich Lehrer an einer Schule, dann würde ich Lazarus/FPC unterrichten: Einfach weil das ein guter Einstieg wäre, man schnell zu Ergebnissen kommt und ich dadurch mehr Schüler mitnehmen würde.
An einer Uni mit Informatik-Schwerpunkt, hat das aber meiner Ansicht nach nichts zu suchen. Einfach deshalb, weil diese Sprache in der Wirtschaft nicht relevant ist.
-
@Steffo sagte in Welche Sprache kann C++ Konkurrenz machen?:
Ich muss aber sagen: Wäre ich Lehrer an einer Schule, dann würde ich Lazarus/FPC unterrichten: Einfach weil das ein guter Einstieg wäre, man schnell zu Ergebnissen kommt und ich dadurch mehr Schüler mitnehmen würde.
An einer Uni mit Informatik-Schwerpunkt, hat das aber meiner Ansicht nach nichts zu suchen. Einfach deshalb, weil diese Sprache in der Wirtschaft nicht relevant ist.Genau dies ist der Punkt, wen Schulen anstelle von C Pascal nehmen würden, wäre Pascal viel verbreiteter.
Bei uns in der Bude, einer der mal studiert hat, hatte kürzlich Lazarus von mir gesehen, der war total begeistert, wie einfach coden sein kann. Und die mit einem ebenbürtigen Ergebnis zu C.FPC und GCC sind fast ebenbürtig, was aber viel schlimmer ist, Python, Java und co. Interpretersprachen, wie dazumal GW-BASIC. Solchen Mist würde ich niemals anfassen. Ausser Java bei Android, weil es da fast keine Alternative gibt.
-
Java ist nicht per se schlecht, nur weil es u. a. interpretiert ist ... Es ist das bessere C++ ... Aber du scheinst nicht studiert zu haben @Mathuas , folglich werde ich bestimmte Unwissenheiten und Nichtkenntnisse auch nicht vorverurteilen.
-
@cyborg_beta sagte in Welche Sprache kann C++ Konkurrenz machen?:
Java ist nicht per se schlecht, nur weil es u. a. interpretiert ist ... Es ist das bessere C++
Aua, das tut aber weh. Die Sprachen haben nicht ohne Grund unterschiedliche Anwendungsgebiete.