Linux und (immer noch) C

[Joachim .. (joachim_01)]

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

[Dirk B. (dirkb2)]

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

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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

[Le X. (lex_91)]

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)

[Michael R. (Firma: Brainit GmbH) (fisa)]

Dirk B. schrieb:
> itoa() ist unsicher.

Warum?

[Dirk B. (dirkb2)]

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 D. (oldbug)]

Michael Reinelt schrieb:
> Warum?

Wegen:

char *  itoa ( int value, char * str, int base );

* str könnte zu klein sein, es fehlt ein Längenargument.

[Michael R. (Firma: Brainit GmbH) (fisa)]

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.

[Dirk B. (dirkb2)]

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.

[Yalu X. (yalu) (Moderator)]

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 :)

[Joachim .. (joachim_01)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[P. M. (o-o)]

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.

[Frank M. (ukw) (Moderator)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.

[Axel S. (a-za-z0-9)]

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.

[Fpgakuechle K. (Gast)]

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,

[Transistorfips (Gast)]

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

[Skyper (Gast)]

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

[Salewski, Stefan (Gast)]

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.

[TriHexagon (Gast)]

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.

[Eric B. (beric)]

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)

[TriHexagon (Gast)]

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?

[B. S. (bestucki)]

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.

[Uhu U. (uhu)]

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 ;-)

[Thorsten (Gast)]

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.

[Oliver S. (oliverso)]

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

[TriHexagon (Gast)]

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.

[Karl H. (kbuchegg)]

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

[Udo S. (urschmitt)]

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.

[Karl H. (kbuchegg)]

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.

[Bernd K. (prof7bit)]

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.

[Yalu X. (yalu) (Moderator)]

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.

[TriHexagon (Gast)]

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.

[Bernd K. (prof7bit)]

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.

[klugscheisser (Gast)]

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.

[TriHexagon (Gast)]

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

[denial (Gast)]

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.

[Bastler (Gast)]

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.

[C Schreiber (Gast)]

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

[C Schreiber (Gast)]

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

[Karl Käfer (Gast)]

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

[Karl Käfer (Gast)]

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

[Karl Käfer (Gast)]

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

[Karl Käfer (Gast)]

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

[Karl Käfer (Gast)]

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

[so nicht (Gast)]

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.

[Nase (Gast)]

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 (Gast)]

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

[so nicht (Gast)]

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.

[so nicht (Gast)]

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.

[Christian B. (casandro)]

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.

[Nase (Gast)]

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.

[Nase (Gast)]

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.

[so nicht (Gast)]

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.

[so nicht (Gast)]

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.

[Nase (Gast)]

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

[Nase (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

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

#include <stdio.h>

int main(void) {
  printf("Hello World\n");
  return 0;
}

C++

#include <iostream>

int main() {
  std::cout << "Hello World\n";
  return 0;
}

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:

hello-gcc      3132
hello-clang    3028
hello-g++      3792
hello-clang++  3808

Das size-Tool liefert folgenden Output:

   text    data     bss     dec     hex filename
   1120     280       4    1404     57c hello-gcc
   1040     280       4    1324     52c hello-clang
   1734     320     144    2198     896 hello-g++
   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.

[so nicht (Gast)]

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.

[Nase (Gast)]

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.

[Nase (Gast)]

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

[temp (Gast)]

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.

[Fpgakuechle K. (Gast)]

Yalu X. schrieb:

> Nehmen wir folgende Hello-World-Programme:
>
> C
>
>

> #include <stdio.h>
> 
> int main(void) {
>   printf("Hello World\n");
>   return 0;
> }
>

>
> C++
>
>

> #include <iostream>
> 
> int main() {
>   std::cout << "Hello World\n";
>   return 0;
> }
>

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

>    text    data     bss     dec     hex filename
>    1120     280       4    1404     57c hello-gcc
>    1040     280       4    1324     52c hello-clang
>    1734     320     144    2198     896 hello-g++
>    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.

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,

[Fpgakuechle K. (Gast)]

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,

[Salewski, Stefan (Gast)]

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.

[TriHexagon (Gast)]

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

[TriHexagon (Gast)]

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.

[TriHexagon (Gast)]

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?

[Nase (Gast)]

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.

[Karl Käfer (Gast)]

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

[Salewski, Stefan (Gast)]

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.

[TriHexagon (Gast)]

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.

[Karl Käfer (Gast)]

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

[Nase (Gast)]

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

[Salewski, Stefan (Gast)]

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.

[TriHexagon (Gast)]

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?

[TriHexagon (Gast)]

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.

[Johann L. (gjlayde)]

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
>

#include <stdio.h>
> 
> int main(void) {
>   printf("Hello World\n");
>   return 0;
> }

>
> C++
>
>

#include <iostream>
> 
> int main() {
>   std::cout << "Hello World\n";
>   return 0;
> }

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

> hello-gcc      3132
> hello-clang    3028
> hello-g++      3792
> hello-clang++  3808
>

>
> Das size-Tool liefert folgenden Output:
>
>

>    text    data     bss     dec     hex filename
>    1120     280       4    1404     57c hello-gcc
>    1040     280       4    1324     52c hello-clang
>    1734     320     144    2198     896 hello-g++
>    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.

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

# C
size -A out.exe
out.exe  :
section          size      addr
.text            3144   4198400
.data              16   4202496
.rdata            224   4206592
.eh_frame         928   4210688
.bss               96   4214784
.idata            888   4218880
.CRT               24   4222976
.tls               32   4227072

C++
size -A out.exe
out.exe  :
section            size      addr
.text            438916   4198400
.data               600   4640768
.rdata            26944   4644864
.eh_frame          5368   4673536
.bss              27488   4681728
.idata             2596   4710400
.CRT                 24   4714496
.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.

[so nicht (Gast)]

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. (yalu) (Moderator)]

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.

[Yalu X. (yalu) (Moderator)]

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.

[Yalu X. (yalu) (Moderator)]

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.

[Salewski, Stefan (Gast)]

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.

[Nase (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

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

  private slot:
    ...

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

[Nase (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

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:

#include <avr/io.h>

#define F_CPU 1E6
#include <util/delay.h>

#define LED1 B, 7

#define CONCAT(x, y) x ## y

#define LEDINIT_(port, pin) CONCAT(DDR, port) |= (1 << (pin))
#define LEDINIT(led) LEDINIT_(led)
#define LEDSET_(port, pin) CONCAT(PORT, port) |= (1 << (pin))
#define LEDSET(led) LEDSET_(led)
#define LEDCLR_(port, pin) CONCAT(PORT, port) &= ~(1 << (pin))
#define LEDCLR(led) LEDCLR_(led)

static void
ioinit(void)
{
  LEDINIT(LED1);
}

int
main(void)
{
  ioinit();

  for (;;)
    {
      LEDSET(LED1);
      _delay_ms(100);
      LEDCLR(LED1);
      _delay_ms(100);
    }
}

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:

#include <avr/io.h>

#define F_CPU 1E6
#include <util/delay.h>

class led
{
  volatile uint8_t * const ddr;
  volatile uint8_t * const port;
  const uint8_t pinmask;

public:
  led(volatile uint8_t *portreg, uint8_t pin)
    :
    port(portreg),
    ddr((volatile uint8_t *)((int)portreg - 1)),
    pinmask(1 << pin)
    {
      *ddr |= pinmask;
    }

  void set(void)
    {
      *port |= pinmask;
    }

  void clr(void)
    {
      *port &= ~pinmask;
    }
};

int main(void)
{
  led led1(&PORTB, 7);

  for (;;)
    {
      led1.set();
      _delay_ms(100);
      led1.clr();
      _delay_ms(100);
    }
}

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.

[Karl Käfer (Gast)]

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

[Karl Käfer (Gast)]

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.

k@rl$ cat main.c
#include <stdio.h>
int main(void) { printf("Hello world.\n"); }
k@rl$ cat main.cpp
#include <cstdio>
int main(void) { printf("Hello world.\n"); }
k@rl$ gcc -static -flto -Os -o main-c main.c && strip main-c
k@rl$ g++ -static -flto -Os -o main-c++ main.cpp && strip main-c++
k@rl$ size main-*
   text    data     bss     dec     hex filename
 782024    7532    9600  799156   c31b4 main-c
 782040    7532    9600  799172   c31c4 main-c++
k@rl$ du -hsb main-*
795864  main-c
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

[so nicht (Gast)]

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

[Salewski, Stefan (Gast)]

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 :-)

[Karl Käfer (Gast)]

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

[Karl Käfer (Gast)]

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

[so nicht (Gast)]

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.

[drama (Gast)]

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 W. (dl8dtl) (Moderator)]

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

[TriHexagon (Gast)]

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?

/*
 * Copyright/Licensing information.
 */

/* inclusion guard */
#ifndef __MAMAN_BAR_H__
#define __MAMAN_BAR_H__

#include <glib-object.h>
/*
 * Potentially, include other headers on which this header depends.
 */

/*
 * Type macros.
 */
#define MAMAN_TYPE_BAR                  (maman_bar_get_type ())
#define MAMAN_BAR(obj)                  (G_TYPE_CHECK_INSTANCE_CAST ((obj), MAMAN_TYPE_BAR, MamanBar))
#define MAMAN_IS_BAR(obj)               (G_TYPE_CHECK_INSTANCE_TYPE ((obj), MAMAN_TYPE_BAR))
#define MAMAN_BAR_CLASS(klass)          (G_TYPE_CHECK_CLASS_CAST ((klass), MAMAN_TYPE_BAR, MamanBarClass))
#define MAMAN_IS_BAR_CLASS(klass)       (G_TYPE_CHECK_CLASS_TYPE ((klass), MAMAN_TYPE_BAR))
#define MAMAN_BAR_GET_CLASS(obj)        (G_TYPE_INSTANCE_GET_CLASS ((obj), MAMAN_TYPE_BAR, MamanBarClass))

typedef struct _MamanBar        MamanBar;
typedef struct _MamanBarClass   MamanBarClass;

struct _MamanBar
{
  /* Parent instance structure */
  GObject parent_instance;

  /* instance members */
};

struct _MamanBarClass
{
  /* Parent class structure */
  GObjectClass parent_class;

  /* class members */
};

/* used by MAMAN_TYPE_BAR */
GType maman_bar_get_type (void);

/*
 * Method definitions.
 */

#endif /* __MAMAN_BAR_H__ */

struct _MamanBarPrivate
{
  int hsize;
};

G_DEFINE_TYPE_WITH_PRIVATE (MamanBar, maman_bar, G_TYPE_OBJECT)

static void
maman_bar_class_init (MamanBarClass *klass)
{
}

static void
maman_bar_init (MamanBar *self)
{
  /* maman_bar_get_instance_private() is generated by G_DEFINE_TYPE_WITH_PRIVATE()
   * above, and it's local to the current compilation unit.
   */
  MamanBarPrivate *priv = maman_bar_get_instance_private (self);

  priv->hsize = 42;
}

Würg... typisch Masochisten.

[Karl Käfer (Gast)]

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

[Karl Käfer (Gast)]

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 K. (carrotindustries)]

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.

[Salewski, Stefan (Gast)]

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.