Archiv verlassen und diese Seite im Standarddesign anzeigen : warum ist Linux in C und nicht in C++ geschrieben
Hallo,
Grundsatzfrage : Warum is der Linux Kernel eigentlich in C geschrieben und nicht in C++ bzw C/C++ ?
Gegenfrage: Wieso sollte er in C++ gechrieben sein?
From: Linus Torvalds [email blocked]
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)
On Tue, 20 Jan 2004, Robin Rosenberg wrote:
>
> This is the "We've always used COBOL^H^H^H^H" argument.
In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:
- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
Feel free to make up (d).
mfg dct.c
Das sollte deine Fragen beantworten:
http://www.tux.org/lkml/#s15-3
C++ ist IMHO komplexer (d.h. auch schlechtere Performance), daher weniger überschaubar, nicht so nah an der Maschine und nicht so ausgereift wie C.
stefan-tiger
20.02.05, 19:16
1. Jedes C Program ist auch ein gültiges C++ Programm
2. damals waren C++ kompiler so, dass sie C++ Klassen und C structs umgewandelt haben und dann den C Code kompiliert haben, deswegen war es nicht idel C++ zu verwenden.
Gruß
1. Jedes C Program ist auch ein gültiges C++ Programm
Nope. *ZehnZeichen*
1985 erschien die erste Version von C++, die eine wichtige Referenzversion darstellte, da die Sprache damals noch nicht standardisiert war. 1989 erschien die Version 2.0 von C++. Neu darin waren Mehrfachvererbung, abstrakte Klassen, statische Elementfunktionen, konstante Elementfunktionen und die Erweiterung des Schutzmodells um protected. 1990 erschien das Buch The Annotated C++ Reference Manual, das als Grundlage für den darauffolgenden Standardisierungsprozess diente.
Ich würde sagen zu den Linux-Anfangszeiten war C++ weder ausgereift, noch verbreitet, vielleicht noch nichteinmal produktiv benutzbar.
Deshalb ist zumindest der Anfangs-Kernel in C geschrieben, warum sollte man dann später umsteigen (Kompatibilität) bzw. den Kernel nochmal in C++ neu schreiben (Aufwand, ernstzunehmende Gründe).
~eli
stefan-tiger
20.02.05, 20:35
Nope. *ZehnZeichen*
Warum nicht?
Nope. *ZehnZeichen*
Ich denke auch, dass das so ist. Das ist doch auch das, was einige Programmierer nervt, naemlich
die Kompatiblitaet zu C. (siehe strings....)
Wieso C? Der Hauptgrund ist PORTABILITÄT auf andere Systeme und das ist nach wie vor so. Man lese http://www.kerneltrap.org/
Da findet ihr haufenweise Diskussionen.
Warum nicht?
Weil es nicht ganz so ist. Bis C99 war es fast zu 100% so... Aber nur fast. Die genauen Unterschiede weiss ich jetzt nicht mehr. Seit C99 wurde C nochmal ein wenig anders... auch wieder keine Ahnung was dazu gekommen ist...
Auf jedenfall ist C nicht zu 100% eine Untermenge von C++, auch wenn es oft danach aussieht...
stefan-tiger
21.02.05, 08:23
Weil es nicht ganz so ist. Bis C99 war es fast zu 100% so... Aber nur fast. Die genauen Unterschiede weiss ich jetzt nicht mehr. Seit C99 wurde C nochmal ein wenig anders... auch wieder keine Ahnung was dazu gekommen ist...
Auf jedenfall ist C nicht zu 100% eine Untermenge von C++, auch wenn es oft danach aussieht...
Auf Wikipedia steht das selbe, nur habe ich noch kein C Code gehabt den man nicht mit einem C++ Compilier kompilieren kann.
Gut, dass C++ nich die Wahl der Mittel war 1992 is mir auch klar, da hat C wohl einfach auch den Vorteil, dass es frueher entwickelt wurde und wohl damals schlicht ausgereifter war. Allein was ich ueber Exception Handling zB bei Scott Meyers gelesen hab: er entschuldigte sich in "More Effective C++" dafuer, dass manche Codes nicht auf Compilern liefen, die von vor 1995 sind, auf Grund des fehlenden Exception Handling. Afaik gabs die erste wirkliche Standartisierung von C++ 1998 (ISO/IEC 14882:1998) und von C dagegen schon 1990 (ISO/IEC 9899:1990).
Ausserdem kann man bei ihm nachlesen (weiss aber nicht mehr genau wo), dass C++ Operationen nicht mehr als 5% der Zeit benoetigen sollen, als vergleichbare in C. Dazu soll C++ Vorteile haben, die versch. Fehlermoeglichkeiten von C einfach ausschliessen. Wobei allerdings dann die Fehler, die bei C++ entstehen koennen um einiges heftigere Wirkungen haben koennen sollen, wie etwa undefiniertes Verhalten, bei falscher Benutzung von manchen STL Methoden, was auch ekelhaft zu finden sein muss ("C macht es einfach sich in den Fuss zu schiessen, C++ erschwert es, aber wenn man es tut, blaest es einem das ganze Bein weg." B.Stroustrup).
Ich denke es gibt wohl einige Dinge, die man bei C++ durch die Standartisierung ausmerzen kann (zB unterschiedliche STL Implementationen, die es immer noch geben soll) oder bereits ausgemertzt hat. Allerdings kann ich verstehen, dass trotzdem eine gewisse Kaschierung von allokiertem Speicher stattfindet und dass das fuer Kernel entwicklung kontraproduktiv ist, ist mir auch irgendwie klar.
Fuer C++ spraechen allerdings ein durchschaubaererer Code, da C von Grunde auf ja keine objektorientierte Sprache ist, ist allein der Code der betrieben werden muss um OOP zu erreichen ja doch auch in sich recht komplex. Allein auch das Umgehen von Fehlermoeglichkeiten, denke ich koennte doch die Entwicklung von Applikationen in C++ schneller machen als mit C und dabei zu vergleichbaren Resultaten fuehren, oder irre ich mich da?
Naja und auch dass nun nicht von heute auf morgen nochmal der komplette Kernel in C++ neu geschrieben wird, blos weil dieses nun auch ihre Standartisierung hatte, verstehe ich. Allerdings, imo afaik ist der Kernel auch in C sogar mit asm Teilen geschrieben worden und da wundert mich halt dass heutzutage nicht auch Teile in C++ erledigt werden. Ob es wirklich nur die Macht der Gewohnheit der Entwickler ist ?! Ich bin selber blutiger Anfaenger mit C/C++ und habe mehr drueber gelesen, als irgendeine langjaehrige praktische Erfahrung damit gemacht. Aber hier sind sicherlich Leute, die meine Thesen mal kommentieren koennen ;)
In C99 gibt es komplexe Zahlen als Datentyp. Ich glaube das hat C++ nicht.
#include <complex>
sollte helfen, http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=complex.html
Aber man kann afaik auch C Libraries fuer C++ hernehmen, nur wird davon abgeraten, denn warum C++ mit C Libraries, dann kann man gleich beim C bleiben, wenn man die Vorteile von C++ nicht ausnutzen will.
Ich moechte hier nich gegen C wettern, ganz im Gegenteil ich halte C fuer irgendwie magisch und bin immer wieder beeindruckt davon wieviel man mit den, im Verhaeltnis zu C++, doch wenigen gegebenen Mitteln eigentlich machen kann - ich halte C nur auch eigentlich fuer schwerer, da man viel mehr wissen muss ueber das Verhalten des Codes, als wenn man wie in C++ Libraries bedienen kann und so viele Gefahren auch umgeht.
Auf jedenfall ist C nicht zu 100% eine Untermenge von C++, auch wenn es oft danach aussieht...
What? Du stellst Stroustrup in Frage?
"C++ ist eine Programmiersprache, die entworfen wurde, um das
Programmieren fuer den ernsthaften Programmierer angenehmer zu machen. Bis auf kleine Details ist C++ eine Obermenge der Programmiersprache C."
C++ implementiert OOP, was programmieren allgemein einfacher macht ab einer bestimmten Grösse.
Warum nicht?
Eine Suche in comp.lang.c (mittels google oder was weiß ich) sollte dir diese Frage ausführöich beantworten können. Das habe ich auf die Schnelle gefunden:
We could spend days discussing various language aspects that
make C and C++ two different (but similar) languages, but this
would be useless; after all, it's been done to death in this
newsgroup countless times. You might want to search DejaNews.
Instead, I usually like to use a more real-world, practical
example. You're invited to participate.
1) Download a piece of freely-available, widely-portable C
software (my standard suggestion is GNU "indent.")
2) In the Makefile, replace the name of the C compiler with
the name of your C++ compiler (i.e., change "cc" to "CC")
3) Attempt to build. Note results.
4) Re-evaluate statement "C is a subset of C++."
Edit: Hier der ganze Thread: <707hi0$au5@bugsbunny.matrox.com> (http://groups.google.de/groups?threadm=707hi0%24au5%40bugsbunny.matrox.com )
What? Du stellst Stroustrup in Frage?
Auch aus c.l.c.:
If you would read what BS actually wrote, you would understand that
a) The statement "C is a subset of C++" is false.
b) BS does NOT maintain that "C is a subset of C++".
BS should sue the several thousand C++ programmers who "quote" him as
saying something that is not ture, that he knows is not true, and that
he does not say.
Indeed you only need to read [Bjarne Stroustrup's] books such as "the C++ programming language"
(third edition) where he makes it quite clear that C++ is not a supertset of
C (he has confirmed this position on the newsgroups). Indeed appendix B
lists C constructs that C++ either does not support or implements with
different semantics.
What? Du stellst Stroustrup in Frage?
Wie könnte ich? :cool: Stroustrups Buch ist meine Bibel! Ich habe sie in zwei Ausführungen zu Hause, plus einen Notfall-Stroustrup in einem feuerresistenten Panzer. Als ich mal in Urlaub gefahren bin, habe ich aus versehen vergessen einen meiner Stroustrup mitzunehmen. Ich war nervös und fing an zu zittern. Konnte meinen Urlaub gar nicht mehr geniessen und habe ihn nach vier Tagen abgebrochen :ugly:
"C++ ist eine Programmiersprache, die entworfen wurde, um das
Programmieren fuer den ernsthaften Programmierer angenehmer zu machen. Bis auf kleine Details ist C++ eine Obermenge der Programmiersprache C."
Wie du geschrieben hast "Bis auf kleine Details". Die Passage habe ich zwar nicht mehr genau im Kopf gehabt, aber ich bin mir sicher, dass du das fehlerfrei auswendiggelernt hast :D
Ich glaube er hat das noch irgendwie ausführlicher beschrieben...
Wie du geschrieben hast "Bis auf kleine Details". Die Passage habe ich zwar nicht mehr genau im Kopf gehabt, aber ich bin mir sicher, dass du das fehlerfrei auswendiggelernt hast :D
OK, also nicht zu 100 %. In der praktischen Welt ist aber eh nichts 100 %ig, ohne philosophisch zu werden... :)
Naja, aber die ganze Diskussion gerade geht ja etwas am Thema vorbei.
Denn selbst wenn wir annehmen das C Code zu 100% mit einem C++ Kompiler übersetzt werden kann beantwortet das nicht wirklich die Frage.
Meine Persönliche Meinung. Zuerst will ich sagen, dass ich lange Zeit C++ für kleine bis mittlere (private) Projekte verwendet habe.
Heute habe ich eine etwas andere Sicht:
- C ist die perfekte "High-Level-Assambler-Sprache" und damit perfekt für Basis Sachen wie Kernel, Libs usw.
- C++, um meinem Prof zu zitieren, ist eine Sprache bei der man so lange an C irgendwelche "Beine", "Ohren" und andere Teile angebaut hat bis es einigermaßen das machte was man wollte. Dadurch ist ein Monster entstanden, dass sehr mächtig aber auch sehr "gefährlich" ist.
Interessant ist, dass es selbst heute ja noch größere Probleme bei C++ z.B. mit der portabilität geben kann (Stichwort: STL), was imho auch zeigt, dass C++ der erste Versuch war (ausgehend von einer Low-Level Sprache) eine brauchbare OOP Sprache zu implementieren. Aber es war der erste Versuch und es wurden imho viele Fehler gemacht aus denen zukünftige Entwicklungen lernen konnten und heute sehr gut dastehen und die "erste Designstudie C++" immer überflüssiger machen.
C hat noch, wie gesagt, seinen Platz bei allen "Basis-Programmen" oder teilweise im embedded-Bereich.
Danach gibt es für viele (spezielle) Aufgaben gut passende Script Sprachen und Funktionelle-Sprachen, ich denke da an Shell-scripte, Perl, lisp,..
Für große Sachen im imperative Programmierstiel ist Ada95 eine absolute Top Sprache, wird auch in der Industrie sehr oft eingesetzt.
Für große Projekte im OOP Stiel gibt es neben smalltalk (der OOP-Sprache überhaupt) Sachen wie Java und in Zukunft .Net/Mono die einem viel unnötige Arbeit abnehmen und für relativ sichere Programme sorgen.
Ich glaube das damit fast alle Bereiche abgedeckt sind und C++ in Zukunft eher eine kleinere als größere Rolle spielen wird.
So, dass waren alles rein persönliche Meinungen/Erfahrungen. Ich weiß das ich jetzt einiges von den C++ Leuten zu hören bekomme. :D
Ich glaube das damit fast alle Bereiche abgedeckt sind und C++ in Zukunft eher eine kleinere als größere Rolle spielen wird.
C und C++ wird man in den nächsten 10-20 Jahren nicht so leicht Tod kriegen. Sogar heute sind viele Bürosoftware zu 30% (!) in COBOL geschrieben! Ein Prof an der FH sagte, dass man zu seiner Zeit sagte, dass COBOL tot sei und siehe die 30% heute.
Außerdem ist und bleibt Java langsam! Ich habe mich auch lange gegen das Argument gewehrt, dass die heutigen Java-Versionen immernoch langsam seien. Aber es IST so! Je tiefer ich in die Java-Programmierung ging, desto mehr merkte ich das. OK, eigentlich ist SWING das langsam ist, weil es die Komponenten eigenständig zeichnet und nicht die OS-Bibliotheken benutzt, aber man kommt nicht drum rum Swing zu benutzen (AWT ist veraltet), außer man benutzt SWT, aber dann steigt die Größe des Programms enorm, weil man dann Bibliotheken in seine Software mitgeben muss. Und nicht zu vergessen, dass Java enorm speicherhungrig ist.
Nee, ich werd mich nach dem Schulabschluß - also noch dieses Jahr - intensiver mit C und anschließend mit C++ beschäftigen.
Mono soll übrigens auch ziemlich langsam sein (keine eigene Erfahrungen. Nur Benchmarkergebnisse gesehen.).
LG
C und C++ wird man in den nächsten 10-20 Jahren nicht so leicht Tod kriegen. Sogar heute sind viele Bürosoftware zu 30% (!) in COBOL geschrieben! Ein Prof an der FH sagte, dass man zu seiner Zeit sagte, dass COBOL tot sei und siehe die 30% heute.
Naja, erstens habe ich nicht gesagt, dass C++ aussterben wird sondern das es an wichtigkeit verlieren wird.
Zweitens ist aussterben nicht gleich aussterben, will heißen, natürlich gibt es noch COBOL "Leichen" aber wohl kaum jemand wird COBOL ernsthaft in die Auswahl nehmen wenn es um neue Programme geht.
Außerdem ist und bleibt Java langsam! Ich habe mich auch lange gegen das Argument gewehrt, dass die heutigen Java-Versionen immernoch langsam seien. Aber es IST so! Je tiefer ich in die Java-Programmierung ging, desto mehr merkte ich das. OK, eigentlich ist SWING das langsam ist, weil es die Komponenten eigenständig zeichnet und nicht die OS-Bibliotheken benutzt, aber man kommt nicht drum rum Swing zu benutzen (AWT ist veraltet), außer man benutzt SWT, aber dann steigt die Größe des Programms enorm, weil man dann Bibliotheken in seine Software mitgeben muss. Und nicht zu vergessen, dass Java enorm speicherhungrig ist.
naja, java != swing. Wenn ich mit java eine GUI machen würde, dann sowieso nur mit den Gtk Bindings. :D
Mono soll übrigens auch ziemlich langsam sein (keine eigene Erfahrungen. Nur Benchmarkergebnisse gesehen.).
In diesem Test[1] ist Mono nach C die Sprache die den wenigsten Speicherplatz unter gnome braucht!
Ausserdem wird da immer viel zu viel in einen Topf geworfen. Ich habe ja durchaus in 4 Bereiche unterschieden, die aber imho zu 99% ohne C++ alles abdecken.
Sprechen wir z.B. über die klassische GUI Anwendung, die sind 99% ihrer Zeit eh mit warten beschäftigt, da spielen bei heutiger Hardware die reinen Performance-Werte eine immer kleinere Rolle, da ist die Entwicklung und der spätere Support ein viel größerer Faktor.
ich bin mir z.B. ziemlich sicher, dass unter MS in Zukunft immer mehr Programme auf .Net setzen werden und auch unter GNU/Linux (besonders in gnome) wird Mono seinen Weg machen.
Und für andere Bereiche habe ich ja noch andere Sprachen im Angebot ;)
[1] http://primates.ximian.com/~miguel/archive/2005/Feb-09.html
WEIL
Sorry nich boese gemeint :D :D :D
Außerdem ist und bleibt Java langsam! Ich habe mich auch lange gegen das Argument gewehrt, dass die heutigen Java-Versionen immernoch langsam seien. Aber es IST so! Je tiefer ich in die Java-Programmierung ging, desto mehr merkte ich das. OK, eigentlich ist SWING das langsam ist, weil es die Komponenten eigenständig zeichnet und nicht die OS-Bibliotheken benutzt, aber man kommt nicht drum rum Swing zu benutzen (AWT ist veraltet), außer man benutzt SWT, aber dann steigt die Größe des Programms enorm, weil man dann Bibliotheken in seine Software mitgeben muss. Und nicht zu vergessen, dass Java enorm speicherhungrig ist.
Nee, ich werd mich nach dem Schulabschluß - also noch dieses Jahr - intensiver mit C und anschließend mit C++ beschäftigen.
So ein Quark. Das Swing langsam ist kann ich nicht leugnen, aber in non-Graphischen Bereichen (und dort findet Java im Enterprise-Umfeld sein Einsatzgebiet, Stichwort EJB) ist Java ziemlich nah an C++ dran, mit der Server-VM teilweise sogar knapp performanter.
Ich kann mich nur wiederholen, Java hat seinen Platz in Enterprise Applications.
Greetz
McHurt
Außerdem ist und bleibt Java langsam!
Wie du geschrieben hast, ist SWING mehr oder weniger langsam. Je nachdem was für Operationen man testet, kann Java dank hochoptimierten JIT-Compiliern leicht besser abschneiden, als ein C++ Programm. Allerdings muss man sagen, dass solche Tests immer relativ schiwerig sind.
Beachte auch, dass SWING nicht die einzige GUI-lib ist. Es gibt immernoch GTK oder WxWidgets Bindings, welche sehr leicht und schnell sind.
Mono soll übrigens auch ziemlich langsam sein (keine eigene Erfahrungen. Nur Benchmarkergebnisse gesehen.).
Mono befindet sich zur Zeit in einer Phase, in der die Entwicklung sehr rasch voranschreitet. Die Geschwindigkeit und der Resourcenverbrauchen werden ständig weiter verbessert. Zudem muss man auch sagen, dass einige Stellen der API noch nicht optimiert wurden, sondern erst auf Funktionalität programmiert wurde.
Schau dir aber zB Beagle an. An diesem Beispiel sieht man, dass eine Applikation, deren Hauptmerkmal sich auf Geschwindigkeit stützt, vollständig in Mono programmiert werden kann. Auch die verwendete Suchengine Lucene wurde von Java auf .NET portiert.
Technologien/Sprachen wie Java oder Mono werden sowohl im Client, wie auch im Serverbereich aufgrund des Bytecodes und der wegfallenden Zeigerproblematik zunehmend an Bedeutung gewinnen. Unter anderem sicher auch auf Kosten von C++.
Eigentlich wolle ich gestern schon antworten, dann kamen mir aber die Netzwerker in die Quere, und das Netz ging erst heute wieder...
Cybercrow
- C ist die perfekte "High-Level-Assambler-Sprache" und damit perfekt für Basis Sachen wie Kernel, Libs usw.
- C++, um meinem Prof zu zitieren, ist eine Sprache bei der man so lange an C irgendwelche "Beine", "Ohren" und andere Teile angebaut hat bis es einigermaßen das machte was man wollte. Dadurch ist ein Monster entstanden, dass sehr mächtig aber auch sehr "gefährlich" ist.
Tja, ich glaube nach dem bisher gezeigten, wird mir klar, dass C mit seiner Standartisierung um '90 rum ein fuer seine Zwecke perfektes Ding ist. "High-Level-Assembler" - genau den selben Eindruck hab ich auch immer, wenn ich C Code lese, als Anfaenger. Es ist fuer mich teilweise unglaublich was alles moeglich ist mit der Sprache, irre. Aber...
Entwicklung der Sprache: Andrerseits denke ich mir halt auch, dass das was C++ koennen will und die Einfachheit die es bieten will, das ganze noch um einiges komplexer macht. Dass afaik eine erste Standartisierung '96 einfach nur Exception handling und eine vage Vorstellung der STL (die sich teilweise, nach der weitern Ausbesserung der Standartisierung '03, jedoch schon weniger; immer noch stark von Compileranbieter zu Compileranbieter unterscheidet) gab ist ein imo Riesenschritt in diese Richtung. Daher denke ich auch, dass ein Wirbeltier mehr Zeit braucht zum entwickeln als Einzeller (uebertrieben gesagt ;) ) aber ein Wirbeltier eben auch um einiges mehr kann - vielleicht ein strager vergleich. Desweiteren wird auf eine umfangreiche Nachbesserung, die vielleicht mit der ersten von C vergleichbar sein wird, in dieser Dekade erst erwartet. Wenn C++ damit die gleiche "wysiwyg" Eigenschaft haben sollte wie C, halte ich es durchaus fuer eine Art eierlegende Wollmilchsau, die dann auch perfekt funktionieren wuerde.
Lange Entwicklung : ich denke das C++ von den OOP Sprachen somit durchaus auch schon eine recht lange Entwicklung mitgemacht hat, die andere Sprachen entweder von C++ abkupfern oder eben auch erst machen muessen. In dieser Hinsicht, denke ich kann C++ wohl nur noch mit Smalltalk konkurieren - wobei ich dazu ueberhaupt gar nichts sagen kann.
Reality:
dass COBOL tot sei und siehe die 30% heute.
Statistiken ueber Anwendungsbereiche von Sprachen : Nunja es wird imo immer versch. Sprachen geben, je nach Groesse des Einsatzbereichs, Schwierigkeit (viele lernen Java, nur wenige bauen einen Linuxkernel in C). Das denke ich, ist aehnlich zu realen Sprachen, ca 4 Mio Finnen werden auch nicht aufhoeren ihre Sprache zu sprechen und chinesisch lernen, blos weil es davon 1 Mrd Sprecher gibt. Aus diesen Gruenden denke ich hinkt sowas immer etwas. Die Geschichte von den COBOL Leichen, die es immer noch gibt kenne ich auch, aber warum den Code aendern, der funktioniert und das vielleicht sogar effektiv tut. Das scheint auch eben ein Grund zu sein, warum man weiterhin den Kernel in C schreibt, jedoch denke ich mittlerweile jetzt auch, dass es in diesem Fall noch zusaetzliche Argumente fuer C gibt.
Im uebrigen, wuerde ich nicht alles glauben, was "Professoren an der FH" sagen, hab da so meine ganz eigenen Erfahrungen gemacht, aber das waere ein ganz eigenes Thema...
Reality:
Außerdem ist und bleibt Java langsam! Ich habe mich auch lange gegen das Argument gewehrt, dass die heutigen Java-Versionen immernoch langsam seien. Aber es IST so!
Das ist lustig - ich glaub ich kenn Dich ausm Java Forum, LOL. Afaik ist SUN der weltgroesste Server Hersteller und da JAVA von SUN entwickelt wurde, soll es wohl auch v.a. als "Serversprache" entwickelt worden sein. So wurde mir das zumindest mal erklaert. Allerdings lernt man afaik heute an den Hochschulen v.a. ueberall JAVA, wir hatten das zumindest so und C++ nur marginal. Ich denke das auch ein ganz grosser Teil daran, welche Sprache sich wo durchsetzt wirtschaftlich begruendet sein mag. Ob das SUN mit seinen Servern ist, oder das was MS mit seinen .NET Sachen macht. Das Prinzip was hinter MS steckt ist ja nicht perfekte Produkte auf den Markt zu schmeissen, sondern (wie Bill Gates das vor ein paar Wochen in Muenchen gesagt haben soll, sinngemaess), Produkte schnell und billig anzubieten. Imo ist das auch der Fall bei den Sprachen, man versucht alles und der "Anwender" ist Betatester (J++, C#, Mono ?!), der Unterschied zu allgemein entwickelten Sprachen wie C++ (OK, zB die STL soll ja von HP grossteils uebernommen sein usw) ist dass bei MS ein Marktmonopol dahinterstecken und sehr viel Geld. Somit muss sich wohl bei den meisten (Thema : Statistik) Heimcomputern, wohl nicht das qualitativ hoehere durchsetzen, wenn jeder Windows schon beim Kauf seines PCs dazu bekommt.
Leider hab ich den Artikel nicht mehr gefunden, aber vor ca vier Monaten, las ich einen Artikel, in dem stand, dass JAVA Entwickler den hoechsten Stundensatz haben - was immer man halten mag von unbekannten Artikeln, die sich nicht mehr auffinden lassen, ich persoenlich halte das Arbeiten mit JAVA v.a. fuer eine zusammenklickerei von Buechereifunktionen (kanns aber auch ueberhaupt nicht :) - is wohl auch Geschmackssache) v.a. wenn man mit SWING arbeitet, und dort mit nur wenig direktem Einfluss auf Performance, i Ggs zu C++ und C sowieso.
MuffiXXL:
WEIL
LOL - Push up posting ?! ;)
McHurt:
Ich kann mich nur wiederholen, Java hat seinen Platz in Enterprise Applications.
Dito, jede Sprache hat wohl seine Anwendungen und wo es auch sinnvoll ist. Das sagt aber nichts darueber aus, warum nicht C++ auch fuer Kernelteile, evtl neuere Bestandteile. (ja ich weiss schon bezog sich auf was anderes... :) )
dark_red:
Technologien/Sprachen wie Java oder Mono werden sowohl im Client, wie auch im Serverbereich aufgrund des Bytecodes und der wegfallenden Zeigerproblematik zunehmend an Bedeutung gewinnen.
Tja, schau ma mal ob sich MS dann mit eigener Sprache irgendwann auch noch den Servermarkt krallt. Ich halte die Zeigerproblematik aber auch bei Hardwarenahen Dingen fuer durchaus sinnvoll, man sieht was man macht und kann direkten Einfluss drauf nehmen. Die Probleme, die daraus entstehen koennen sind zwar gerade am Anfang wie die Pest am Ar... aber ich denke, wenn man mal versucht hat modularisisert oder OOP Konzepte in C zu implementieren, regen einen Zeiger nicht mehr auf. Zeiger koennen nerven, sind aber auch ein "Instrument der Macht", imo.
Eigene Frage:
Wie sieht es denn aus mit spaeter entwickelten Dingen, als dem Basiskernel, wie zB QT, wenn ich in C++ auf Linux entwickle kann ich die QT Libraries benutzen, KDE soll afair auf dieser sogar aufbauen, ist dann C++ bei den Anwendungen von Linux gebraeuchlicher ?
Ist es vielleicht bei der Anwendungs Entwicklung sinnvoller oder gerade richtig eingesetzt ? Was denkt Ihr ?
Ich halte die Zeigerproblematik aber auch bei Hardwarenahen Dingen fuer durchaus sinnvoll, man sieht was man macht und kann direkten Einfluss drauf nehmen. Die Probleme, die daraus entstehen koennen sind zwar gerade am Anfang wie die Pest am Ar... aber ich denke, wenn man mal versucht hat modularisisert oder OOP Konzepte in C zu implementieren, regen einen Zeiger nicht mehr auf. Zeiger koennen nerven, sind aber auch ein "Instrument der Macht", imo.
Jein. Auch hier ist es wieder eine Frage des Anwendungsgebiets. Ich persönlich vertrete die Meinung, dass in der Zukunft Desktop-Applikationen vermehrt in Sprachen mit grosser Abstraktion geschrieben werden. Grosse Abstraktion bietet in meinen Augen in dem Sinn Vorteile, dass viele Fehlerquellen und Fallgruben umgangen werden können und man sich auf die Logik der Applikation konzentrieren kann ohne sich um Low-Level Angelegenheiten kümmern zu müssen. Dies spart Entwicklungszeit und unter Umständen kann es zu qualitativ besserem Code führen (dies ist aber zum grossen Teil vom Entwickler abhängig).
Abstraktion ist jedoch immer mit Kontrollverlust verbunden. Wie gesagt, jede Sprache hat ihr Einsatzgebiet, IMO ist die Sprache ideal, welche für die Anforderungen die nötige Kontrolle bei höchster Abstraktion bietet.
Eigene Frage:
Wie sieht es denn aus mit spaeter entwickelten Dingen, als dem Basiskernel, wie zB QT, wenn ich in C++ auf Linux entwickle kann ich die QT Libraries benutzen, KDE soll afair auf dieser sogar aufbauen, ist dann C++ bei den Anwendungen von Linux gebraeuchlicher ?
Ist es vielleicht bei der Anwendungs Entwicklung sinnvoller oder gerade richtig eingesetzt ? Was denkt Ihr ?
Stimmt, KDE baut auf QT auf. Eine klare Antwort kann ich dir auf diese Frage nicht geben, ich denke es hängt sehr von der eingesetzten Library ab.
Wenn ich mich z.B. dazu entschliesse mit QT zu entwickeln, liegt es nahe, dass ich als Sprache C++ wähle, obwohl auch für diverse andere Sprachen Bindings bestehen (ist aber kein Muss). Gnome hingegen ist in C geschrieben.
Auf deine zweite Frage möchte ich auf den obigen Teil verweisen.
Greetz
McHurt
Eigene Frage:
Wie sieht es denn aus mit spaeter entwickelten Dingen, als dem Basiskernel, wie zB QT, wenn ich in C++ auf Linux entwickle kann ich die QT Libraries benutzen, KDE soll afair auf dieser sogar aufbauen, ist dann C++ bei den Anwendungen von Linux gebraeuchlicher ?
Ist es vielleicht bei der Anwendungs Entwicklung sinnvoller oder gerade richtig eingesetzt ? Was denkt Ihr ?
Naja, wie gesagt wurde. Es gibt ja nicht nur Qt, bei Qt hast du recht.
Bei Gtk+ sieht es anders aus, und ich halte es technisch auch für sinnvoller (bitte nicht einen Qt-Gtk flame starten!)
Um mich mal selber zu zitieren:
- C++, um meinem Prof zu zitieren, ist eine Sprache bei der man so lange an C irgendwelche "Beine", "Ohren" und andere Teile angebaut hat bis es einigermaßen das machte was man wollte.
Dieses Spiel spielt Qt im Prinzip weiter. Keine Frage, dadurch ist ein schönes Framework entstanden um GUIs zu programmieren, aber eben auch irgendwie ein riesen Mutant.
Gtk+ bietet dagegen GU-libs in C, eine schöne und kleine Sprache für "low-level" Sachen, wie ich weiter oben geschrieben habe, wozu imho auch libs gehören.
Aber für Anwendungen würde ich persönlich nicht C verwenden, dazu gibt es dann beliebige Sprachbindings, jeder kann nehmen was einem gefällt.
Vorteil (meiner Meinung nach), du kannst immer die Technik nutzen die dir gefällt, Gtk passt sich perfekt in C++, Python, Scheme, C#,... ein.
Sprich, du schreibst eine GUI mit der Sprach deiner Wahl und die GUI-libs sind in der besten Sprache für libs geschrieben -> C, dadurch ist es möglich einfach diese viele bindings anzubieten, max. Performance zu erreichen, gute Portabilität (da C durch den kleine Sprachumfang wohl am einfachsten auf verschiedenen Plattformen kompiliert)
Naja, lange Rede kurzer Sinn. Um so weiter du von der "Basis" weg kommst um so sinnvoller sind imho Hochsprachen, die Grenze ist natürlich fließend. Ich würde sagen für libs, kernel usw. ist C die beste Wahl.
Oder um eine RedHat Mitarbeiter zu zitieren:
And of course, the number 1 tip for GTK+ programming is:
- Don't use C; In my opinion, C is a library programming language not an app programming language
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.