Linux und (immer noch) C

Linus ist gegen C++ im Kernel weil dessen "exception handling broken" 
ist.
Ein anderer Grund gegen C++ im Kernel ist das Risiko an aufgeblähter 
Speichernutzung - "bloatware".

Da stehts detailliert beschrieben:
http://www.embedded.com/design/programming-languages-and-tools/4429790/1/How-to-make-C--more-real-time-friendly

MfG,

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

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.

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.

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.

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:
> Diese Möglichkeit gibt es doch.

Genaugenommen wurde die auch schon umgesetzt, nämlich in der CLX, die 
damals mal mit Kylix ausgeliefert wurde(*)

(*) 
https://books.google.de/books?id=mpvSnBZTsOgC&lpg=PA332&ots=qvDz7V3CAY&dq=qt%20c%20wrapper&hl=de&pg=PA332#v=onepage&q=qt%20c%20wrapper&f=false

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

http://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.

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.

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

> int main(void) {

4

>   printf("Hello World\n");

5

>   return 0;

6

> }

7

>

>
> C++
>
>

1

> #include <iostream>

2

> 

3

> int main() {

4

>   std::cout << "Hello World\n";

5

>   return 0;

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#qtHaskell
https://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_wxWidgets
http://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_4
http://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.

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.

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.

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

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.

1

k@rl$ cat main.c

2

#include <stdio.h>

3

int main(void) { printf("Hello world.\n"); }

4

k@rl$ cat main.cpp

5

#include <cstdio>

6

int main(void) { printf("Hello world.\n"); }

7

k@rl$ gcc -static -flto -Os -o main-c main.c && strip main-c

8

k@rl$ g++ -static -flto -Os -o main-c++ main.cpp && strip main-c++

9

k@rl$ size main-*

10

   text    data     bss     dec     hex filename

11

 782024    7532    9600  799156   c31b4 main-c

12

 782040    7532    9600  799172   c31c4 main-c++

13

k@rl$ du -hsb main-*

14

795864  main-c

15

795864  main-c++

Die Text-Sektion des C++-Kompilats ist 16 Bytes (0,002 Prozent) größer. 
Hat da jemand "Ressourcenverschwendung" gesagt? ;-)

Liebe Grüße,
Karl

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.

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.

12

 */

13

14

/*

15

 * Type macros.

16

 */

17

#define MAMAN_TYPE_BAR                  (maman_bar_get_type ())

18

#define MAMAN_BAR(obj)                  (G_TYPE_CHECK_INSTANCE_CAST ((obj), MAMAN_TYPE_BAR, MamanBar))

19

#define MAMAN_IS_BAR(obj)               (G_TYPE_CHECK_INSTANCE_TYPE ((obj), MAMAN_TYPE_BAR))

20

#define MAMAN_BAR_CLASS(klass)          (G_TYPE_CHECK_CLASS_CAST ((klass), MAMAN_TYPE_BAR, MamanBarClass))

21

#define MAMAN_IS_BAR_CLASS(klass)       (G_TYPE_CHECK_CLASS_TYPE ((klass), MAMAN_TYPE_BAR))

22

#define MAMAN_BAR_GET_CLASS(obj)        (G_TYPE_INSTANCE_GET_CLASS ((obj), MAMAN_TYPE_BAR, MamanBarClass))

23

24

typedef struct _MamanBar        MamanBar;

25

typedef struct _MamanBarClass   MamanBarClass;

26

27

struct _MamanBar

28

{

29

  /* Parent instance structure */

30

  GObject parent_instance;

31

32

  /* instance members */

33

};

34

35

struct _MamanBarClass

36

{

37

  /* Parent class structure */

38

  GObjectClass parent_class;

39

40

  /* class members */

41

};

42

43

/* used by MAMAN_TYPE_BAR */

44

GType maman_bar_get_type (void);

45

46

/*

47

 * Method definitions.

48

 */

49

50

#endif /* __MAMAN_BAR_H__ */

1

struct _MamanBarPrivate

2

{

3

  int hsize;

4

};

5

6

G_DEFINE_TYPE_WITH_PRIVATE (MamanBar, maman_bar, G_TYPE_OBJECT)

7

8

static void

9

maman_bar_class_init (MamanBarClass *klass)

10

{

11

}

12

13

static void

14

maman_bar_init (MamanBar *self)

15

{

16

  /* maman_bar_get_instance_private() is generated by G_DEFINE_TYPE_WITH_PRIVATE()

17

   * above, and it's local to the current compilation unit.

18

   */

19

  MamanBarPrivate *priv = maman_bar_get_instance_private (self);

20

21

  priv->hsize = 42;

22

}

Würg... typisch Masochisten.

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

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.