Was ich schon immer wissen wollte aber nie zu fragen wagte:
Warum eigentlich wird für Linux so viel Software in C und nur wenig in
C++ oder in einer anderen (moderneren) Programmiersprache erstellt?
Beispielsweise schreibt Microsoft, daß Funktionen wie itoa() oder atoi()
unsicher sind. Was soll man von dieser Aussage halten? Stimmt sie? Oder
ist C grundsätzlich zeitlos und im grunde genommen ideal und nicht
"verbesserbar" ?
itoa() ist unsicher. Das ist aber auch nicht im C-Standard enthalten.
atoi() ist nicht unsicher. Aber du kannst keine Fehleingaben erkennen.
Dafür gibt es (seit C89 oder früher) strtol().
Joachim ... schrieb:> Warum eigentlich wird für Linux so viel Software in C und nur wenig in> C++ oder in einer anderen (moderneren) Programmiersprache erstellt?
Was versprichst du dir für Vorteile? Die Sprache, mit der man am ehesten
ans Ziel kommt, ist die Sprache der Wahl.
Natürlich kannst du C++ benutzen und ist vermutlich für komplexe
Programme auch angesagt. Aber für einen Treiber oder kleines CLI Tool
einfach viel zu abgehoben.
Z.B. Torque3D wird ausschliesslich in C++ geschrieben und läuft auf
Linux, MacOSX und Windows.
http://www.garagegames.com/products/torque-3d
Joachim ... schrieb:> Warum eigentlich wird für Linux so viel Software in C und nur wenig in> C++ oder in einer anderen (moderneren) Programmiersprache erstellt?
Das ist ein Unding, ja.
Ich denke mal das hat mehrere Gründe.
- Linus himself ist erklärter C++ Gegner. Das schliest C++ im Kernel
schonmal aus
- C ist historisch gesehen DIE Sprache für unixoide Systeme, die ganzen
GNU-Tools liegen in C vor. Deswegen werden wohl die ganzen Userspace
Programme und Systemtools, die auf Linux aufsetzen auch weiterhin in C
entwickelt
- C++ ist verdammt mächtig, aber auch verdammt kompliziert. Der gemeine
Hobbyprogrammierer der gerne mal was zu seinem Lieblings OS Projekt
beitragen will kann oft nur C
- und Last (but not least): "Das haben wir schon immer so gemacht".
Finds auch schade. Das mag noch einige Jahre/Jahrzehnte gut gehen, aber
irgendwann könnte sich das Nichtbeachten von OO rächen. Man muss nicht
jeden Hype mitmachen, aber zumindest C++ ist reif genug um Einzug in den
(Teile des) Kernels zu finden. Zumal der Kernel eh viele C++ Features
nachbildet und hinter kryptischen Makroorgien versteckt.
Zumindest verwenden aber einige Distributionen mittlerweile offiziell
Python. Kann man nur Hoffen dass Python sich auf lange Sicht halten kann
(mehrere Jahrzehnte)
Ich kenne zwei Arten von itoa, mit und ohne Angabe der Basis:
char * itoa ( int value, char * str, int base );
char * itoa ( int value, char * str);
Bei keiner kannst du die Größe des Bereichs angeben, auf die str zeigt.
Jetzt macht itoa zwar nicht so viele Zeichen, wie es gets schafft,
dennoch gibt es keine Längenprüfung.
Patrick Dohmen schrieb:> str könnte zu klein sein, es fehlt ein Längenargument.
Kommt auf die Sichtweise drauf an. Zumindest ist klar welche Länge
maximal benötigt wird, und es liegt in der Verantwortung des
Programmierers, den Buffer groß genug zu machen.
Für mich ist das nicht "unsicher", maximal gefährlich. Aber was in C ist
ungefährlich? :-)
gets() ist wirklich unsicher.
Michael Reinelt schrieb:> Zumindest ist klar welche Länge> maximal benötigt wird,
Welche denn?
7 auf DOS und avr-gcc
12 bei 32-Bit Systemen
> und es liegt in der Verantwortung des> Programmierers, den Buffer groß genug zu machen.
Das liegt es immer
> Für mich ist das nicht "unsicher", maximal gefährlich.
Die Zeiten ändern sich.
Joachim ... schrieb:> Was ich schon immer wissen wollte aber nie zu fragen wagte:> Warum eigentlich wird für Linux so viel Software in C und nur wenig in> C++ oder in einer anderen (moderneren) Programmiersprache erstellt?
Bei meiner Linux-Installation hier ist das Verhältnis von C- zu
C++-Programmen etwa 2:1. Angesichts der Tatsache, dass praktisch alle
klassischen Unix-Tools, die keine Skripte sind, C-Programme sind,
erscheint mir der C++-Anteil überraschend hoch.
Bei Leuten, die KDE installiert haben, dürfte der C++-Anteil noch höher
liegen.
Joachim ... schrieb:> Beispielsweise schreibt Microsoft, daß Funktionen wie itoa() oder atoi()> unsicher sind. Was soll man von dieser Aussage halten? Stimmt sie?
atoi würde ich überhaupt nicht als unsicher ansehen, itoa eigentlich
auch nicht, aber vielleicht etwas eher als atoi. itoa ist aber nicht im
C- und C++-Standard enthalten, sondern eine Microsoft-Erweiterung. MS
sollte sich also nicht über diese Funktion beschweren, sondern erst
einmal ein wenig in sich gehen :)
Autor: Yalu X. (yalu) (Moderator) schrieb:
>itoa ist aber nicht im>C- und C++-Standard enthalten, sondern eine Microsoft-Erweiterung. MS>sollte sich also nicht über diese Funktion beschweren, sondern erst>einmal ein wenig in sich gehen :)
Microsoft schreibt zu itoa():
This POSIX function is depreceated. Use the ISO C++ conformant _itoa or
security-enhanced _itoa_s instead.
Joachim ... schrieb:> This POSIX function is depreceated.
Nichtmal das bekommen sie auf die Reihe.
War nie in POSIX drin.
Weder Linux noch FreeBSD noch OSX implementieren sie. Andere UNIXe habe
ich gerade nicht zum Nachschauen zur Hand.
Joachim ... schrieb:> Warum eigentlich wird für Linux so viel Software in C und nur wenig in> C++ oder in einer anderen (moderneren) Programmiersprache erstellt?
Weil C++ letztlich für die meisten Programmierer zu kompliziert ist. Im
Gegensatz zu fast allen anderen Sprachen (inklusive C) ist für C++ ein
vertieftes Verständnis notwendig. Ansonsten kann man die Vorteile nicht
nutzen, setzt sich aber vielen Gefahren aus. Nicht umsonst ist C++ die
wohl einzige Programmiersprache, für die es Fortgeschrittenen-Bücher
gibt.
Jörg Wunsch schrieb:> Weder Linux noch FreeBSD noch OSX implementieren sie. Andere UNIXe habe> ich gerade nicht zum Nachschauen zur Hand.
Gibt/Gab es auch nicht in UNIX System V, HPUX und anderen unixoiden
Systemen. Und davon kenne ich eine Menge. ;-)
Frank M. schrieb:> Gibt/Gab es auch nicht in UNIX System V, HPUX und anderen unixoiden> Systemen.
Das letzte SysV-Derivat, das man noch in freier Wildbahn antreffen
kann, dürfte Solaris sein. War ich zu faul, das extra zu booten dafür.
Die Behauptung von Winzigweich war ja, dass es “POSIX” sein, also die
genormte Untermenge von UNIX, und das stimmt so schlicht nicht.
Btw., ein HP/UX lief mir zufällig gerade über den Weg (in Form meines
LAs, mit dem ich gerade arbeiten muss): auch Fehlanzeige, kein itoa().
Sieht so aus, als gäbe es das Ding nur bei MS, aber sie waren sich
zu fein, das zuzugeben, und wollten das daher lieber auf POSIX schieben.
Joachim ... schrieb:> Was ich schon immer wissen wollte aber nie zu fragen wagte:> Warum eigentlich wird für Linux so viel Software in C und nur wenig in> C++ oder in einer anderen (moderneren) Programmiersprache erstellt?
Wie kommst du zu dieser Einschätzung? Wenn ich mich auf einem
Linux-System umsehe, dann ist da jede Menge Software auch in anderen
Sprachen als C:
- Python (5994)
- C++ (5176)
- Perl (4523)
- Ruby (754)
- Java (367)
- Mono (113)
- tcl/tk (90)
Die Zahl in Klammern ist dabei die Zahl der Packages in Debian Wheezy,
die direkt von dem Runtime-Package (z.B. der Java-JRE oder libstdc++)
abhängen.
>Wie kommst du zu dieser Einschätzung? Wenn ich mich auf einem>Linux-System umsehe, dann ist da jede Menge Software auch in anderen>Sprachen als C:>- Python (5994)>- C++ (5176)>- Perl (4523)>- Ruby (754)>- Java (367)>- Mono (113)>- tcl/tk (90)
Du hast aufzuzählen vergessen, wie viele Programme dieses Linux-Systems
in C geschrieben sind. Erst dann gilt ein Vergleich.
Ich denke man sollte auch Unterscheiden zwischen dem Kernel "ganz unten"
und den Programmen im Userspace.
KDE als Stichwort ist schon gefallen - Basis dafür ist Qt und das ist
C++ (Ok mit Erweiterungen, aber das ist eine andere Geschichte!) ...
GTK+ ist zwar Ursprünglich "für" die Nutzung mit C geschrieben, bietet
aber mit gtkmm auch eine Schnittstelle für C++. (Inkscape ist mit GTK+
entwickelt). Dann noch wxWidgets, entwickelt in C++ und auch mit Libs
für C und andere Sprachen...
Skyper schrieb:> GTK+ ist zwar Ursprünglich "für" die Nutzung mit C geschrieben, bietet> aber mit gtkmm auch eine Schnittstelle für C++.
Ich kenne zwar die Anfänge von GTK nicht...
Aber: GTK wurde ganz zu Anfang für Gimp geschrieben, und dann als
allgemeines GUI Toolkit für andere Sprachen weiterentwickelt. Es war
also schon früh nicht mehr auf die Nutzung von C aus ausgerichtet.
Bindings/Wrapper gibt es jetzt ja für fast jede andere Sprache. (Ich
hatte kürzlich die für Nim gemacht.) Für Toolkits die etwa mit C++
geschrienben sind wie Qt oder wxWidgets ist das Erstellen von Wrappern
für andere Sprachen deutlich aufwendiger.
Das man heute für die Entwicklung eines OS eine bessere Sprache als C
nehmen würde ist wohl klar, Rust, Swift, Nim wären wohl zumindest gute
Kandidaten, aber es gibt sicher viele weitere.
Salewski, Stefan schrieb:> Das man heute für die Entwicklung eines OS eine bessere Sprache als C> nehmen würde ist wohl klar, Rust, Swift, Nim wären wohl zumindest gute> Kandidaten, aber es gibt sicher viele weitere.
Das kann man so nicht sagen. Bei C hat man sich auch im Standard
wirklich Gedanken gemacht wie man Platformunabhängigkeit möglichst ohne
technische Nachteile garantiert. Nicht viele Sprachen können das von
sich behaupten.
Im Userspace lieber C++ statt C, weil ich da die ganzen Features ohne
Bedenken und Nachteile (naja meistens jedenfalls) nutzen kann, aber im
Kernelspace?
Bei C hat man zwei große Vorteile:
- sehr viele können C (kleiner Sprachkern) -> mehr Mitarbeiter im Fall
von Linux
- in C gibt es kaum Verschleierung (klassisches Beispiel in C++: wie
oft wird bei der Stringverarbeitung Speicher alloziert?)
Meine Erfahrung nach, ist C eigentlich sehr angenehm, wenn man auf
dynamische Speicherverwaltung verzichten kann und prozedural
programmiert. Dazu kommt, dass der Kernel größtenteils in sich
geschlossene Aufgaben erledigen muss, weshalb sich die Komplexität
dazwischen in Grenzen hält (ich hoffe, dass ich mit der Aussage nicht zu
sehr aus dem Fenster lehne ;) )
Also ernst gemeinte Frage: welche Vorteile kann mir C++ über C bei der
Kernelentwicklung bieten?
TriHexagon schrieb:> - in C gibt es kaum Verschleierung (klassisches Beispiel in C++: wie> oft wird bei der Stringverarbeitung Speicher alloziert?)
Wenn ich in C eine Bibliothek schreibe, die Strings dynamisch verwaltet,
hast du als Anwender auch keine Ahnung, wie oft Speicher alloziert wird
(ausser du analysierst den Quellcode, was in C++ auch möglich ist).
TriHexagon schrieb:> Meine Erfahrung nach, ist C eigentlich sehr angenehm, wenn man auf> dynamische Speicherverwaltung verzichten kann und prozedural> programmiert.
Kann man in C++ auch, nur ist C++ auch angenehm, wenn man nicht auf
dynamische Speicherverwaltung verzichten kann (Container und Smart
Pointer).
TriHexagon schrieb:> Also ernst gemeinte Frage: welche Vorteile kann mir C++ über C bei der> Kernelentwicklung bieten?
Ich entwickle zwar keine Kernel, aber namespaces, Klassen inkl.
Konstruktoren und Destruktoren, sowie das Überladen von Operatoren sehe
ich unabhängig vom Einsatzgebiet als deutlichen Vorteil an. Nur weil
eine Programmiersprache Features beinhaltet, ist man nicht gezwungen,
all diese auch zu benutzen.
Jörg Wunsch schrieb:> Sieht so aus, als gäbe es das Ding nur bei MS, aber sie waren sich> zu fein, das zuzugeben, und wollten das daher lieber auf POSIX schieben.
Nein, POSIX stammt doch von M$, wie auch das ganze Internet ;-)
be stucki schrieb:> Ich entwickle zwar keine Kernel, aber namespaces, Klassen inkl.> Konstruktoren und Destruktoren, sowie das Überladen von Operatoren sehe> ich unabhängig vom Einsatzgebiet als deutlichen Vorteil an. Nur weil> eine Programmiersprache Features beinhaltet, ist man nicht gezwungen,> all diese auch zu benutzen.
Die ganzen netten Features von C++ benötigen aber eine Laufzeitumgebung
bzw. zumindest eine funktionierende Speicherverwaltung. Und da hätten
wir auch schon das erste Problem.
Im User-Space gibt es nur eine Art von Speicher, während es im
Kernel-Space viele Arten von Speicher gibt, wie z.B.: ISA addressierbar,
DMA-fähig, LowMem, HighMem, Swappable, ... und auch der Context
(Interrupt, Kernel-Thread, Userspace Prozess,...) in dem der Speicher
allokiert wird spielt eine wichtige Rolle. Auch wird Speicher häufig
seitenweise oder in noch größeren Blöcken allokiert, um eine
Fragmentierung zu vermeiden oder kritische Datenstrukturen und
Containeralgorithmen auf optimales Caching/optimale Performanz
optimiert.
Das passt alles nicht so recht zu C++, das mal eben im Hintergrund noch
zusätzlich Speicher allokiert oder eine Datenstruktur vergrößert.
Thorsten schrieb:> Das passt alles nicht so recht zu C++, das mal eben im Hintergrund noch> zusätzlich Speicher allokiert oder eine Datenstruktur vergrößert.
C++ macht genauso viel oder wenig "im Hintergrund" wie C, nämlich von
sich aus überhaupt nichts.
Oliver
be stucki schrieb:> TriHexagon schrieb:>> - in C gibt es kaum Verschleierung (klassisches Beispiel in C++: wie>> oft wird bei der Stringverarbeitung Speicher alloziert?)> Wenn ich in C eine Bibliothek schreibe, die Strings dynamisch verwaltet,> hast du als Anwender auch keine Ahnung, wie oft Speicher alloziert wird> (ausser du analysierst den Quellcode, was in C++ auch möglich ist).
Ja das mag sein, aber in C kann man sehr viel einfacher einschätzen wie
viel Laufzeit der Code benötigt. Ist irgendwie schwer da zu
argumentieren, betrifft halt die subjektive Wahrnehmung. Mit Klassen und
Operatorüberladung lässt sich jedenfalls viel verschleiern, vor allem
wenn da so abstruses Zeug wie Streamoperatoren rauskommt.
be stucki schrieb:> TriHexagon schrieb:>> Also ernst gemeinte Frage: welche Vorteile kann mir C++ über C bei der>> Kernelentwicklung bieten?> Ich entwickle zwar keine Kernel, aber namespaces, Klassen inkl.> Konstruktoren und Destruktoren, sowie das Überladen von Operatoren sehe> ich unabhängig vom Einsatzgebiet als deutlichen Vorteil an. Nur weil> eine Programmiersprache Features beinhaltet, ist man nicht gezwungen,> all diese auch zu benutzen.
Finde ich eher so "nice to have" bei der Kernelentwicklung. Sehe bei
einem Kernel nicht so die Komplexität in der Architektur sondern im
Technischen und da bringt mir C++ nicht mehr als C (mir fällt da
jedenfalls nichts ein).
Bei C++ gibt es das große Problem, dass die Fähigkeiten und Stile (z.B.
Templategebrauch) zwischen den Programmierern sehr unterschiedlich sind,
was bei einem großen internationalen Projekt wirklich zu einem Problem
werden kann. Irgendwie muss man ja dafür sorgen, dass der Code möglichst
gleichwertig/harmonisch ist, sonst herrscht Chaos. Da müsste man bei C++
zunächst sehr viel Arbeit reinstecken um das zu gewährleisten, Arbeit
die auch einfach in den Kernel selbst gesteckt werden kann.
Insofern kann ich es sehr gut verstehen sich einfach auf C zu
beschränken.
Thorsten schrieb:> Das passt alles nicht so recht zu C++, das mal eben im Hintergrund noch> zusätzlich Speicher allokiert oder eine Datenstruktur vergrößert.
Die ganzen von dir angesprochenen Probleme und Sonderfälle hast du aber
in C genauso. Mit einem malloc alleine ist es da nicht getan.
Der kleine Unterschied besteht darin, dass du beispielsweise den C++
STL-Containern diese ganzen Sonderfälle alle transparent unterjubeln
kannst. Alle Containerklassen haben ein zusätzliches Argument für einen
Allokator, der sich um die SPeicherverwaltung und nur um die
Speicherverwaltung kümmert. Und das ohne dass derjenige, der die Klassen
verwendet, da irgendwas vergessen könnte.
Will man die Template COntainer nicht benutzen, dann schreibt man sich
eben selbst welche, mit genau den Eigenschaften die man haben will. Das
macht man ja in C auch nicht anders.
Denn genau das sehe ich als den Hauptvorteil an: Man kann Klassen so
schreiben, dass man, anders als in C, automatisch immer auf der sicheren
Seite ist. Wie lange hat man sich in C mit Buffer-Overruns
rumgeschlagen, nur weil wieder mal irgendein Programmierer eine
Overflow-Prüfung vergessen hat? C++ gibt dir die Möglichkeiten in die
Hand, Funktionalität so zu verpacken, dass man das nicht mehr vergessen
kann. Das bedeutet nicht, dass man alles und jedes, was in C++ möglich
ist, auch benutzen muss. Ich hab durchaus Verständnis dafür, dass man
die Community einer freiwilligen Selbstbeschränkung unterwirft. Selbst
wenn man C++ nur als ein 'besseres C' benutzen würde, noch Konstruktoren
und Destruktoren mit dazu nimmt, hätte man schon einen Vorteil. Das
heisst ja nicht, dass man da jetzt eine MOnsterklassenhierarchie mit
multiple Inharitance in 30 Ableitungsstufen konsturieren muss. Die man,
wenn man die Funktionalität in C braucht, ja auch erst irgendwie
realisieren muss.
Das ist überhaupt ein Punkt, der bei derartigen Vergleichen gerne
übersehen wird: Oft werden da Äpfel mit Birnen verglichen. Denn das
meiste, was dir C++ (bzw. die STL Klassen) abnehmen, sind Dinge, die du
in C sowieso ebenfalls implementieren müsstest, es aber oft nicht tust,
weil schlicht und ergreifend darauf vergessen wurde. Das Ergebnis ist
sattsam bekannt: Wieder mal ein Loch, durch welches Angreifer eine
Chance haben.
Wie oft hat man in einer Funktion eine dynamische Allokierung und einen
Codepfad übersehen, in dem der Speicher nicht mehr freigegeben wird?
Nimm in C++ einen Smart Pointer und du kannst per Definition nicht
mehr die Freigabe verpassen, weil der Destruktor sich darum kümmert. Und
das der aufgerufen wird, darum kümmert sich wieder der Compiler. Eine
codetechnische Sorge weniger um die ich mich explizit kümmern müsste.
Klar, mann kann natürlich einen alloca() benutzen - kann ich in C++
genauso. Alles was ich in C machen kann, kann ich in C++ genauso und
mehr oder weniger genau gleich machen (bis auf ein paar Kleinigkeiten,
die aber sowieso von eher dubioser Qualität sind). Aber ich kann eben
auch noch mehr machen. In praktisch allen Laufzeitvergleichen, die ich
gesehen habe und in denen C haushoch gewonnen hat, war es praktisch
immer so, dass in C die ganzen Sicherheitsprüfungen und die Buchhaltung
ganz einfach weggelassen wurde - mit den bekannten Konsequenzen, dass es
bei den ersten fehlerhaften Eingabedaten ganz gewaltig kracht. Ergänzt
man diese fehlenden Dinge hat man plötzlich wieder einigermassen
Gleichstand, oft sogar mit einem kleinen Vorteil zugunsten von C++.
Karl Heinz schrieb:> In praktisch allen Laufzeitvergleichen, die ich> gesehen habe und in denen C haushoch gewonnen hat, war es praktisch> immer so, dass in C die ganzen Sicherheitsprüfungen und die Buchhaltung> ganz einfach weggelassen wurde
Man muss aber ehrlicherweise sagen, dass genau dieses Weglassen von für
Profis "unnützen" Sicherheitsabfragen wie z.B. die Prüfung eines
gültigen Indexes für ein Array bei der Entwicklung von C bewusst gemacht
wurden um ein schlankes und schnelles System zu haben.
Unddas wird auch bis heute als Vorteil von C gegenüber Sprachen wie
Pascal etc. angeführt.
Udo Schmitt schrieb:> Unddas wird auch bis heute als Vorteil von C gegenüber Sprachen wie> Pascal etc. angeführt.
;-)
Man könnte auch sagen: als Nachteil.
Wer ungeprüft einen String vom Benutzer mittels strcpy umkopiert, hat
einfach irgendwas nicht begriffen.
gets/fgets Problematik.
Das sind ja nicht alles Dinge, die ich mir hier ausdenke. Das ist alles
realer Code, der auch heute noch so geschrieben wird.
Axel Schwenke schrieb:> Wie kommst du zu dieser Einschätzung? Wenn ich mich auf einem> Linux-System umsehe, dann ist da jede Menge Software auch in anderen> Sprachen als C:>> - Python (5994)> - C++ (5176)> - Perl (4523)> - Ruby (754)> - Java (367)> - Mono (113)> - tcl/tk (90)
Und die wiederum sind meist in C geschrieben und nicht etwa in C++ oder
Go oder D oder Ada oder Pascal oder anderen Systemsprachen.
Karl Heinz schrieb:> Udo Schmitt schrieb:>>> Unddas wird auch bis heute als Vorteil von C gegenüber Sprachen wie>> Pascal etc. angeführt.>> ;-)> Man könnte auch sagen: als Nachteil.
Einen Vorteil kann man darin sehen, dass der Programmierer zwischen
mehreren Möglichkeiten, einen Fehler zu verhindern, auswählen kann.
Array-Überläufe u.ä. sind oft nur ein spätes Symptom von Fehlern, die
sich bereits viel früher angebahnt haben dort schon abgefangen hätten
werden müssen. Eine einzige Fehlerabfrage zur rechten Zeit ersetzt u.U.
tausende späterer Indexprüfungen bei Array-Zugriffen, was das System
natürlich deutlich performanter macht.
Deswegen ist es relativ sinnlos, den Compiler auf Verdacht an jeder
erdenklichen Stelle stumpfsinnige Abfragen in den Code einbauen zu
lassen, wie das bspw. in Pascal oder bei einigen High-Level-Datentypen
auch in C++ geschieht. Zudem stellen diese automatischen Prüfungen ja
auch keine Vollkaskoversicherung dar. Sie verhindern zwar i.Allg., dass
ein Programm im Fehlerfall Amok läuft, es ist aber nach wie vor Aufgabe
des Programmierers, geeignete Recovery-Aktionen einzuleiten, um eine
sinnvolle Fortsetzung des Programmablaufs zu ermöglichen. Das nimmt
einem der C++- oder Pascal-Compiler genauso wenig ab wie der C-Compiler
und wird oft ebenso vergessen wie die Sicherheitsabfragen in C.
In wievielen C++-Programmen wird z.B. die bad_alloc-Exception abgefangen
oder gar im Vorfeld dafür gesorgt, dass diese gar nicht erst ausgelöst
werden muss? Ein Großteil C++-Programmierer kennt vermutlich nicht
einmal ihren Namen ;-)
In einem Anwendungsprogramm ist das nicht ganz so tragisch. In den
relativ seltenen Fällen, wo der Speicher vollläuft, wird einfach
abgebrochen. Für einen OS-Kernel ist Abbruch aber keine Lösung.
Das Featureset von C++ einzuschränken wäre natürlich eine Möglichkeit.
In Zeiten von Intel Core i7 und immer stärkeren Vernetzung wäre
durchgehendes Boundchecking eigentlich schon mal angebracht (auch im
Kernel). Dann wäre es auch besser eine andere Sprache als C zu wählen,
aber es gibt natürlich nach wie vor Situationen in denen man die
Laufzeit braucht. Darüberhinaus könnte man auch überlegen, Treiber in
den Userspace zu verschieben.
Udo Schmitt schrieb:> Man muss aber ehrlicherweise sagen, dass genau dieses Weglassen von für> Profis "unnützen" Sicherheitsabfragen wie z.B. die Prüfung eines> gültigen Indexes für ein Array bei der Entwicklung von C bewusst gemacht> wurden um ein schlankes und schnelles System zu haben.> Unddas wird auch bis heute als Vorteil von C gegenüber Sprachen wie> Pascal etc. angeführt.
Das Range-Checking ist bei den mir bekannten Pascal-Compilern eine
Compileroption die man im Release-Build nicht verwenden muss wenn man
nicht will. Eine zusätzliche Option kann also wohl kaum als Nachteil
ausgelegt werden.
Die Hauptvorteile von Pascal gegenüber C sind IMHO die strenge
Typprüfung zur Compilezeit, die sehr aufgeräumte und fast vollkommen
Kontextfreie Grammatik (die Kontextfreiheit ist auch das was den Code so
gut menschenlesbar und den Compiler so rasend schnell macht).
Alle Low-Level Schweinereien die man in C machen kann kann man übrigens
selbstverständlich auch in Pascal machen, man muss nur die unanständigen
Pointer-Casts explizit so hinschreiben damit der Compiler überzeugt ist
daß man das auch wirklich will und danach sehen sie sogar im Code besser
aus als das selbe Konstrukt in C.
Will jetzt nur kurz einen weiteren Grund anmerken,
warum c++ im Kernel wenig verloren hat:
c++ führt schlicht zu Bloatware,
scheint mehr oder weniger zwingend zu sein.
Braucht man sich ja nur c++ Programme ansehen,
eben wie angesprochen kde. braucht hier mehrere 100 MB.
Was ja per se gar nicht so schlimm ist,
ein Kernel in der Größe wäre das aber schon.
Bernd K. schrieb:> Alle Low-Level Schweinereien die man in C machen kann kann man übrigens> selbstverständlich auch in Pascal machen, man muss nur die unanständigen> Pointer-Casts explizit so hinschreiben damit der Compiler überzeugt ist> daß man das auch wirklich will und danach sehen sie sogar im Code besser> aus als das selbe Konstrukt in C.
Zeiger sind in C genauso streng typisiert wie in Pascal. Ausnahme ist
der void-Zeiger (generische Zeiger), der implizit zu jedem anderen
Zeiger Typ gecastet wird bei einer Zuweisung.
Bernd K. schrieb:> Die Hauptvorteile von Pascal gegenüber C sind IMHO die strenge> Typprüfung zur Compilezeit, die sehr aufgeräumte und fast vollkommen> Kontextfreie Grammatik (die Kontextfreiheit ist auch das was den Code so> gut menschenlesbar und den Compiler so rasend schnell macht).
Ein schlechter Programmierer schreibt auch in Pascal schlechten Code.
klugscheisser schrieb:> Will jetzt nur kurz einen weiteren Grund anmerken,> warum c++ im Kernel wenig verloren hat:> c++ führt schlicht zu Bloatware,> scheint mehr oder weniger zwingend zu sein.>> Braucht man sich ja nur c++ Programme ansehen,> eben wie angesprochen kde. braucht hier mehrere 100 MB.>> Was ja per se gar nicht so schlimm ist,> ein Kernel in der Größe wäre das aber schon.
Scheinst ja ne Menge Ahnung von C++ zu haben...
Warum ich nicht manchmal lieber C als C++ schreibe?
Weil die libstdc++ ein fetter Brocken ist und man am Ende trotzdem noch
20 leicht verschiedene Instanzen jedes Templates hat.
Wenn jede Methode von den TemplateParametern abhängt und die 20 binär
wirklich unterschiedlich sind, dann wird es wohl nicht anders gehen.
Auch in C nicht, nur daß man sich dann die Finger wund schreibt. Und
nicht alles, was frühe C++ Compiler machten, ist heute noch Stand der
Kunst.
TriHexagon schrieb:> Scheinst ja ne Menge Ahnung von C++ zu haben...
Hab schon bisschen mehr damit gemacht..
genug um zu wissen, dass einige der hier angesprochenen "features" wie
Sicherheit durch in Klassen eingekapselte Fehlerabfragen oder ähnliches
auf Systemebene nix verloren haben.
Murks kann ich so oder so zusammenschreiben, da helfen die besten
libraries nichts. Fressen nur Performance, vor allem wenn sich dann im
Laufe der Zeit immer mehr Features irgendwo im Objektwust widerfinden.
Irgendwann hat man dann halt Bloatware ala Kde.
denial schrieb:> Warum ich nicht manchmal lieber C als C++ schreibe?> Weil die libstdc++ ein fetter Brocken ist und man am Ende trotzdem noch> 20 leicht verschiedene Instanzen jedes Templates hat.
Habs vergessen wie viel genau, aber ein simples hello world in c++
benötigt schon mehrere MB (!!!!)
in C bereits deutlich weniger,
und in Assembler schafft man problemlos so 150 Bytes, ohne besondere
Tricks..
Bastler schrieb:> Wenn jede Methode von den TemplateParametern abhängt und die 20> binär> wirklich unterschiedlich sind, dann wird es wohl nicht anders gehen.> Auch in C nicht, nur daß man sich dann die Finger wund schreibt. Und> nicht alles, was frühe C++ Compiler machten, ist heute noch Stand der> Kunst.
Oder ich setz mich erst noch mal hin und überlege gründlich,
ob ich nicht doch besser abstrahieren kann.
Hab an sich gar nichts gegen cpp.
Würde jetzt sogar behaupten, dass sich Programmiersprachen zunächst mal
nur
darin unterscheiden, wie ich grundsätzlich an Problemstellungen
herangehe.
Es gibt in jeder sprache einen Weg, der am einfachsten zu gehen ist.
Also bspw. in c++ als objektorientierter Sprache eben Objekte.
Ich kann aber auch problemlos in c++ funktionsorientiert vorgehen.
Nun geht man jedoch normalerweise den einfachsten Weg und setzt die in
einer Sprache vorhandenen Konzepte dann auch im eigenen Denken voraus.
Und hier scheint mir das Denken in Objekten einige Nachteile zu
implizieren,
eben z.B. bereits der Gedanke daran, auf Systemebene sollten immer noch
grundsätzlich Sicherheitsabfragen vorhanden sein.
Wenn ich dann die tolle Arrayklasse mit all ihren Features geerbst habe
und daran gehe, meinen Speichermanager zu implementieren, dauert schnell
alles zehnmal länger wie ohne die features. Muss ich wohl meine eigene
Array Klasse schreiben, da die features dann ja ganz sicher private
sind. also wieder nix gewonnen.
Bezweifel sogar dass cpp hier besser als Basic ist,
mit Basic ist ja bekanntermassen der ganze wixxxs mist geschrieben..
Hallo Joachim,
Joachim ... schrieb:> Was ich schon immer wissen wollte aber nie zu fragen wagte:> Warum eigentlich wird für Linux so viel Software in C und nur wenig in> C++ oder in einer anderen (moderneren) Programmiersprache erstellt?
Entschuldige bitte, aber wie kommst Du darauf?
Liebe Grüße,
Karl
Hallo P.,
P. M. schrieb:> Weil C++ letztlich für die meisten Programmierer zu kompliziert ist. Im> Gegensatz zu fast allen anderen Sprachen (inklusive C) ist für C++ ein> vertieftes Verständnis notwendig.
Das erlebe ich ganz anders.
> Nicht umsonst ist C++ die wohl einzige Programmiersprache, für die es> Fortgeschrittenen-Bücher gibt.
Oh! Ich habe hier mehrere Stapel von Fortgeschrittenen-Büchern, für C,
C++, Perl, Python, Java, JavaScript und sogar PHP.
Liebe Grüße,
Karl
Hallo Stefan,
Salewski, Stefan schrieb:> Für Toolkits die etwa mit C++ geschrienben sind wie Qt oder wxWidgets> ist das Erstellen von Wrappern für andere Sprachen deutlich aufwendiger.
Wie kommst Du auf diese Aussage? PyQt, PerlQt, RubyQt und sogar PHP-Qt
existieren. In der Boost-Library gibt es sogar das Modul Boost.Python,
das nahtlose Übergänge zwischen Python und C++ in ermöglicht.
Liebe Grüße,
Karl
Hallo,
TriHexagon schrieb:> Finde ich eher so "nice to have" bei der Kernelentwicklung.
An welchen Kernels hast Du denn schon mitentwickelt?
Liebe Grüße,
Karl
Hallo denial,
denial schrieb:> Warum ich nicht manchmal lieber C als C++ schreibe?> Weil die libstdc++ ein fetter Brocken ist und man am Ende trotzdem noch> 20 leicht verschiedene Instanzen jedes Templates hat.
Man muß die libstdc++ nicht benutzen. Man muß auch Boost nicht benutzen.
Aber man will. ;-)
Liebe Grüße,
Karl
Karl Käfer schrieb:> Salewski, Stefan schrieb:>> Für Toolkits die etwa mit C++ geschrienben sind wie Qt oder wxWidgets>> ist das Erstellen von Wrappern für andere Sprachen deutlich aufwendiger.>> Wie kommst Du auf diese Aussage? PyQt, PerlQt, RubyQt und sogar PHP-Qt> existieren. In der Boost-Library gibt es sogar das Modul Boost.Python,> das nahtlose Übergänge zwischen Python und C++ in ermöglicht.
Erkläre mir bitte mal, warum es keine einfache Möglichkeit gibt QT (als
GUI) in einem NUR C Compiler zu nutzen, also durch einbinden von Libs
den ganzen Plunder einfach als C-Projektfile zu kompilieren. Ohne den
umgekehrten Weg zu gehen C-Code in einen QT C++ Quelltext einzubinden
und das ganze dann in QT zu kompilieren. Dann weißt du vielleicht wie er
drauf kommt zu behaupten, dass QT für C++ geschrieben ist.
so nicht schrieb:> Erkläre mir bitte mal, warum es keine einfache Möglichkeit gibt QT (als> GUI) in einem NUR C Compiler zu nutzen, also durch einbinden von Libs> den ganzen Plunder einfach als C-Projektfile zu kompilieren.
Diese Möglichkeit gibt es doch.
(Was ist ein C-Projektfile?)
Du brauchst lediglich eine Bibliothek, die den C++-Kram in Form von
(sinnvollen) C-Symbolen exportiert. Diese Bibliothek ist dann
zweckmäßigerweise mit einem C++-Compiler übersetzt. Die Bibliothek kann
dann ihrerseits wieder in einer reinen C-Umgebung genutzt werden.
Selbst diese Bibliothek brauchst du eigentlich nicht, nur dann wird es
etwa mühsam wegen der C++-Linkage und dem Name-Mangling usw.
Nase schrieb:> so nicht schrieb:>> Erkläre mir bitte mal, warum es keine einfache Möglichkeit gibt QT (als>> GUI) in einem NUR C Compiler zu nutzen, also durch einbinden von Libs>> den ganzen Plunder einfach als C-Projektfile zu kompilieren.> Diese Möglichkeit gibt es doch.> (Was ist ein C-Projektfile?)>> Du brauchst lediglich eine Bibliothek, die den C++-Kram in Form von> (sinnvollen) C-Symbolen exportiert. Diese Bibliothek ist dann> zweckmäßigerweise mit einem C++-Compiler übersetzt. Die Bibliothek kann> dann ihrerseits wieder in einer reinen C-Umgebung genutzt werden.>> Selbst diese Bibliothek brauchst du eigentlich nicht, nur dann wird es> etwa mühsam wegen der C++-Linkage und dem Name-Mangling usw.
Wo bitte im Netz gibt es denn diese Bibliothek(en) die das leisten? Wenn
es so einfach wäre würde man es binnen Sekunden finden.
Ich bin auch nicht der erste der danach fragt.
http://stackoverflow.com/questions/1728509/does-qt-have-a-c-interfacehttp://forum.qt.io/topic/7872/how-to-use-c-code-in-qt?page=2
Mehr als irgendwelche halbgaren Ansätze finden sich nicht.
Nase schrieb:> Genaugenommen wurde die auch schon umgesetzt, nämlich in der CLX, die> damals mal mit Kylix ausgeliefert wurde(*)
Und genau da steht ja bereits das Problem. Ein Compiler (beispielsweise
reiner C-Compiler) der nix mit Operator Überladung oder
Mehrfachvererbung anfangen kann wird sich schwer tun QT Code zu
kompilieren.
Ich finde es immer wieder bemerkenswert wie Leute behaupten, C++ sei ein
Fortschritt gegenüber C, nur weil da ein ++ dahinter steht.
Grob gesagt kann man aber sagen, dass die "Vorteile" von C++ in
unixoiden Betriebssystemen bereits durch das Betriebssystem abgedeckt
werden.
Vielleicht ein schönes Beispiel ist die fakerlib. Die stellt ja in der
Regel Objekte zur Verfügung über die man plausible Fakedaten erhält.
Unter einem unixoiden Betriebssystem hätte man einfach ein "fake"
Programm welchem man Parameter übergibt und welches dann die Daten in
einem einfachen Format auf der Standardausgabe ausgibt.
Lest mal "The Art of Unix Programming" durch, das erklärt das ganz
schön.
so nicht schrieb:> Mehr als irgendwelche halbgaren Ansätze finden sich nicht.
Du hast ja auch nicht nach Bibliothekten gefragt.
Du hast provokant gefragt, wieso das nicht geht. Und ich habe dir
provokant geantwortet, dass es problemlos geht.
Es hat wohl noch keiner implementiert, weil es bisher noch niemand
ernsthaft vermisst hat.
Außer Borland damals für CLX/Kylix. Das lag aber daran, dass deren
Pascal-Compiler kein Polymorphismus und keine Operatorenüberladung kann.
Schreiben sie jedenfalls in ihrer Anleitung.
so nicht schrieb:> Nase schrieb:>> Genaugenommen wurde die auch schon umgesetzt, nämlich in der CLX, die>> damals mal mit Kylix ausgeliefert wurde(*)>> Und genau da steht ja bereits das Problem. Ein Compiler (beispielsweise> reiner C-Compiler) der nix mit Operator Überladung oder> Mehrfachvererbung anfangen kann wird sich schwer tun QT Code zu> kompilieren.
Ein reiner C-Compiler wird sich schon mit dem Schlüsselwort class
schwer tun.
[*] Du hast das grundsätzliche Problem nicht verstanden.
Nase schrieb:> so nicht schrieb:>> Mehr als irgendwelche halbgaren Ansätze finden sich nicht.> Du hast ja auch nicht nach Bibliothekten gefragt.>> Du hast provokant gefragt, wieso das nicht geht. Und ich habe dir> provokant geantwortet, dass es problemlos geht.>> Es hat wohl noch keiner implementiert, weil es bisher noch niemand> ernsthaft vermisst hat.
Da haben wir uns missverstanden. Ich meinte nicht, dass es prinzipiell
nicht geht. Ich meinte viel mehr, dass man hierzu nichts brauchbares im
Netz findet. Also fällt QT für mich als Möglichkeit der Nutzung mit
einer netten C IDE wie Pelles C schon mal flach. Oder anders gesagt, man
muss sich in die C++ Ecke begeben, um QT mit C-Code nutzen zu können.
Oder besser gleich sich auf C++ einlassen. Oder was mit Python + C-Code
versuchen.
Nase schrieb:> Ein reiner C-Compiler wird sich schon mit dem Schlüsselwort class> schwer tun.
Das sagte ich doch.
> [*] Du hast das grundsätzliche Problem nicht verstanden.
Natürlich habe ich's verstanden. Umgekehrt hast du aber mein Anliegen
nicht verstanden. Leute die nach einer einfachen Möglichkeit unter C QT
als GUI zu verwenden fragen, werden mit halbgaren Antworten abgespeist.
Beim Nachhaken kommt dann heraus, dass es eben keine Möglichkeit gibt.
Oder es wird frech behauptet, "kein Bedarf", was ich für ein Gerücht
halte. Für C gibt es immer an sowas (GUI) Bedarf. Eher mehr als für
C++. Denn dort gibt es genügend Lösungen. Aber nicht für C. Übrig bleibt
die gute alte Win32 API. Das war's dann aber auch schon fast.
so nicht schrieb:> Ich meinte viel mehr, dass man hierzu nichts brauchbares im> Netz findet. Also fällt QT für mich als Möglichkeit der Nutzung mit> einer netten C IDE wie Pelles C schon mal flach.
Naja. Es gibt auch schöne C++-IDEs. Wobei ich den Hype um Pelles nie
verstanden habe - ich find die gruselig, zumindest als
Anwendungs-Entwickler.
Die Alternative siehst du ja z.B. bei GTK. Da hat man auf Biegen und
Brechen versucht, OOP in reinem C zu implementieren. Prinzipiell
funktioniert das auch, aber dafür hast du dann Symbolnamen mit
Zeilenumbruch...
so nicht schrieb:> Für C gibt es immer an sowas (GUI) Bedarf. Eher mehr als für> C++.
Warum siehst du das so?
> Denn dort gibt es genügend Lösungen. Aber nicht für C. Übrig bleibt> die gute alte Win32 API. Das war's dann aber auch schon fast.
Jo, vorallem mit irgendeiner Form von Zukunftssicherheit oder
Portabilität...
Oder eben GTK, ein TCL-binding, XForms.
Ich finde, GUI ist eines der Anwendungsfelder, die absolut prädestiniert
für natives OOP sind. Schon alleine, weil es da gigantisch viel
Boilerplate erspart.
C Schreiber schrieb:> Habs vergessen wie viel genau, aber ein simples hello world in c++> benötigt schon mehrere MB (!!!!)> in C bereits deutlich weniger,
Jetzt übertreibst du aber ein wenig :)
Nehmen wir folgende Hello-World-Programme:
C
1
#include<stdio.h>
2
3
intmain(void){
4
printf("Hello World\n");
5
return0;
6
}
C++
1
#include<iostream>
2
3
intmain(){
4
std::cout<<"Hello World\n";
5
return0;
6
}
Kompiliert mit GCC und CLang, jeweils mit -Os und anschließender
Entfernung der Symbolinformation mit strip -s, ergeben sich folgende
Größen der Binärdateien:
1
hello-gcc 3132
2
hello-clang 3028
3
hello-g++ 3792
4
hello-clang++ 3808
Das size-Tool liefert folgenden Output:
1
text data bss dec hex filename
2
1120 280 4 1404 57c hello-gcc
3
1040 280 4 1324 52c hello-clang
4
1734 320 144 2198 896 hello-g++
5
1778 320 148 2246 8c6 hello-clang++
Das C++-Programm braucht in diesem (nicht sehr repräsentativen) Fall
also ca. 50% mehr Speicher. Von Bloatware oder Megabytes kann deswegen
aber noch lange keine Rede sein.
Nase schrieb:> so nicht schrieb:>> Ich meinte viel mehr, dass man hierzu nichts brauchbares im>> Netz findet. Also fällt QT für mich als Möglichkeit der Nutzung mit>> einer netten C IDE wie Pelles C schon mal flach.> Naja. Es gibt auch schöne C++-IDEs. Wobei ich den Hype um Pelles nie> verstanden habe - ich find die gruselig, zumindest als> Anwendungs-Entwickler.
Es geht hier nicht speziell um Pelles C, sondern Pelles C als
Stellvertreter für eine "pure C" Entwicklungsumgebung. Der Pelles C
Compiler ist sehr modern, aber es kann mit C++ Schlüsselworten nun mal
nix anfangen.
> Die Alternative siehst du ja z.B. bei GTK. Da hat man auf Biegen und> Brechen versucht, OOP in reinem C zu implementieren. Prinzipiell> funktioniert das auch, aber dafür hast du dann Symbolnamen mit> Zeilenumbruch...
Mit GTK geht schon eher was. Ein paar andere gibt es auch noch. Aber
nicht den großen Wurf.
>> Für C gibt es immer an sowas (GUI) Bedarf. Eher mehr als für>> C++.>Warum siehst du das so?
Ach lass mich doch. Ich mag eben das Einfache. ;)
> Ich finde, GUI ist eines der Anwendungsfelder, die absolut prädestiniert> für natives OOP sind.
Sicher, nur dann heißt es auf den C++ Zug gleich ganz aufzuspringen und
den im Grunde ganzen überschaubar-einfachen C Kram als C++ zu
verkomplizieren, nur vielleicht um ein paar GUI Elemente
hinzuzubekommen.
(Nicht gleich aufschreien, wenn die tollen Features der STL oder Boost
Lib an dieser Stelle unerwähnt bleiben, gelle :)).
Das ist es doch was viele gleich ganz aus C flüchten lässt hin zu
Pascal/Lazarus oder einem der Basic Derivate oder JAVA oder Profan oder
zu sonst irgend was, was Code mit GUI ohne Verrenkungen verbindet.
Es fehlt an einer einfachen Möglichkeit (meinetwegen mit Wrapper) um von
C aus QT GUI Elemente verwenden zu können.
Dass QT und wxwidgets auch nicht von jedem C++ Fan als ein
leichtgewichtiges Framework verstanden wird, dafür gibt es auch bereits
sichtbare Anzeichen.
so nicht schrieb:> Ach lass mich doch. Ich mag eben das Einfache. ;)
Ich auch. Und aber genau darum habe ich keine Lust, mir bei
GUI-Programmierung ständig Gedanken zu machen, ob irgendein String noch
in den Puffer passt...
GUI ist halt 99% nerviges Boilerplate. So ziemlich alles, was du
programmierst, ist schneller und sparsamer als der GUI-Kram. Darum sehe
ich keinen Sinn darin, dort viel Zeit zu investieren, um noch das letzte
Bisschen Speicher zu sparen.
Bei der Programmlogik selbst ist das gewiss anders.
Und ja, Qt ist keineswegs leichtgewichtig. 10..15MB Bibliotheken kannst
du rechnen beim Deploy.
Der Trugschluss ist aber, dass WinAPI/MFC/... auch keineswegs
leichtgewichtig sind. Sie sind nur direkt im Kernel...
Ja, ich verwende auch C++ seit Jahren. Allerdings lange nicht alle
Möglichkeiten. Manche Sachen nehmen auch kuriose Züge an. z.B. haben wir
die V8 von Google in unseren Projekten verwendet. Wenn diese lib als
statische lib übersetzt wird, belegt sie (nur die entstandene lib) satte
600-800Mb auf der Platte. Der anschließende Linkerlauf gönnt sich
mehrere Minuten. Und dabei ist die Codegröße meilenweit vom Linux Kernel
entfernt. Ob das wohl die richtige Entwicklung ist wage ich auch zu
bezweifeln.
Um in der V8 js-Funktionen hinzuzufügen ist natürlich C++ nötig. Wenn
man für das ganze dann Bindings für java, php u.s.w schreiben muss, wird
es ganz lustig. Wir haben dann folgenden Weg beschritten: Um die V8 eine
reine C-Schnittstelle gebaut die genau unsere Anforderungen abbildet und
das dann in eine dll bzw. so gepackt. Das ganze lässt sich dann im
Interfacecode von php, java, apache sapi,c++! u.s.w als einfaches C
verwenden. ist zwar von hinten durch die Brust ins Auge, aber immer noch
besser als den ganzen Tag dem System beim Linke zuzuschauen.
Yalu X. schrieb:> Nehmen wir folgende Hello-World-Programme:>> C>>
1
>#include<stdio.h>
2
>
3
>intmain(void){
4
>printf("Hello World\n");
5
>return0;
6
>}
7
>
>> C++>>
1
>#include<iostream>
2
>
3
>intmain(){
4
>std::cout<<"Hello World\n";
5
>return0;
6
>}
7
>
>> Kompiliert mit GCC und CLang, jeweils mit -Os und anschließender> Entfernung der Symbolinformation mit strip -s, ergeben sich folgende> Größen der Binärdateien:> Das size-Tool liefert folgenden Output:>>
1
> text data bss dec hex filename
2
> 1120 280 4 1404 57c hello-gcc
3
> 1040 280 4 1324 52c hello-clang
4
> 1734 320 144 2198 896 hello-g++
5
> 1778 320 148 2246 8c6 hello-clang++
6
>
>> Das C++-Programm braucht in diesem (nicht sehr repräsentativen) Fall> also ca. 50% mehr Speicher. Von Bloatware oder Megabytes kann deswegen> aber noch lange keine Rede sein.
Nun 50% mehr Code (1120 vs. 1734) ist schon ein deutlicher Nachteil und
das nackte Verhältnis bei den Variablen (4 vs. 144) ist schon
katastrophal. Sicher nicht repräsentativ aber es könnte die bekannte
Tendenz aufzeigen "c++ verschleudert Arbeitsspeicher (S/DDR-RAM)". Und
das ist gerade die resource die im Embedded Bereich am knappesten ist
und erheblich an der Batterie saugt. Die Größe des binaries ist da kaum
entscheident - das schluckt der ROM.
Bloatware wird in unterschiedlichen Zusammenhängen gebraucht, oben ist
gemeint das der Bedarf an Arbeitsspeicher aufgebläht wird. Das ist
insbesonders für den kernel schlecht da häufigen Cache misses die
Kernfunktionen ausbremsen.
MfG,
Eric B. schrieb:> Fpga Kuechle schrieb:>>> Ein anderer Grund gegen C++ im Kernel ist das Risiko an aufgeblähter>> Speichernutzung - "bloatware".>> Mah, auch ohne C++ ist der Linux-Kernel im Laufe der Zeit ziemliche> Bloatware geworden. Sagte sogar Linus schon vor 6 Jahre...>> (http://www.cnet.com/news/linus-torvalds-linux-is-bloated/> http://techie-buzz.com/foss/linux-kernel-double-size-three-years.html)
Da meint Linus aber was anderes mit bloated:
-Anzahl von Code-Zeilen im Quelltext
-Anzahl von Funktionen/Strukturen im Kernel
Original ist gemeint, das es für den "normalen" C++ Programmierer
"leichter" ist Speicher zu verschwenden als für C-Programmierer. C++
macht es "leichter" Arbeitspeicher mehr als nötig zu belegen.
Zitat:
"The greatest danger with C++ is in fact its power. It seduces the
programmer, making it much easier to write bloatware. ... I think it is
fair to say that it takes more skill to write efficient C++ code than C
code. [Developers] will not know the various tricks and traps for
producing efficient C++ code.”
MfG,
Fpga Kuechle schrieb:> Nun 50% mehr Code (1120 vs. 1734) ist schon ein deutlicher Nachteil und> das nackte Verhältnis bei den Variablen (4 vs. 144) ist schon> katastrophal.
Nun ja, ein fast leeres Programm zu testen mach meiner Meinung nach nun
doch recht wenig Sinn. Yalu hatte sich wohl dazu verleiten lassen, weil
da jemand etwas vom Magabyte geschrieben hatte. Aber in der Regel
enthält ein Programm ja deutlich mehr Code. Bei den "höheren" Sprachen
tritt natürlich das Problem auf, dass man nicht immer weiss, was hinter
den Kulissen passiert. Bei Scriptsprachen wie Python oder Ruby ist das
ja ganz extrem, da treiben manch unerfahrene Leute einen riesen Aufwand
für eine triviale Operation. Ich habe schon erlebt, dass eine Zahl in
einen String gewandelt wird, um zu Testen ob sie ungerade ist. Das kommt
eben dabei heraus, wenn man als erste und einzige Sprache Java, Python,
Ruby usw. lernt. Und bei C++ ginge es mir teilweise ähnlich, wenn ich es
denn benutzen wollte. Aber Compiler sind heute schon gut. Bei Benchmarks
ist C++ oft sogar etwas schneller als C. Und nochmal zu dem leeren
Testprogramm: Eine Hochsprache hat eben oft ein Laufzeitsystem oder auch
einen Garbage-Collector, und das ergibt dann eben einen kleinen Offset
bei der Programmgröße. Bei Nim kommt man aber für ein leeres Programm
auf weniger als 20k, bei Rust ist es wohl jetzt ähnlich. Das ist doch
wirklich schon akzeptabel.
Fpga Kuechle schrieb:> Original ist gemeint, das es für den "normalen" C++ Programmierer> "leichter" ist Speicher zu verschwenden als für C-Programmierer. C++> macht es "leichter" Arbeitspeicher mehr als nötig zu belegen.
C++ macht es dafür einfacher Speicher zu verwalten ;) .
C Schreiber schrieb:> Hab schon bisschen mehr damit gemacht..> genug um zu wissen, dass einige der hier angesprochenen "features" wie> Sicherheit durch in Klassen eingekapselte Fehlerabfragen oder ähnliches> auf Systemebene nix verloren haben.
Darüber lässt sich streiten.
C Schreiber schrieb:> Murks kann ich so oder so zusammenschreiben, da helfen die besten> libraries nichts. Fressen nur Performance, vor allem wenn sich dann im> Laufe der Zeit immer mehr Features irgendwo im Objektwust widerfinden.
C++ bietet viele Features die keine zusätzliche Performance zur Laufzeit
benötigen (siehe Templates). Und doch SmartPointer sind eine wirksame
Möglichkeit Speicherlecks zu vermeiden, da automatisiert. In C nicht
realisierbar. Ein std::unique_ptr braucht nicht mehr Ressourcen als ein
malloc/free.
C Schreiber schrieb:> Habs vergessen wie viel genau, aber ein simples hello world in c++> benötigt schon mehrere MB (!!!!)> in C bereits deutlich weniger,> und in Assembler schafft man problemlos so 150 Bytes, ohne besondere> Tricks..
Mein HelloWorld braucht 11,5 kB (11.776 Bytes). Dann schreib mal in
Assembler sowas wie einen C++ Kompiler, sag mir wenn dir der Kopf
qualmt. Ich sag nur: Das geeignete Werkzeug für die jeweilige Aufgabe.
C Schreiber schrieb:> Und hier scheint mir das Denken in Objekten einige Nachteile zu> implizieren,> eben z.B. bereits der Gedanke daran, auf Systemebene sollten immer noch> grundsätzlich Sicherheitsabfragen vorhanden sein.
OOP hat in der Tat Nachteile, aber wer zwingt dich in C++ OOP zu
benutzen? Wir sind doch nicht bei Java oder C#.
C Schreiber schrieb:> Wenn ich dann die tolle Arrayklasse mit all ihren Features geerbst habe> und daran gehe, meinen Speichermanager zu implementieren, dauert schnell> alles zehnmal länger wie ohne die features. Muss ich wohl meine eigene> Array Klasse schreiben, da die features dann ja ganz sicher private> sind. also wieder nix gewonnen.
In C hättest du die Arrayverwaltung sowieso selbst schreiben müssen. In
C++ gibt es Container die für den allgemeinen Gebrauch konzipiert sind
und für die meisten Fälle völlig ausreichend sind. Was erwartest du
eigentlich von einer Standardbibliothek? Das sie dir in jedem Fall
eine optimale Lösung präsentiert?
C Schreiber schrieb:> Hab schon bisschen mehr damit gemacht..
Ja so siehts aus.
Christian Berger schrieb:> Grob gesagt kann man aber sagen, dass die "Vorteile" von C++ in> unixoiden Betriebssystemen bereits durch das Betriebssystem abgedeckt> werden.>> Vielleicht ein schönes Beispiel ist die fakerlib. Die stellt ja in der> Regel Objekte zur Verfügung über die man plausible Fakedaten erhält.> Unter einem unixoiden Betriebssystem hätte man einfach ein "fake"> Programm welchem man Parameter übergibt und welches dann die Daten in> einem einfachen Format auf der Standardausgabe ausgibt.
Bitte was? Es gibt mehr Unterschiede zwischen C und C++ als nur die
größere Standardbibliothek. Z.B. sowas wie Sprachelemente und davon hat
C++ sehr viel mehr. Wie stellt mir Unix jetzt diese Sprachelemente zur
Verfügung? Zauberei?
Fpga Kuechle schrieb:> Nun 50% mehr Code (1120 vs. 1734) ist schon ein deutlicher Nachteil und> das nackte Verhältnis bei den Variablen (4 vs. 144) ist schon> katastrophal. Sicher nicht repräsentativ
Nö, ganz sicher nicht repräsentativ und schon garnicht katastrophal.
Du siehst bei diesem Mini-Testprogramm ja nichtmal, ob es Faktor 2 ist
oder ob es Faktor 0,5 + Konstante ist.
> aber es könnte die bekannte> Tendenz aufzeigen "c++ verschleudert Arbeitsspeicher (S/DDR-RAM)".
Nicht C++ verschwendet den Speicher, sondern der Programmierer. Bla.
Hallo,
so nicht schrieb:> Karl Käfer schrieb:>> Salewski, Stefan schrieb:>>> Für Toolkits die etwa mit C++ geschrienben sind wie Qt oder wxWidgets>>> ist das Erstellen von Wrappern für andere Sprachen deutlich>>> aufwendiger.>>>> Wie kommst Du auf diese Aussage? PyQt, PerlQt, RubyQt und sogar PHP-Qt>> existieren. In der Boost-Library gibt es sogar das Modul Boost.Python,>> das nahtlose Übergänge zwischen Python und C++ in ermöglicht.>> Erkläre mir bitte mal, warum es keine einfache Möglichkeit gibt QT (als> GUI) in einem NUR C Compiler zu nutzen,
Das weißt Du nicht? Wirklich? Dabei liegt die Antwort doch auf der Hand:
weil Qt nun einmal Gebrauch von modernen objektorientierten Features
macht, und antiquiertes "NUR C"-Spielzeug das nunmal nicht direkt kann.
Aber, wie schon erwähnt habe: für mehrere moderne, also:
objektorientierte Programmierprachen gibt es bereits fertige Qt-Wrapper.
Offensichtlich ist es also im Gegensatz zu den Behauptungen des
Vorposters gar kein Problem, Wrapper für andere Sprachen als C++ zu
bauen.
Liebe Grüße,
Karl
Karl Käfer schrieb:> Offensichtlich ist es also im Gegensatz zu den Behauptungen des> Vorposters gar kein Problem, Wrapper für andere Sprachen als C++ zu> bauen.
Dann mach mal...
Natürlich ist es kein "Problem", also nicht unmöglich. Womöglich über
eine C "Zwischenschicht". Warum Wrapper/Bindings für C++ so aufwendig
sind, dazu möchte ich nichts sagen, dazu kenne ich mich mit C++ zu wenig
aus. Aber ich habe die Wrapper-Entwicklung für moderne Sprachen in den
letzten Jahren beobachtet. Für GTK gab es in der Regel recht früh
Wrapper, obwohl das generelle Interesse für GTK ja nicht mehr so groß
ist. Für Qt und wxWidgets sah es in der Regel ziemlich schlecht aus. Für
Nim gibt es weder wxWigets noch Qt, und der Aufwand wird nach Ausssage
einiger Entwickler beträchtlich sein. Für Rust wohl ähnlich. Für
Haskell, Go, D habe ich vor einem Jahr, als ich zuletzt gesucht hatte,
jedenfalls weder WxWigets noch Qt gefunden, jedenfalls nichts
ernstzunehmendes. Ich selbst hatte mal versucht, von Ruby aus über eine
C Zwischenschicht Funktionen der CGAL und Boost Bibliothek zu nutzen.
Selbst für einige wenige Funktionen ist das schon ein beträchtlicher
Aufwand. Wrapper/Bindings für CGAL und Boost gab es jedenfalls vor drei
Jahren nur Ansatzweise. Ich denke mal, für Rust oder Nim einem Qt
Wrapper zu machen wäre über ein Jahr Vollzeitarbeit, womöglich auch weit
mehr, wenn man einen wirklich opimalen High-Level_Wrapper möchte.
Für reine C Bibliotheken sind die Wrapper zum Glück deutlich einfacher
zu erstellen. Von Ruby ist es relativ einfach, man muss sich aber
natürlich gegebenenfalls sorgfältig um den Garbage-Collector kümmern.
Für GTK etwa kann man einfach von ein paar Scripten die C Headerfiles
verarbeiten lassen und hat dann schon prinzipiel funktionierende Wrapper
-- gut ohne Garbage-Collector Support, aber bei GTK ist das wegen des
Reference-Countings auch nicht tragisch.
Salewski, Stefan schrieb:> Warum Wrapper/Bindings für C++ so aufwendig> sind, dazu möchte ich nichts sagen, dazu kenne ich mich mit C++ zu wenig> aus.
Das kommt daher, dass C++ verdammt mächtig ist und eigentlich immer mehr
Sprachfeatures bietet als die Sprache für die du den Wrapper schreibst.
Wird schwierig so etwas zu portieren. Dann kommt noch hinzu, dass bei
C++ sehr viel zur Compile-Zeit passiert, es werden zum Beispiel
Templates aufgelöst und die Codeabschnitte für den jeweiligen Typ etc.
kompiliert. Das ist nicht wie in C, was dir Maschinencode liefert der
etwa 1:1 deinen Sourcecode entspricht. Das passiert bei C natürlich auch
nicht zu 100% (Makros, inlining), allerdings ist C im Vergleich zu C++
in der Hinsicht absolut primitiv .
Qt ist da auch noch mal ein Spezialfall, weil Qt mehr ist als nur ein
GUI Framework. Qt versucht die komplette STL/stdlibc++ zu ersetzen und
arbeitet ausschließlich mit seinen eigenen Datenstrukturen. Qt ist
schlichtweg für C++ maßgeschneidert.
Hallo Stefan,
Salewski, Stefan schrieb:> dazu kenne ich mich mit C++ zu wenig aus.
Mit Verlaub: anläßlich Deiner bisherigen Einlassungen scheint mir genau
das das Hauptproblem zu sein. Du bildest Dir ein Urteil über Dinge, von
denen Du offenbar nicht viel verstehst.
> Für Haskell, Go, D habe ich vor einem Jahr, als ich zuletzt gesucht> hatte, jedenfalls weder WxWigets noch Qt gefunden,
Pardon, aber für Deine Versäumnisse bist Du selbst verantwortlich:
https://wiki.haskell.org/Applications_and_libraries/GUI_libraries#qtHaskellhttps://wiki.haskell.org/Applications_and_libraries/GUI_libraries#wxHaskell
Ist jetzt nur für Haskell, gibts aber auch für D und Go -- siehe unten.
Wenn das geklärt ist wüßte ich gerne, wie Du vom Nichtvorhandensein von
Qt- oder wx-Wrappern für irgendwelche esoterischen Exoten, und obwohl es
genau solche Wrapper seit vielen Jahren für etliche verbreitete Sprachen
gibt, zu Deiner verrückten Behauptung kommst, das Erstellen von solchen
Wrappern sei "deutlich aufwändiger".
> Ich selbst hatte mal versucht, von Ruby aus über eine C Zwischenschicht> Funktionen der CGAL und Boost Bibliothek zu nutzen.
Was soll das denn mit der "C Zwischenschicht"? Da geht es doch nur
darum, sich etwas herbei zu konstruieren, um etwas Unbeweisbares dann
doch noch irgendwie "beweisen" zu können. Laß die Shaiz-Zwischenschicht
weg, schon hast Du eine wunderbare Abbildung der Qt-API auf Ruby.
CGAL und Boost sind nun einmal explizit C++-Bibliotheken. Benutz' sie
mit C++ oder laß' es. Daß Du kein C++ kannst, ist nicht die Schuld von
Boost, CGAL oder C++, sondern, nochmals Pardon: ganz alleine Dein
Problem.
Ansonsten dürften die folgenden Links Deine Behauptung ebenso eindeutig
wie endgültig widerlegen:
http://en.wikipedia.org/wiki/List_of_language_bindings_for_wxWidgetshttp://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_4http://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_5
Übrigens: SWIG existiert.
Liebe Grüße,
Karl
TriHexagon schrieb:> Das kommt daher, dass C++ verdammt mächtig ist und eigentlich immer mehr> Sprachfeatures bietet als die Sprache für die du den Wrapper schreibst.> Wird schwierig so etwas zu portieren. Dann kommt noch hinzu, dass bei> C++ sehr viel zur Compile-Zeit passiert, es werden zum Beispiel> Templates aufgelöst und die Codeabschnitte für den jeweiligen Typ etc.> kompiliert.
Und das alles sind Dinge, die für den Wrapper völlig unerheblich sind.
Weil man den Wrapper nämlich typischerweise auch in C++ und für C
schreiben wird. So kann man innerhalb des Wrappers ganz normal C++
programmieren und exportiert dann halt einfach C-taugliche-Symbole.
> Das ist nicht wie in C, was dir Maschinencode liefert der> etwa 1:1 deinen Sourcecode entspricht. Das passiert bei C natürlich auch> nicht zu 100% (Makros, inlining), [...]
Du hast außerdem ein grundsätzliches Verständnisproblem hier.
Ich denke, du siehst das Problem an einer Stelle, wo es eigentlich
garnicht ist...
TriHexagon schrieb:> Das kommt daher,
Ja danke, das fasst das zusammen, was ich in den letzten Jahren auch
ähnlich formuliert gelesen hatte.
Was der Herr Käfer oben schreibt: Nun, ich habe nie behaupted C++ zu
können, allenfalls ansatzweise Aber ich habe doch einiges in
Mailinglisten, Blogs oder Seiten wie Reddit, HN usw. von Entwicklern
gelesen. Ansätze für Wrapper gibt es schon, ich hatte vorhin nochmal auf
der Qt Seite nachgeschaut. Den D-Wrapper etwa scheint seit Jahren keiner
mehr angefasst zu haben. Und was ich an Wrappern gesehen hatte, war dann
in der Regel extrem umfangreich. Deine Haskell Links werde ich mir
später mal ansehen, wenn es da einen guten Qt Wrapper gibt. wäre das für
mich eine Motivation mir endlich mal Haskell anzusehen.
Nase schrieb:> TriHexagon schrieb:>> Das kommt daher, dass C++ verdammt mächtig ist und eigentlich immer mehr>> Sprachfeatures bietet als die Sprache für die du den Wrapper schreibst.>> Wird schwierig so etwas zu portieren. Dann kommt noch hinzu, dass bei>> C++ sehr viel zur Compile-Zeit passiert, es werden zum Beispiel>> Templates aufgelöst und die Codeabschnitte für den jeweiligen Typ etc.>> kompiliert.> Und das alles sind Dinge, die für den Wrapper völlig unerheblich sind.> Weil man den Wrapper nämlich typischerweise auch in C++ und für C> schreiben wird. So kann man innerhalb des Wrappers ganz normal C++> programmieren und exportiert dann halt einfach C-taugliche-Symbole.
Es gibt sicher Bibliotheken die bestimmte Mechanismen in C++ umsetzen,
die sich dann aber nicht einfach Wrappen/Übertragen lassen, auch mit
extra C++/C Zwischenschicht nicht. Dummerweise fällt mir gerade kein
Beispiel ein (Boost eventuell).
Nase schrieb:>> Das ist nicht wie in C, was dir Maschinencode liefert der>> etwa 1:1 deinen Sourcecode entspricht. Das passiert bei C natürlich auch>> nicht zu 100% (Makros, inlining), [...]> Du hast außerdem ein grundsätzliches Verständnisproblem hier.> Ich denke, du siehst das Problem an einer Stelle, wo es eigentlich> garnicht ist...
Mir ist natürlich bewusst, dass das, wie ich es ausgedrückt habe, nicht
ganz richtig ist. Ich wollte damit einfach den Unterschied zwischen C
und C++ klarmachen. Eine Templateklasse wird man in einer kompilierten
Bibliothek in der ursprünglichen Form nicht finden. Das ganze Metazeug
ist nach dem Kompilieren weg.
Wo ist denn das Problem deiner Meinung nach?
Noch ein kleiner Zusatz:
Die meisten Bibliotheken haben ein einfaches Interface. Das lässt sich
dann auch einfach über eine C++/C Zwischenschicht wrappen. Das bestreite
ich überhaupt nicht. Aber es gibt halt auch andere Fälle wie Boost oder
Qt.
Yalu X. schrieb:> C Schreiber schrieb:>> Habs vergessen wie viel genau, aber ein simples hello world in c++>> benötigt schon mehrere MB (!!!!)>> in C bereits deutlich weniger,>> Jetzt übertreibst du aber ein wenig :)>> Nehmen wir folgende Hello-World-Programme:>> C>
1
#include<stdio.h>
2
>
3
>intmain(void){
4
>printf("Hello World\n");
5
>return0;
6
>}
>> C++>>
1
#include<iostream>
2
>
3
>intmain(){
4
>std::cout<<"Hello World\n";
5
>return0;
6
>}
> Kompiliert mit GCC und CLang, jeweils mit -Os und anschließender> Entfernung der Symbolinformation mit strip -s, ergeben sich folgende> Größen der Binärdateien:>>
1
> hello-gcc 3132
2
> hello-clang 3028
3
> hello-g++ 3792
4
> hello-clang++ 3808
5
>
>> Das size-Tool liefert folgenden Output:>>
1
> text data bss dec hex filename
2
> 1120 280 4 1404 57c hello-gcc
3
> 1040 280 4 1324 52c hello-clang
4
> 1734 320 144 2198 896 hello-g++
5
> 1778 320 148 2246 8c6 hello-clang++
6
>
>> Das C++-Programm braucht in diesem (nicht sehr repräsentativen) Fall> also ca. 50% mehr Speicher. Von Bloatware oder Megabytes kann deswegen> aber noch lange keine Rede sein.
Das kann ich so nicht nachvollziehen. Ohne -static linkt dein Programm
erst zur Load-Zeit; mit size wirst du also nicht sehen, was die paar
Symbole, die der Compiler in meinem Progrämmchen verwendet, so alles im
Schlepptau haben.
Versuch einfach nochmal mit -static für eine ungefähre Abschätzung, und
schau dir an was nm oder size -A so zu berichten haben! Strippen hat
übrigens keinen Einfluss auf .text oder .data.
Bein gcc/g++ 4.7.1 liefert mit -Os
1
# C
2
size -A out.exe
3
out.exe :
4
section size addr
5
.text 3144 4198400
6
.data 16 4202496
7
.rdata 224 4206592
8
.eh_frame 928 4210688
9
.bss 96 4214784
10
.idata 888 4218880
11
.CRT 24 4222976
12
.tls 32 4227072
13
14
C++
15
size -A out.exe
16
out.exe :
17
section size addr
18
.text 438916 4198400
19
.data 600 4640768
20
.rdata 26944 4644864
21
.eh_frame 5368 4673536
22
.bss 27488 4681728
23
.idata 2596 4710400
24
.CRT 24 4714496
25
.tls 32 4718592
Weil die (compilierte) "main" nur ein paar Befehle enthält, wird sich
die Optimierungsstufe auch nur marginal auf die Codegröße auswirken denn
-Os ist keine Multiliboption.
Karl Käfer schrieb:>> Erkläre mir bitte mal, warum es keine einfache Möglichkeit gibt QT (als>> GUI) in einem NUR C Compiler zu nutzen,>> Das weißt Du nicht? Wirklich? Dabei liegt die Antwort doch auf der Hand:> weil Qt nun einmal Gebrauch von modernen objektorientierten Features> macht, und antiquiertes "NUR C"-Spielzeug das nunmal nicht direkt kann.>> Aber, wie schon erwähnt habe: für mehrere moderne, also:> objektorientierte Programmierprachen gibt es bereits fertige Qt-Wrapper.> Offensichtlich ist es also im Gegensatz zu den Behauptungen des> Vorposters gar kein Problem, Wrapper für andere Sprachen als C++ zu> bauen.
Offensichtlich ist es aber doch ein Problem einen Wrapper für C-Compiler
für Qt zu basteln. Damit ist Qt für einfache Sprachen wie C schlicht
unbrauchbar.
Bevor man fragt, warum es für Qt keinen C-Wrapper gibt, sollte man sich
fragen, warum es keinen C++-Wrapper gibt.
Denn Qt verwendet ja ein erweitertes C++, das durch einen Präprozessor
(moc) erst in reguläres C++ umgesetzt wird, bevor es kompiliert wird.
Natürlich könnte man auf den moc verzichten und den Code, den dieser
erzeugen würde, direkt hinschreiben. Aber das ist wohl ziemlich
umständlich, sonst wäre der moc sicher schon längst abgeschafft worden.
Ein Wrapper – egal für welche Sprache – muss, damit er Qt genauso
komfortabel wie C++ plus moc präsentiert, in irgendeiner Form die
Funktion des moc nachbilden. Das kann bspw. dadurch geschehen, dass man
einen entsprechenden Präprozessor für die Zielsprache entwickelt. Man
kann auf diesen auch verzichten, wenn die Zielsprache über geeignete
Features (insbesondere Introspection) verfügt.
So benötigen bspw. die Wrapper für Python (PyQt und PySide) keinen
Präprozessor, weil Python diesbezüglich mächtiger als C++ ist. Zusammen
mit ein paar anderen vom Wrapper genutzten Python-Features ist die
Verwendung von Qt in Python sogar noch komfortabler als in C++.
C hingegen kennt nicht nur keine Introspection, sondern auch keine
Templates, keine Vererbung, kein Überladen von Funktionen usw. Ein
Qt-Wrapper für C wäre sicher irgendwie realisierbar, aber entweder wäre
das API so umständlich zu benutzen, dass es keiner benutzen wollte oder
man bräuchte einen Präprozessor, der noch weit über das hinausginge, was
der moc für C++ tut. Das erweiterte C, das als Input in diesen
Präprozessor hineinginge, würde sich dann aber so stark von reinem C
unterscheiden, dass man sein Programm auch gleich in C++ schreiben
könnte.
Anders sieht es bei GTK+ aus: Weil GTK+ von ganz normalen C-Programmen
ohne jegliche Spracherweiterungen genutzt werden kann und die meisten
Programmiersprachen an Mächtigkeit mit C mindestens gleichauf liegen, es
es relativ leicht, dafür Wrapper zu schreiben. Deswegen ist GTK+ für
wesentlich mehr Sprachen verfügbar als Qt. Wenn ein Wrapper dann auch
noch zusätzliche Features der Zielsprache nutzt (wie bspw. GTKmm für
C++), ist er zudem auch noch komfortabler und sicherer als das Original.
Um den Beitrag mit einem etwas modifzierten Zitat von Loriot
abzuschließen:
Ein Qt-Wrapper für C ist möglich, aber sinnlos.
Salewski, Stefan schrieb:> Deine Haskell Links werde ich mir später mal ansehen, wenn es da einen> guten Qt Wrapper gibt. wäre das für mich eine Motivation mir endlich> mal Haskell anzusehen.
Da muss ich dich leider enttäuschen: qtHaskell ist gestorben und seine
Forks so gut wie. Um Qt in Haskell zu nutzen, kannst du HsQML, einen
Wrapper um QtQuick nehmen. Damit wird das GUI-Teil einer Anwendung aber
nicht in Haskell, sondern in QML programmiert. Der verbreitetste Weg,
GUIs in Haskell zu entwicklen, scheint nach wie vor Gtk2Hs zu sein.
Johann L. schrieb:> Das kann ich so nicht nachvollziehen. Ohne -static linkt dein Programm> erst zur Load-Zeit; mit size wirst du also nicht sehen, was die paar> Symbole, die der Compiler in meinem Progrämmchen verwendet, so alles im> Schlepptau haben.
Das ist prinzipiell richtig.
Aber das Hello-World-Beispiel ist sowieso alles andere als repräsentativ
für eine "echte" Anwendung oder gar einen Kernel. Würde man jetzt auch
noch die Größe der Laufzeitbibliothek hinzurechnen, die in einem großen
Programm nur einen relativ geringen Teil der Gesamtgröße ausmacht, wäre
das Ergebnis noch verzerrter.
In deinem Test ist die Text-Section des C++-Executables um den Faktor
140 größer als beim C-Executable. Daraus zu schließen, dass C++-
Programme grundsätzlich 140-mal zu groß sind wie C-Programme, wäre arg
weit weg von der Realität. Der Faktor 1,5, der bei meinem (ebenfalls
nicht repräsentativen) Test herauskam, erscheint mir da schon sehr viel
realistischer.
Yalu X. schrieb:> Da muss ich dich leider enttäuschen: qtHaskell ist gestorben und seine> Forks so gut wie.
Danke für den Hinweis. Da Karl Käfer den Link explizit angegeben hatte,
dachte ich, dass sich da womöglich in letzter Zeit etwas getan hätte.
Yalu X. schrieb:> Denn Qt verwendet ja ein erweitertes C++, das durch einen Präprozessor> (moc) erst in reguläres C++ umgesetzt wird, bevor es kompiliert wird.> Natürlich könnte man auf den moc verzichten und den Code, den dieser> erzeugen würde, direkt hinschreiben. Aber das ist wohl ziemlich> umständlich, sonst wäre der moc sicher schon längst abgeschafft worden.
Jein, der moc ist nämlich kein Präprozessor.
In Qt schreibst du nach wie vor ganz konventionelles C++ hin, allenfalls
mit ein paar CPP-Makros. Der moc verändert deine Quelldateien überhaupt
nicht. Dein Quelltext wird 1:1 vom C++-Compiler übersetzt.
Was der moc allerdings macht: Er ergänzt. Hauptsächlich
Introspektions-Kram für die Laufzeit, damit man dynamisch Signale und
Slots binden kann usw. Das macht der moc, indem er neue C++-Module
erzeugt, die dann aber wiederum konventionelle C++-Quelltexte sind.
Das ganze Qt-Zeugs, um das C++ scheinbar erweitert wird - Q_OBJECT,
Q_PROPERTY, SIGNAL(), SLOT(), Q_ENUM, ... - expandiert im CPP in leere
Makros und wird effektiv entfernt (ok, SIGNAL und SLOT machen
CPP-Stringify). Das sind alles nur Hinweise für den moc.
Nase schrieb:> Jein, der moc ist nämlich kein Präprozessor.
Ok, der Begriff war schlecht gewählt.
> Dein Quelltext wird 1:1 vom C++-Compiler übersetzt.
Stimmt. Ich dachte erst, solche Dinge wie das "slot" in
1
privateslot:
2
...
die ja zunächst einmal wie neue Schlüsselwörter aussehen, würden vom moc
vor dem Kompilieren in irgendwelche zusätzlichen Deklarationen o.ä.
umgeschrieben. Tatsächlich werden sie aber vom C++-Präprozessor per
Makrodefinition einfach entfernt. Damit sind sie – formal gesehen –
keine Spracherweiterungen. Für den Programmierers erscheinen sie
allerdings wie neue Schlüsselwörter, sowohl was ihre Verwendung als auch
die damit verbundenen Restriktionen betrifft (so dürfen bspw. "signal"
und "slot" nicht als Identifier verwendet werden).
<Ok, ist jetzt Klugscheiß>
Yalu X. schrieb:> (so dürfen bspw. "signal"> und "slot" nicht als Identifier verwendet werden).
Das wussten die Entwickler auch. Daher kann man die Veröffentlichung
dieser Makros per Define unterbinden. Dann muss man halt Q_SLOT und
Q_SIGNALS schreiben.
Genaugenommen sind die auch nicht immer ganz leer. Q_OBJECT etwa
expandiert in die Deklaration einiger Felder fürs Meta-Objekt. Aber
dennoch alles reines C++.
Fpga Kuechle schrieb:> Und das ist gerade die resource die im Embedded Bereich am knappesten> ist und erheblich an der Batterie saugt.
Dann darfst du aber auch nicht Äpfel mit Birnen vergleichen. Das
„Helloworld“ im Embedded-Bereich ist nun mal die blinkende LED. Für
einen AVR könnte der Code in C ungefähr so aussehen:
Das hat natürlich noch ein paar AVR-Besonderheiten dabei, die durch
die dortige Architektur bedingt sind (Lage der Register DDRx/PORTx).
Bei späteren (Xmega) oder den diversen ARMs ist das alles orthogonaler
und einfacher zu zimmern.
Das C++-Äquivalent sähe ungefähr so aus:
1
#include<avr/io.h>
2
3
#define F_CPU 1E6
4
#include<util/delay.h>
5
6
classled
7
{
8
volatileuint8_t*constddr;
9
volatileuint8_t*constport;
10
constuint8_tpinmask;
11
12
public:
13
led(volatileuint8_t*portreg,uint8_tpin)
14
:
15
port(portreg),
16
ddr((volatileuint8_t*)((int)portreg-1)),
17
pinmask(1<<pin)
18
{
19
*ddr|=pinmask;
20
}
21
22
voidset(void)
23
{
24
*port|=pinmask;
25
}
26
27
voidclr(void)
28
{
29
*port&=~pinmask;
30
}
31
};
32
33
intmain(void)
34
{
35
ledled1(&PORTB,7);
36
37
for(;;)
38
{
39
led1.set();
40
_delay_ms(100);
41
led1.clr();
42
_delay_ms(100);
43
}
44
}
Auch hier als schräger Trick die Ausnutzung dessen, dass die Register
DDRx je eine Adresse unter PORTx liegen. Man könnte stattdessen auch
das in C benutzte Makro-Gewurschtel zimmern, welches aus „B“ sowie
„PORT“ und „DDR“ dann „PORTB“ und „DDRB“ baut. Wie geschrieben, bei
moderneren Prozessoren braucht man das nicht.
(In einem realen Projekt würde man sowohl das Makrogewurschtel als
auch die LED-Klasse natürlich in ein Headerfile auslagern.)
Und, was glaubst du, welche von beiden Versionen mehr Code erzeugt?
.
.
.
.
.
.
.
.
.
.
.
.
Keine. Beide erzeugen identischen Assemblercode.
Hallo,
so nicht schrieb:> Offensichtlich ist es aber doch ein Problem einen Wrapper für C-Compiler> für Qt zu basteln. Damit ist Qt für einfache Sprachen wie C schlicht> unbrauchbar.
Natürlich ist es das. Ein so mächtiges Framework wie Qt wird jeden, der
nicht über "einfache Sprachen" hinausgekommen ist, heillos überfordern.
Insofern macht ein C-Wrapper für Qt überhaupt keinen Sinn, und deswegen
würde auch niemand, der bei Verstand ist, sowas entwickeln.
Liebe Grüße,
Karl
Hallo Johann,
Johann L. schrieb:> Versuch einfach nochmal mit -static für eine ungefähre Abschätzung, und> schau dir an was nm oder size -A so zu berichten haben! Strippen hat> übrigens keinen Einfluss auf .text oder .data.
Karl Käfer schrieb:> Hallo,>> so nicht schrieb:>> Offensichtlich ist es aber doch ein Problem einen Wrapper für C-Compiler>> für Qt zu basteln. Damit ist Qt für einfache Sprachen wie C schlicht>> unbrauchbar.>> Natürlich ist es das. Ein so mächtiges Framework wie Qt wird jeden, der> nicht über "einfache Sprachen" hinausgekommen ist, heillos überfordern.> Insofern macht ein C-Wrapper für Qt überhaupt keinen Sinn, und deswegen> würde auch niemand, der bei Verstand ist, sowas entwickeln.>> Liebe Grüße,> Karl
Du musst jetzt nicht gleich beleidigend werden wenn jemand nach
Vereinfachungen sucht. Das macht jeder täglich wo es nur geht. Wer sich
unnütze Arbeit schafft obwohl's auch einfach geht, der hat entweder eine
Meise unterm Pony oder eben eine Leidenschaft. Wenn ich C++ lieb hätte
wär's meine Leidenschaft und ich würde nicht fragen. Dem ist aber nicht
oder noch nicht so. Kann ja noch kommen. Bis dahin gehe ich andere Wege
und die gibt es zum Glück auch.
Dass Qt nicht zwingen an C++ gebunden ist sieht man ja an solchen
Beispielen hier
http://www.q7basic.org/index.html
Karl Käfer schrieb:> Aber, wie schon erwähnt habe: für mehrere moderne, also:> objektorientierte Programmierprachen
Im übrigen, wer heute noch modern und objektorientiert wie oben
gleichsetzt, hat die Entwicklung der letzten Jahre wohl auch etwas
verschlafen. Siehe
http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism
Objektorientierung war vor 20 Jahren der große Hype -- heute erkennt man
aber zunehmend die Schwächen, und Objektorientierung ist nur noch ein
Paradigma unter Vielen. Mit dem Theme muss ich mich auch mal näher
beschäftigen -- ich habe jetzt ja Zeit, da ich mir dank Yalus Hinweis
nicht den verstorbenen Haskell Qt-Wrapper ansehen muss :-)
Hallo,
so nicht schrieb:> Karl Käfer schrieb:>> Natürlich ist es das. Ein so mächtiges Framework wie Qt wird jeden, der>> nicht über "einfache Sprachen" hinausgekommen ist, heillos überfordern.>> Insofern macht ein C-Wrapper für Qt überhaupt keinen Sinn, und deswegen>> würde auch niemand, der bei Verstand ist, sowas entwickeln.>> Du musst jetzt nicht gleich beleidigend werden wenn jemand nach> Vereinfachungen sucht.
Wenn ich beleidigend werden wollte, würdest Du es merken. Versprochen.
;-)
Ein objektorientiertes Framework in einer Sprache benutzen zu wollen,
die keine Objektorientierung unterstützt, kann keine Vereinfachung sein,
sondern führt zwangsläufig zu einem Krampf. Du kannst Formel1-Reifen
an Deinen Traktor schrauben, aber das ist der Feldarbeit nicht
zuträglich.
Ok, Du willst ein modernes und leistungsfähiges GUI-Framework benutzen.
Jetzt hast Du zwei Möglichkeiten: entweder, Du suchst Dir eines aus, das
mit einer Programmiersprache Deiner Wahl funktioniert. Oder, Du suchst
Dir eins aus, das problemlos und komfortabel mit einer oder mehreren
anderen Programmiersprachen benutzt werden kann und eignest Dir eine
davon an.
Du hingegen hast die dritte Option gewählt: quengeln, daß das Framework,
das Du so gerne benutzen willst, nicht reibungslos mit der Sprache
Deiner Wahl zusammengeht. Erschwerend kommt hinzu, daß Du dieses
Framework gerade wegen seiner Mächtigkeit benutzen willst, welche es
aber nur hat, weil es umfangreichen Gebrauch von Features und Konzepten
macht, die Deine recht antiquierte Programmiersprache nicht oder nur
unter Schmerzen beherrscht.
Was Du machst, ist keine Vereinfachung, sondern einfach nur widersinnig.
> Wenn ich C++ lieb hätte> wär's meine Leidenschaft und ich würde nicht fragen. Dem ist aber nicht> oder noch nicht so. Kann ja noch kommen. Bis dahin gehe ich andere Wege> und die gibt es zum Glück auch.
Du mußt C++ nicht "liebhaben". Das ist ein Werkzeug wie jedes andere,
wenn auch ein ziemlich leistungsfähiges. Wenn Du diese
Leistungsfähigkeit nicht brauchst oder sogar nicht willst --
Leistungsfähigkeit geht halt immer mit einer gewissen Komplexität einher
-- dann mußt Du Dir andere Wege suchen, völlig richtig. Aber das tust Du
ja nicht: Du hast Dich stattdessen dafür entschieden, Dich darüber zu
beschweren, daß Qt die Limitierungen Deiner antiquierten
Programmiersprache übersteigt, und anstatt einen der beiden einfachen
Wege zu gehen und Dir entweder eine passende Sprache anzueignen oder ein
anderes Framework zu suchen, kritisierst Du Qt und die Sprache in der es
implementiert ist.
> Dass Qt nicht zwingen an C++ gebunden ist sieht man ja an solchen> Beispielen hier>> http://www.q7basic.org/index.html
Niemand hat behauptet, daß Qt an C++ gebunden sei. Ich habe gesagt daß
das nicht so ist und bin dafür von Dir kritisiert worden. Qt ist relativ
stark an Objektorientierung gebunden, weil es etliche objektorientierte
Features und Konzepte nutzt. Ob diese Features nun aus C++, Perl,
Python, Ruby oder einer anderen objektorientierten Programmiersprache
heraus benutzt werden, spielt eine untergeordnete Rolle, solange die
verwendete Sprache nur eine ordentliche Unterstützung für das
objektorientierte Paradigma mitbringt.
Liebe Grüße,
Karl
Hallo,
Salewski, Stefan schrieb:> Karl Käfer schrieb:>> Aber, wie schon erwähnt habe: für mehrere moderne, also:>> objektorientierte Programmierprachen>> Im übrigen, wer heute noch modern und objektorientiert wie oben> gleichsetzt, hat die Entwicklung der letzten Jahre wohl auch etwas> verschlafen. Siehe>> http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism
Objektorientierung ist nun einmal heute der verbreitete
Industriestandard, und zwar nicht nur in C++, sondern auch in nahezu
allen anderen modernen und verbreiteten Programmiersprachen. Was die
Schöpfer von Exoten wie Clojure, Erlang und Modula dazu sagen, kann man
vermutlich nur dann für relevant halten, wenn man dringend nach
Argumenten sucht. :-)
> Objektorientierung war vor 20 Jahren der große Hype -- heute erkennt man> aber zunehmend die Schwächen, und Objektorientierung ist nur noch ein> Paradigma unter Vielen. Mit dem Theme muss ich mich auch mal näher> beschäftigen -- ich habe jetzt ja Zeit, da ich mir dank Yalus Hinweis> nicht den verstorbenen Haskell Qt-Wrapper ansehen muss :-)
Merkwürdig, ich hatte nur auf das Haskell-Wiki verlinkt. Da siehst Du
mal, wie relevant Haskell in der Praxis ist: offenbar kann das Projekt
nichtmal genug Mitstreiter anziehen, um ihr Wiki anständig zu pflegen.
Tatsache ist aber dennoch, daß Objektorientierung heute der Standard ist
und von allen Programmierparadigmen das am Weitesten verbreitete. Es hat
seine Schwächen, wie jede andere Technologie auch, und niemand würde das
ernsthaft bestreiten. Trotzdem hat es sich auf ganzer Linie
durchgesetzt, obwohl die Kritikpunkte zum Teil schon seit Jahrzehnten
bekannt sind.
Andererseits unterstützt C++, um darauf noch einmal zurückzukommen,
nicht nur objektorientierte, sondern zudem auch imperative, funktionale,
und generische Paradigmen. Man kann diese sogar innerhalb ein und
desselben Programms miteinander mischen. Trotzdem dürfte die OO das
verbreitetste Paradigma sein und ist, wie gesagt, der akzeptierte
Industriestandard -- und das übrigens nicht nur in C++, sondern in
nahezu allen verbreiteten Programmiersprachen. Das geht sogar so weit,
daß es allerlei Ansätze für nicht-objektorientierte Sprachen wie C gibt,
wie sich objektorientierte Konzepte darin abbilden lassen.
Niemand erwartet, daß Du das gut findest. Aber wenn Du nicht ständig mit
dem Kopf gegen die Wand willst, solltest Du es akzeptieren.
Liebe Grüße,
Karl
Karl Käfer schrieb:> Andererseits unterstützt C++, um darauf noch einmal zurückzukommen,> nicht nur objektorientierte, sondern zudem auch imperative, funktionale,> und generische Paradigmen. Man kann diese sogar innerhalb ein und> desselben Programms miteinander mischen.
Wenn Objektorientierung angeblich so universell und gut ist, sollte es
auch ohne weiteres möglich sein seitens eines Frameworks wie Qt für
nicht objektorientierte Sprachen wie C Gui-Objekte wie Dialogfelder
usw. bereitzustellen, die man einfach per lib-Einbindung benutzt. Keiner
hat verlangt, dass man das gesamte Qt Framework genau so unter C wie
unter C++ verwenden können soll. Die Eierlegende Wollmilchsau braucht es
in 99% aller Fälle auch gar nicht. Ein einfacher, abgespeckter Zugang zu
Qt, wie schon erwähnt per lib-Einbindung, würde genügen für das was in
der Regel an Gui-Zeugs so gebraucht wird. Das das angeblich "unsinnig"
oder unmöglich sein soll halte ich für schlicht für dummes Zeug. Die
Ansätze wie q7basic gehen schließlich in diese Richtung. Worum sollen
alle gezwungen werden auf den Vererbungswahn aufzuspringen an Stellen,
an denen sie das gar nicht brauchen, weil die Dinge auch einfacher
abgewickelt werden könnten? Darin sehe ich keinen Sinn.
Dass Qt schon lange mehr als ein Gui Framework ist, ist bekannt. Das
heißt aber noch lange nicht, dass man auch den ganzen Kram daraus
zwingend auch benutzen muss oder sollte. Genauso wenig wie man zwingend
eine blitzsaubere OOP in C++ umsetzen muss, was sowieso die Wenigsten
machen oder machen können mangels Kenntnissen, Übung, Zeit etc. C++ wird
oftmals einfach als das bessere C eingesetzt. Das weiß jeder und das ist
nun mal so. Ob dies den Predigern der "Reinstlehre" nun passt oder
nicht.
Und ja, ich sagte doch bereits. Es gibt Ausweichmöglichkeiten für C auch
ohne Qt auszukommen. Dennoch kann man ja mal die Fühler nach Qt
ausstrecken und schauen was geht. Natürlich immer im Rahmen seiner
Möglichkeiten. Nicht jeder beschäftigt sich mit dem Zeug tagtäglich oder
ist monothematisch auf nur C++ ausgerichtet.
Karl Käfer schrieb:> Andererseits unterstützt C++, um darauf noch einmal zurückzukommen,> nicht nur objektorientierte, sondern zudem auch imperative, funktionale,> und generische Paradigmen.
Und das ist auch eins der zentralen Probleme, die C++ so unpopulär
machen. C++ hat tausend Features, aber kein Konzept dahinter. Es ist ein
Sammelsurium an über Jahrzehnte gewachsenen Features, ohne Fokus.
Wie sieht "guter" und "sauberer" C++-Code aus? Da werden dir zehn
Programmierer zehn verschiedene Antworten geben!
Im Gegensatz dazu gibt es bei C eine überschaubare Menge an Features,
klare Paradigmen sowie großflächig akzeptierte Coding Conventions und
Best Practices.
so nicht schrieb:> Wenn Objektorientierung angeblich so universell und gut ist, sollte es> auch ohne weiteres möglich sein seitens eines Frameworks wie Qt für> nicht objektorientierte Sprachen wie C Gui-Objekte wie Dialogfelder usw.> bereitzustellen, die man einfach per lib-Einbindung benutzt.
Warum zum Geier[tm] sollte man sich sowas aber antun?
Anders gesagt: wer sollte denn irgendeine Motivation haben, eine
derartige Arbeit auszuführen? Derjenige müsste ja in irgendeiner
Form einen Nutzen davon haben. „Bereitstellung eines Tools für
C++-Hasser“ ist vermutlich wenig Motivation für den Batzen Arbeit,
der damit verbunden wäre.
Klar kann man auch OO in blankem C machen. Das originale C++ wurde
ja schließlich auch per cfront in C umgewandelt (wobei das mit dem
heutigen Sprachstandard sicher nicht mehr abbildbar ist), und Xt und
Motif haben auch OO-Ansätze in C gemacht. Das waren alles ziemliche
Verrenkungen. Viel stupide, langweilige Schreibarbeit.
> Dass Qt schon lange mehr als ein Gui Framework ist, ist bekannt.
Der wesentliche Vorteil dabei ist, dass sie allerlei Abstraktion der
zugrunde liegenden Plattform damit gleich erschlagen, was das Erstellen
von Code, der sowohl auf Unix, Windows und OSX läuft, ungemein
vereinfacht.
Trotzdem würde ich natürlich kein Qt als Betriebssystemkern haben
wollen, um mal auf das Thema das Threads zurückzukommen. ;-)
Jörg Wunsch schrieb:> Klar kann man auch OO in blankem C machen. Das originale C++ wurde> ja schließlich auch per cfront in C umgewandelt (wobei das mit dem> heutigen Sprachstandard sicher nicht mehr abbildbar ist), und Xt und> Motif haben auch OO-Ansätze in C gemacht. Das waren alles ziemliche> Verrenkungen. Viel stupide, langweilige Schreibarbeit.
Warum muss ich da an GObject denken?
1
/*
2
* Copyright/Licensing information.
3
*/
4
5
/* inclusion guard */
6
#ifndef __MAMAN_BAR_H__
7
#define __MAMAN_BAR_H__
8
9
#include<glib-object.h>
10
/*
11
* Potentially, include other headers on which this header depends.
Hallo,
so nicht schrieb:> Karl Käfer schrieb:>> Andererseits unterstützt C++, um darauf noch einmal zurückzukommen,>> nicht nur objektorientierte, sondern zudem auch imperative, funktionale,>> und generische Paradigmen. Man kann diese sogar innerhalb ein und>> desselben Programms miteinander mischen.>> Wenn Objektorientierung angeblich so universell und gut ist, sollte es> auch ohne weiteres möglich sein seitens eines Frameworks wie Qt für> nicht objektorientierte Sprachen wie C Gui-Objekte wie Dialogfelder> usw. bereitzustellen, die man einfach per lib-Einbindung benutzt.
Das ist nun wirklich nicht so schwer zu verstehen: wenn ein Framework in
einer Sprache mit bestimmten Features geschrieben ist, und umfangreichen
Gebrauch von diesen Features macht, ist es nunmal schwierig, es in einer
Sprache zu benutzen, die diese Features nicht unterstützt. Dies vor
allem auch deswegen, weil es gerade diese Features sind, die das
Framework so mächtig machen, daß man es benutzen will.
> Ein einfacher, abgespeckter Zugang zu Qt, wie schon erwähnt per> lib-Einbindung, würde genügen für das was in der Regel an Gui-Zeugs so> gebraucht wird.
Da C weder Vererbung noch Überladung unterstützt, müßtest Du für jeden
möglichen Dialog und alle Abkömmlinge je eine eigene Implementierung
schreiben. Klar, das kann man machen, wenn man auf Schmerzen steht.
Bedeutend weniger aufwändig dürfte es allerdings sein, sich eine der
objektorientierten Sprachen anzueigenen, die Qt nativ, direkt und
vollständig unterstützen. Python, Ruby, Perl, Q7basic -- es gibt da
etliche vernünftigere Möglichkeiten als den Versuch, objektorientierte
Features mit einer Sprache abzubilden, die das nicht kann.
Übrigens: eine zweie Programmiersprache zu lernen, ist nicht so schwer,
wie eine erste Programmiersprache zu lernen. Bei der ersten Sprache muß
man üblicherweise erstmal das Programmieren selbst lernen, was meistens
der größte Aufwand bei der ganzen Sache ist. Da man das bei der zweiten
oder n-ten Sprache aber bereits beherrscht, geht es dann nur noch darum
wie man dieselben Probleme mit den neuen Mitteln löst.
> Das das angeblich "unsinnig" oder unmöglich sein soll halte ich für> schlicht für dummes Zeug.
Es ist unsinnig, weil der absehbare Aufwand den potentiellen Nutzen bei
Weitem übersteigt. Ansonsten steht es Dir natürlich gerne und jederzeit
frei, ein entsprechendes Projekt beginnen. Darauf zu bestehen, daß das
doch sicherlich irgendwie gehen müsse und daß andere bitteschön diese
Arbeit zu machen hätten, ist nämlich irgendwie lame.
> Die Ansätze wie q7basic gehen schließlich in diese Richtung.
Nein. Q7basic ist objektorientiert, verstehst Du? Es geht gar nicht um
C++, sondern um Objektorientierung. Wenn objektorientierte Features so
einfach mit den Möglichkeiten einer nicht-objektorientierten Sprache
abgebildet werden könnten, hätte man Sprachen wie C und Pascal nicht zu
objektorientierten Sprachen wie Objective-C, C++, Object Pascal, Delphi
und Oberon weiterentwickelt. Diese werden auch nicht zum Vergnügen als
eigenständige Sprachen betrachtet, sondern, weil es viele fundamentale
Unterschiede zu ihren nicht-objektorientierten Vorgängern gibt.
Liebe Grüße,
Karl
Hallo drama,
drama schrieb:> Und das ist auch eins der zentralen Probleme, die C++ so unpopulär> machen.
Einen seit Jahrzehnten etablierten Industriestandard als "unpopulär" zu
bezeichnen, ist mindestens gewagt. ;-)
> C++ hat tausend Features, aber kein Konzept dahinter.
Daß Du die Konzepte nicht kennst oder nicht verstehst spricht zum Glück
nicht gegen ihre Existenz. Da gibts ein ausgesprochen lesenswertes Buch
über diese Konzepte, es heißt "The Design und Evolution of C++" und ist
von einem, der es wissen sollte -- nämlich vom Schöpfer der Sprache C++
selbst, Bjarne Stroustrup. Wenn Dich die Konzepte interessieren, findest
Du dort alles, was Du darüber wissen möchtest.
> Es ist ein Sammelsurium an über Jahrzehnte gewachsenen Features, ohne> Fokus.
Von wegen. Das behaupten meistens Leute, die vor sich selbst
rechtfertigen wollen, sich entweder nicht einarbeiten zu wollen oder mit
der Mächtigkeit überfordert zu sein.
> Wie sieht "guter" und "sauberer" C++-Code aus? Da werden dir zehn> Programmierer zehn verschiedene Antworten geben!
Das mag sein, ist aber letztlich nur ein Beweis für die besonders große
Mächtigkeit und Flexibilität dieser Sprache.
> Im Gegensatz dazu gibt es bei C eine überschaubare Menge an Features,> klare Paradigmen sowie großflächig akzeptierte Coding Conventions und> Best Practices.
Daß Du keine kennst, heißt ja nicht, daß es keine gibt. MISRA C++, JSF
AV C++ und die Guidelines für Secure Coding der CMU existieren.
Liebe Grüße,
Karl
TriHexagon schrieb:> Jörg Wunsch schrieb:>> Klar kann man auch OO in blankem C machen. Das originale C++ wurde>> ja schließlich auch per cfront in C umgewandelt (wobei das mit dem>> heutigen Sprachstandard sicher nicht mehr abbildbar ist), und Xt und>> Motif haben auch OO-Ansätze in C gemacht. Das waren alles ziemliche>> Verrenkungen. Viel stupide, langweilige Schreibarbeit.>> Warum muss ich da an GObject denken?>> [...]>> Würg... typisch Masochisten.
Da muss ich dir recht geben, aber wenn man sich das antut hat man ganz
automagisch bindings für zahlreiche Sprachen da. GObject introspection
macht's möglich.
Lukas, hast Du schon mal etwas mit GObject Introspection gemacht? Also
ich habe das bisher nicht wirklich durchschaut, meine Nim Bindings habe
ich direkt aus den Header Files generiert, mit Nims c2nim geht das auch
ganz gut. Ich habe jetzt die wichtigsten 10 Module komplett, das sollte
GTK 3.16 abdecken, aber mit 3.18 oder GTK 4.0 gäbe es leider neue
Arbeit. Mein Eindruck war bisher, dass Introspection eher für
interpretierte Sprachen wie Python und Ruby ist. GTKmm verwendet ja wohl
(noch) kein Introspection? Aber wenn man sich damit wirklich das Leben
leichter machen kann, sollte ich mich wohl irgendwann mal damit
beschäftigen.