>Recht anspruchsvoll wird es dann mit der Vorstellung der LCGI (Linux C Graphics Interface), einer eigens im Rahmen dieses Buches entwickelten Bibliothek für grafische Arbeiten.
Solche Sätze erschrecken mich immer etwas. Es gibt doch genug Möglichkeiten mit C grafische Sachen zu erstellen, in der Konsole ncurses und unter X GTK+. Warum wird da in dem Buch etwas eigenes verwendet, was man in der Praxis kaum gebrauchen kann? Schließlich wird man sich letztlich auf bewährte Sachen verlassen die jedes GNU oder BSD System hat und nicht irgendwelche exotischen libs aus irgendeinem Buch nehmen.
Ich kenne die erste Ausgabe, es sind ja wirklich interessante Sachen dabei, mit den Fraktale, Funktionsplotter,.. die man in "normalen" C Büchern nicht findet. Aber irgendwie war ich nie wirklich motiviert mir das genauer anzusehen, da es eben mit diesen komischen extra libs gemacht wird. Ich denke es wäre von viel größerem Nutzen, wenn man es wirklich "GNU/Linux-like" machen würde (mit ncurses in der konsole oder gtk+ unter X).
Von Alter Mann mit Bart im Schauke am Mo, 23. August 2004 um 06:09 #
ACK,
fast das gleiche wie mit dem Buch "3D Programmierung unter Linux (Band 1)", da gibt's auch eine l3d-Bibliothek. Die ist zwar letztlich ein C++ Wrapper für libX Calls, aber beim Lesen verwirrt's doch schon. Und wenn man bei dieser Thematik gerade erst einsteigt, wird man eigentlich auf den falschen Weg gebracht.
Auf das Buch bin ich auch reingefallen. Wirklich viel 3D macht der Author ja nicht gerade. Bevor es ans OpenGL geht, muss erst mal ein komischer Softwarerenderer geschrieben werden und überhaupt übertreibt es sein l3d sehr mit Designpatterns.
Kommt drauf an, wie man 'grafisch' definiert. Der Monitor zeigt immer nur Punkte an, also sind auch ASCII-Zeichen grafische Symbole (definitiv!). Der Bildschirm ist immer ein GUI, im Gegensatz zur Soundkarte z.B.
Eine Soundkarte ist nie ein GUI, aber definitiv ein User Interface. Es gibt Software, die z.B. Blinden das, was sonst auf dem Bildschirm dargestellt wird vorliest und Spracherkennung gibt es auch. Also UIs ohne Bild sind kein Problem. Ich hoffe, Dir ein bisschen das Weltbild erweeitert zu haben.
...sollte vermieden werden! Was soll denn heute noch der 70er Jahre code? Die insecurity-news sind voll mit Meldungen über C libraries/programmen mit teils immer denselben Fehlern. Der GCC kann seit längerem schon sehr gut C++ und Obj-C kompilieren. C ist einfach nur noch eine Unix-Krankheit! Es gibt heutzutagen KEINE Entschuldigung mehr in C rumzuwürgen.
>Es gibt heutzutagen KEINE Entschuldigung mehr in C rumzuwürgen.
wen interessierts was du von c hältst? die meisten unter linux verwenden c. nur weil du damit nicht zurechtkommst heißt das lange noch nicht das andere sich drum scheren müssen. und obj-c ist eh müll. wenn schon dann c++ sonst halt c. aber ich glaube du trollst nur rum weil du gar nicht programmieren kannst, sonst würdest du anderen nicht vorschreiben wollen was sie für ne programmiersprache nutzen sollen. der müll den du da redest ist ein zeichen dafür das du keine ahnung hast!
Wenn man sagen wir mal C++ anstelle von C für ein programm nimmt (und auch wirklich C++ schreibt!) ist die Wahrscheinlichkeit das schwere Fehler drin sind praktisch null. Allein so simple Sachen wie std::string oder container klassen merzen schon vieles aus. Dazu kommt das Fehlerbehandlung mit Exceptions einfach um klassen besser ist als in historischem C.
Es geht nicht darum ob man mit C zurechtkommt oder nicht. Es geht darum das jeder Fehler macht und eine minimalistische Sprache wie C zwar leicht zu erlernen, aber schwer zu beherrschen ist.
Wir alle müssen darunter leiden wenn mal wieder ein Sicherheits-Bug in einem C programm gefunden wurde und reihenweise die server geknackt werden.
ich glaube du trollst nur rum Beißt sich irgendwie mit: obj-c ist eh müll. wenn schon dann c++ sonst halt c. Und das beißt sich wiederum mit: sonst würdest du anderen nicht vorschreiben wollen was sie für ne programmiersprache nutzen sollen Du schreibst es ja genau nicht anders vor und bringst nichtmal ein Argument dafür, weshalb Obj-C Müll sei. nur weil du damit nicht zurechtkommst Wer war doch gleich der Troll? Es geht ihm gar nicht um sich. Schau dir nur mal die promimenten Bugs der vergangenen Monate an.
Läsest du die Bugs, wie ich sagte, bemerktest du, dass diese "typisch" für Programmiersprachen auf dem Level von C sind und in anderen eher schwerer zu fabrizieren sind (s.u.) - und das war, was abc ausdrückte. (wenn ich ihn richtig interpretiere). Zudem geht es (mir) nicht um C++.
Als Experte würd ich mich dennoch nicht bezeichnen, ich bezeichne mich selten als irgendwas.
Und ja, natürlich verursachen die Programmierer die Fehler. Aber offenbar tun das eine ganze Menge, weshalb "nur, weil du damit nicht klarkommst" nicht angebracht ist. Bei C gibt es nunmal viel, worauf man achten muss. Kleine Unachtsamkeiten können schon zu Buffer-Overflows, Speicherlecks und Segfaults führen. Das schafft man in anderen Sprachen nunmal nicht so leicht bis gar nicht. Natürlich oft auf Kosten der Flexibilität, aber es geht mir nicht drum, Leuten von C abzuraten.
du hast einfach nicht verstanden das es keine perfekte sprache gibt, das ist auch an abc gerichtet. eine (mehr oder weniger) vor bugs sicherer sprache gibt es nicht. bugs umfassen nicht nur speicherlecks sondern allgemein einen programmverlauf der nicht beabsichtig ist. und da es keine garantie dafür gibt, dass der programmierer das was er vorhat auch umsetzen kann, hast du dasselbe problem mit allen programmiersprachen. vielleicht kann mann mit c++/stl oder java/python/perl/c#/php etc. speicherlecks besser vermeiden aber das ist auch schon alles. man erkauft sich diesen vorteil damit das mann weniger kontrolle über das hat, was das programm hat und mann hat hohe einbußen an performance. es gibt wohl anwendungen wo das hinnehmbar ist, aber in vielen bereichen geht vor allem um performance und möglichst vollkomene kontrolle über den code. und das gilt nicht nur für den kernel code. der sinn der open-source community ist unter anderem auch das bugs durch testen gefunden und von jedem der sich im stande fühlt auch gefixt werden kann.
> du hast einfach nicht verstanden das es keine perfekte sprache gibt, Natürlich habe ich das verstanden, das kann schon aufgrund verschiedener Geschmäcker und Aufgabenbereiche gar nicht sein.
> umfassen nicht nur speicherlecks sondern allgemein einen programmverlauf der nicht beabsichtig ist. Das weiß ich ebenfalls, es ging mir aber konkret um _diese_ "typischen" Bugs. Dass andere Sprachen andere Anfälligkeiten haben, ist mir bewusst, aber es geht mir hier nicht um ein Pro und Contra verschiedener Sprachen oder darum, C schlecht zu machen. Dass C verglichen mit höheren Sprachen anfällig für Buffer-Overflows, Segfaults und Speicherlecks ist, kann man einfach nicht von der Hand weisen oder auf die "Unfähigkeit" der Leute schieben.
>kann man einfach nicht von der Hand weisen oder auf die "Unfähigkeit" der Leute schieben.
doch natürlich. speicherverwaltung ist sehr wichtig und bevor man anfängt in c zu programmieren sollte mann das auf jedenfall drauf haben. natürlich passieren solche fehler auch aus flüchtigkeit, aber jeder sollte wissen, wann ein dyn. array zur richtigen zeit zu löschen ist. wenns dann irgendwann später auftritt dann muss man es halt fixen und gut is.
Da stimme ich dir jetzt vollkommen zu. Aber Flüchtigkeitsfehler passieren auch den fähigsten Leuten, und ganz besonders denen ... Routine ist gefährlich.
Die perfekte Sprache gibt es nicht, aber bessere und schlechtere. Immerhin kann man in C++ sicherheitskritischen Fehlern vorbeugen. Wenn der Server gecrackt ist heisst es eben nicht: "Ah, ok wir gucken mal und gut ist's.". Sowas darf einfach nicht passieren. Im übrigen ist der performance unterschied zwischen C und C++ praktisch null und ich hab bestimmt nicht weniger "Kontrolle" in C++...
C ist nun mal aus den 70ern und hat sich seitdem nicht weiterentwickelt.
vielleicht kann mann mit c++/stl oder java/python/perl/c#/php etc. speicherlecks besser vermeiden aber das ist auch schon alles.
Ausser C++ haben meines Wissens alle von Dir genannten Sprachen eine GC, sodass dem Programmierer Speicherlecks gar nicht "passieren" koennen. Und ausserdem ist das nicht schon alles. Die BOs werden ja schliesslich auch vermieden.
Lass die Leute doch nehmen was sie wollen? Gibts sicherlich sogar Leute die können in Assembler bessere Programme schreiben, als manche mit C++ Letztlich hängt es immer beim Programmierer und Fehler kann man mit jeder Sprache machen.
Die Programmiersprache war noch nie ein Garant dafür das die Software gut wird. Ich erinnere daran das Windows (lt. eigenen Aussagen von MS) zu einem beachtlichen Teil in C++ geschrieben ist...
Unter Windows gibt es MFC, was eigentlich nur ein wrapper für den C Unterbau ist. Wirklich C++ ist das nicht.
C++ ist durchaus ein garant dafür das z.b. buffer overflows nicht passieren:
wenn ich mit std::vector::at(size_t n) "daneben schiesse" gibts ne exception. wenn ich ein klassisches C array nehme und darüber hinausschiesse entsteht ein kritisches Sicherheitsproblem.
Das ist schon richtig. Man muss das alles aber auch relativieren und nicht so tun, als ob mit einer einzelnen Sprache plötzlich alles wunderbar und fehlerfrei ist ;) C++ bietet einige interessante Dinge wie z.B. Templates. Aber wer nutzt in jedem C++ Programm z.B. konsequent "std::string" statt eines selbstgebastelten arrays
Die MFC ist zudem nur ein Teil von Windows (wie du schon sagtest ein Wrapper z.B. auf die Win32-API). Das gesamte Shellmodell von Windows ist z.B. C++ (genaugenommen COM)
Auch zu c++ wird es mal einen nachfolger geben, bzw an C++ wird ja aktiv weiterentwickelt. Ich bin durchaus neuem aufgeschlossen. Zum anderen kann ich, wenn ich eine library in einem projekt benutzen will den code überfliegen und wenn ich da z.B. vector::at() sehe weiss ich das es schonmal kein Sicherheitsproblem geben kann.
Ich benutze auf alle Fälle immer string/container klassen, exceptions und boxed types; muss ja nicht STL sein wenn man das nicht mag.
Ich kenne mich nicht 100% in der windows welt aus, aber was ich von msdn kenne ist immer irgendein C/C++ Mischgebräu. Ein Paradebeispiel für C++ ist das jedenfalls nicht.
es gibt gründe warum manche leute die stl aus c++ vermeiden. und zwar weil diese absolut langsam ist. wenn es jemandem um performance geht oder nur um ein einfachen string ist stl vollkommen überflüssig - und zwar im warsten sinen des wortes -. welche programmiersprache man nimmt hängt einzig und allein davon ab welche anforderungen an das programm gestellt werden. informier dich erstmal oder lerne programmieren bevor du solche sätze schmeißt.
Und die Hauptanforderung an alle Programme ist das sie kein Sicherheitsrisiko sind. Genau das aber sind C programme in der Regel.
Übrigens ich weiss nicht wo du nachplapperst das die STL langsam ist, aber das stimmt so nicht. Die STL Container haben keine virtuellen Funktionen, sind templates und inlinen sehr gut. Es wäre gar nicht so einfach möglich mit C etwas ähnlich schnelles und sicheres zu schreiben.
da sieht man dass du c gar nicht kennst. man kann stl in c gar nicht nachmachen weil c nunmal nicht objektorientiert ist, genau darauf baut aber stl auf.
Von El Pseudonymo am Mo, 23. August 2004 um 21:04 #
Die STL als Objektorientiert zu bezeichnen ist etwas weit hergeholt. Einer der Kernpunkte von Objektorientierung ist ja, das man eine bestimmte Datenstruktur und die Operationen welche auf dieser Struktur arbeiten können zu einem Typ zusammenfasst. Aber das macht die STL (eher) nicht. Sie stellt unter Anderem Algorithmen bereit die mit sehr vielen verschieden Typen arbeiten können.
Kennzeichen von Objektorientierung sind auch z.B. (tiefe) Vererbungshirarchien und Schnittstellenklassen. Die findet man in der STL auch nicht.
Deine Erklärung von OO ist zwar etwas unorthodox aber Okay, irgendwie beschreibt sie ja Kapselung und Polyphormismus ;)
Die STL kapselt selbstverständlich Daten ("Information Hiding"), bietet zugriffsgeschützte Methoden zur Manipulation der Daten und nutzt Vererbung. Was soll daran nicht objektorientiert sein?
Von El Pseudonymo am Di, 24. August 2004 um 15:56 #
Deine Erklärung von OO ist zwar etwas unorthodox aber Okay, irgendwie beschreibt sie ja Kapselung und Polyphormismus
Meistens lese ich das Objektorientierung sei, wenn man Nachrichten an Objekte sendet und diese dann darauf reagieren. Damit kann ich persönlich aber nicht viel anfangen. Z.b "ventil3.schliessen();" in C++, da kann ich keinen Nachrichtenversand drin erkennen. Für mich ist das ein Funktionsaufruf. Deshalb hatte ich das Obere als eine Eigenschaft von Objektorientierung genannt. Die ist zwar auch beiweitem nicht vollständig, aber sie hat, finde ich, Substanz.
Ich würde nun sagen, daß die STL zwar auch Kennzeichen von Objekorientierung besitzt, aber meiner Meinung nach nur in geringem Umfang (*). Z.b (das hatte ich schon genannt) fehlt eine Vererbungshirarchie (Vererbung in der STL ist eher ein Imlementierungsdetail). Und Polymorphismus, in der meistverbreiteten Form, findet man auch nicht. Und dann findet man in der STL die Algorithmen z.B. aus , welche losgelöst von deren Verwendung in bestimmten Klassen/Typen/Objekten existieren. Als Vergleich für einen Objektorientierten Ansatz der (aber nur teilweise) das gleiche wie die STL macht möchte ich die Containerklassen der Java-Bibliothek nennen.
* Es gibt ein sehr interessantes Interview mit Stepanov in dem er vehement zum Ausdruck bringt das Objektorientierung kein Faktor beim Design der STL war. Er hält von OO auch so gut wie gar nichts. Wenn du es nicht schon kennst, kannst du es hier nachlesen: http://www.stlport.org/resources/StepanovUSA.html
Ich finde es ist wirklich interessant, viel Spass!
Die Erklärung ist falsch. Die STL baut auf Templates auf und sowas gibt es bei "C" nicht. Um so etwas mit "C" zu machen bräuchte man eine Funktionalität der Typenersetzung, wie man es Ansatzweise nur mit Makros hinbekommt.
Ausserdem... "C" ist zwar eine prozedurorientierte Sprache, man kann aber trotzdem damit auch objektorientiert Entwickeln Mit grossen Abstrichen der Typensicherheit, könnte man sogar die Funktionalität der STL nachbauen. Statt der Typen, würde man mit void* Zeigern arbeiten und bräuchte eine Extra-Typenbeschreibung. Wie man sowas z.B. umsetzen kann, findet man auch in dem Buch von Schreiner "OO mit Ansi-C".
In vielen Fällen kann man heutzutage auf das letzte Quäntchen Geschwindigkeit verzichten, da die Prozessoren sowieso schnell genug sind.
Es gibt aber Bereiche, wo man versuchen muss möglichst optimalen (schnellen) Code zu schreiben und dort sind komplexe Datenstrukturen teilweise extrem hinderlich.
Das Bedeutet nicht, dass man kein C++ nutzen kann, aber es gibt Fälle, wo man lieber auf OOP verzichtet (innerhalb von C++ ja kein Problem) oder in extremfällen sogar auf ASM zurückgreifen sollte.
Die STL muss nicht zwangsläufig langsamer sein, als wenn man die Datenstrukturen selbst implementiert, aber umso komplexer diese Strukutren sind, umso langsamer sind sie auch.
Das man in C++ häufig einen hybriden Code zwischen OOP und Prozeduraler Programmierung sieht liegt nicht umbedingt daran, dass die Leute es nicht besser können, sondern das es teilweise sinnvoller ist die OOP Paradigmen zu verlassen um mehr Geschwindigkeit rauszuholen.
Der Vollständigkeit halber sollte man noch erwähnen, dass C++ sowieso eine Hybridsprache ist. Wer vollständig OOP Programmieren will sollte sich eher Sprachen wie Smalltalk widmen.
> Es gibt aber Bereiche, wo man versuchen muss möglichst optimalen (schnellen) > Code zu schreiben und dort sind komplexe Datenstrukturen teilweise extrem hinderlich.
> Das Bedeutet nicht, dass man kein C++ nutzen kann, aber es gibt Fälle, wo man > lieber auf OOP verzichtet (innerhalb von C++ ja kein Problem) oder in > extremfällen sogar auf ASM zurückgreifen sollte. Um mal bei der Problemstellung STL und komplexe Datenstrukturen zu bleiben: Wenn Du laufzeitkritische Operationen auf STL-Klassen machen willst, hilft Dir partielle Spezialisierung wunderbar weiter. Definiere für Deine Datentypen speziell optimierte Bearbeitungsroutinen (von mir aus mit Inline-Assembler) und schon sieht die Welt wieder besser aus. Wenn Du dann noch konsequent darauf baust, bei der Übergabe von Objektreferenzen auch wirklich Referenzen zu verwenden, anstatt die Datenstruktur jedesmal implizit kopieren zu lassen, gibt es nur noch theoretische Vorteile der Lösung, die "kurz mal das OOP außen vor läßt".
> Die STL muss nicht zwangsläufig langsamer sein, als wenn man die Datenstrukturen > selbst implementiert, aber umso komplexer diese Strukutren sind, umso langsamer > sind sie auch. Das kann und will ich so einfach nicht abnicken. Die STL ist, was ihre Spezifikation angeht, ziemlich optimal implementiert. Datentypspezifische Optimierungen kann man (siehe oben) schnell und einfach selbst erledigen. Und dank der breiten Palette an Datenstrukturen hat man auch jede Menge Möglichkeiten, mit Standardfunktionalität _algorithmisch_ zu optimieren, ohne gleich Hashtabellen, Mappings, Vektoren oder Strings neu implementieren zu müssen. Überhaupt sollte man mE viel mehr Hirnschmalz investieren, algorithmisch zu optimieren. Implementationsoptimierung durch Inlining, Assembler o.ä. überdeckt für mich immer so ein bißchen die algorithmischen Schwächen. :)
"C "kann nix dafür wenn die Leute Arrays mit statischer Größe benutzen oder Bereichsgrenzen nicht kontrollieren. Das bekommt man mit C++ genauso hin Aus der Nummer kommt man wirklich nur raus wenn man komplett auf Zeiger verzichtet und wirklich alles nur noch ein Objekt/Klasse ist, wo zudem ein Garbage Collector im Hintergrund sich um die Speicherverwaltung kümmert...
Das die STL langsam sein soll habe ich auch nicht gehört. Aber man lernt ja nie aus
C, C++, Java und wie sie alle heissen haben alle Ihre Vor- und Nachteile
C - mag zwar alt sein, und es gibt leider auch konkurrierende Sprachstandards Beispiel c89, c99 in c99 kann ich das machen
.. for (int i = 0; i < 10; i++) ..
in c89 muss ich es wie folgt machen .. int i = 0; for ( ; i < 10 ; i++) ..
wie man daran schon sieht, es gibt "keine" Universalsprache, und jede Sprache hat Ihre Stärken und Schwächen, im Endeffekt würde ich sagen mit C - Code verhält es sich ähnlich wie mit Perl man kann "Perl" programmieren oder man kann "Pöährl" programmieren,
von hervorragend lesbar, bis ich brauche einen Ägyptologen, um das zu entziffern,
C nimmt einem Programmierer das Denken über die Speicherverwaltung und die eigenen Aktionen im Speicher eben nicht ab, genauso wenig dies C++ u. Objective-C machen, aber es gibt halt noch den Punkt der bei Menschen immer hinzu kommt, der eigene Geschmack,
ich würde z.B. eine Kombination von C (rein prozedurale Lösungen) und Java(rein objektorientierte Lösungen) vorziehen, da C++ z.B. nicht nach meinem "Geschmack" ist.
ich spielte damit eher auf den mehr oder minder beliebten "Hybridcode" an, sorry das war nicht ganz deutlich, aber Du hast in Deinem Punkt natürlich recht.
Solche Sätze erschrecken mich immer etwas.
Es gibt doch genug Möglichkeiten mit C grafische Sachen zu erstellen, in der Konsole ncurses und unter X GTK+.
Warum wird da in dem Buch etwas eigenes verwendet, was man in der Praxis kaum gebrauchen kann?
Schließlich wird man sich letztlich auf bewährte Sachen verlassen die jedes GNU oder BSD System hat und nicht irgendwelche exotischen libs aus irgendeinem Buch nehmen.
Ich kenne die erste Ausgabe, es sind ja wirklich interessante Sachen dabei, mit den Fraktale, Funktionsplotter,.. die man in "normalen" C Büchern nicht findet.
Aber irgendwie war ich nie wirklich motiviert mir das genauer anzusehen, da es eben mit diesen komischen extra libs gemacht wird. Ich denke es wäre von viel größerem Nutzen, wenn man es wirklich "GNU/Linux-like" machen würde (mit ncurses in der konsole oder gtk+ unter X).
z.B. auch svga-lib libframebuffer falls man ohne X auskommen möchte.
fast das gleiche wie mit dem Buch "3D Programmierung unter Linux (Band 1)", da gibt's auch eine l3d-Bibliothek. Die ist zwar letztlich ein C++ Wrapper für libX Calls, aber beim Lesen verwirrt's doch schon. Und wenn man bei dieser Thematik gerade erst einsteigt, wird man eigentlich auf den falschen Weg gebracht.
von graphik noch nicht einmal die ausgabe son graphischen "symbolen".
ac
Was soll denn heute noch der 70er Jahre code?
Die insecurity-news sind voll mit Meldungen über C libraries/programmen mit teils immer denselben Fehlern. Der GCC kann seit längerem schon sehr gut C++ und Obj-C kompilieren.
C ist einfach nur noch eine Unix-Krankheit! Es gibt heutzutagen KEINE Entschuldigung mehr in C rumzuwürgen.
wen interessierts was du von c hältst? die meisten unter linux verwenden c. nur weil du damit nicht zurechtkommst heißt das lange noch nicht das andere sich drum scheren müssen. und obj-c ist eh müll. wenn schon dann c++ sonst halt c. aber ich glaube du trollst nur rum weil du gar nicht programmieren kannst, sonst würdest du anderen nicht vorschreiben wollen was sie für ne programmiersprache nutzen sollen. der müll den du da redest ist ein zeichen dafür das du keine ahnung hast!
Wenn man sagen wir mal C++ anstelle von C für ein programm nimmt (und auch wirklich C++ schreibt!) ist die Wahrscheinlichkeit das schwere Fehler drin sind praktisch null. Allein so simple Sachen wie std::string oder container klassen merzen schon vieles aus. Dazu kommt das Fehlerbehandlung mit Exceptions einfach um klassen besser ist als in historischem C.
Es geht nicht darum ob man mit C zurechtkommt oder nicht. Es geht darum das jeder Fehler macht und eine minimalistische Sprache wie C zwar leicht zu erlernen, aber schwer zu beherrschen ist.
Wir alle müssen darunter leiden wenn mal wieder ein Sicherheits-Bug in einem C programm gefunden wurde und reihenweise die server geknackt werden.
Beißt sich irgendwie mit:
obj-c ist eh müll. wenn schon dann c++ sonst halt c.
Und das beißt sich wiederum mit:
sonst würdest du anderen nicht vorschreiben wollen was sie für ne programmiersprache nutzen sollen
Du schreibst es ja genau nicht anders vor und bringst nichtmal ein Argument dafür, weshalb Obj-C Müll sei.
nur weil du damit nicht zurechtkommst
Wer war doch gleich der Troll? Es geht ihm gar nicht um sich. Schau dir nur mal die promimenten Bugs der vergangenen Monate an.
bugs sind sache der programmiere. die gibt es auch unter c++. der satz qualifiziert dich auch nicht gerade als experten.
Als Experte würd ich mich dennoch nicht bezeichnen, ich bezeichne mich selten als irgendwas.
Natürlich habe ich das verstanden, das kann schon aufgrund verschiedener Geschmäcker und Aufgabenbereiche gar nicht sein.
> umfassen nicht nur speicherlecks sondern allgemein einen programmverlauf der nicht beabsichtig ist.
Das weiß ich ebenfalls, es ging mir aber konkret um _diese_ "typischen" Bugs. Dass andere Sprachen andere Anfälligkeiten haben, ist mir bewusst, aber es geht mir hier nicht um ein Pro und Contra verschiedener Sprachen oder darum, C schlecht zu machen. Dass C verglichen mit höheren Sprachen anfällig für Buffer-Overflows, Segfaults und Speicherlecks ist, kann man einfach nicht von der Hand weisen oder auf die "Unfähigkeit" der Leute schieben.
doch natürlich. speicherverwaltung ist sehr wichtig und bevor man anfängt in c zu programmieren sollte mann das auf jedenfall drauf haben. natürlich passieren solche fehler auch aus flüchtigkeit, aber jeder sollte wissen, wann ein dyn. array zur richtigen zeit zu löschen ist. wenns dann irgendwann später auftritt dann muss man es halt fixen und gut is.
Immerhin kann man in C++ sicherheitskritischen Fehlern vorbeugen. Wenn der Server gecrackt ist heisst es eben nicht: "Ah, ok wir gucken mal und gut ist's.". Sowas darf einfach nicht passieren. Im übrigen ist der performance unterschied zwischen C und C++ praktisch null und ich hab bestimmt nicht weniger "Kontrolle" in C++...
C ist nun mal aus den 70ern und hat sich seitdem nicht weiterentwickelt.
Ausser C++ haben meines Wissens alle von Dir genannten Sprachen eine GC, sodass dem Programmierer Speicherlecks gar nicht "passieren" koennen.
Und ausserdem ist das nicht schon alles. Die BOs werden ja schliesslich auch vermieden.
z.B. Quartz von MacOS X ?
Die Programmiersprache war noch nie ein Garant dafür das die Software gut wird. Ich erinnere daran das Windows (lt. eigenen Aussagen von MS) zu einem beachtlichen Teil in C++ geschrieben ist...
C++ ist durchaus ein garant dafür das z.b. buffer overflows nicht passieren:
wenn ich mit std::vector::at(size_t n) "daneben schiesse" gibts ne exception. wenn ich ein klassisches C array nehme und darüber hinausschiesse entsteht ein kritisches Sicherheitsproblem.
C++ bietet einige interessante Dinge wie z.B. Templates. Aber wer nutzt in jedem C++ Programm z.B. konsequent "std::string" statt eines selbstgebastelten arrays
Die MFC ist zudem nur ein Teil von Windows (wie du schon sagtest ein Wrapper z.B. auf die Win32-API). Das gesamte Shellmodell von Windows ist z.B. C++ (genaugenommen COM)
Ich benutze auf alle Fälle immer string/container klassen, exceptions und boxed types; muss ja nicht STL sein wenn man das nicht mag.
Ich kenne mich nicht 100% in der windows welt aus, aber was ich von msdn kenne ist immer irgendein C/C++ Mischgebräu. Ein Paradebeispiel für C++ ist das jedenfalls nicht.
mfg
Andy
Übrigens ich weiss nicht wo du nachplapperst das die STL langsam ist, aber das stimmt so nicht. Die STL Container haben keine virtuellen Funktionen, sind templates und inlinen sehr gut. Es wäre gar nicht so einfach möglich mit C etwas ähnlich schnelles und sicheres zu schreiben.
Kennzeichen von Objektorientierung sind auch z.B. (tiefe) Vererbungshirarchien und Schnittstellenklassen. Die findet man in der STL auch nicht.
Die STL kapselt selbstverständlich Daten ("Information Hiding"), bietet zugriffsgeschützte Methoden zur Manipulation der Daten und nutzt Vererbung. Was soll daran nicht objektorientiert sein?
Deine Erklärung von OO ist zwar etwas unorthodox aber Okay, irgendwie beschreibt sie ja Kapselung und Polyphormismus
Meistens lese ich das Objektorientierung sei, wenn man Nachrichten an Objekte sendet und diese dann darauf reagieren. Damit kann ich persönlich aber nicht viel anfangen.
Z.b "ventil3.schliessen();" in C++, da kann ich keinen Nachrichtenversand drin erkennen. Für mich ist das ein Funktionsaufruf. Deshalb hatte ich das Obere als eine Eigenschaft von Objektorientierung genannt. Die ist zwar auch beiweitem nicht vollständig, aber sie hat, finde ich, Substanz.
Ich würde nun sagen, daß die STL zwar auch Kennzeichen von Objekorientierung besitzt, aber meiner Meinung nach nur in geringem Umfang (*). Z.b (das hatte ich schon genannt) fehlt eine Vererbungshirarchie (Vererbung in der STL ist eher ein Imlementierungsdetail). Und Polymorphismus, in der meistverbreiteten Form, findet man auch nicht. Und dann findet man in der STL die Algorithmen z.B. aus , welche losgelöst von deren Verwendung in bestimmten Klassen/Typen/Objekten existieren. Als Vergleich für einen Objektorientierten Ansatz der (aber nur teilweise) das gleiche wie die STL macht möchte ich die Containerklassen der Java-Bibliothek nennen.
* Es gibt ein sehr interessantes Interview mit Stepanov in dem er vehement zum Ausdruck bringt das Objektorientierung kein Faktor beim Design der STL war. Er hält von OO auch so gut wie gar nichts. Wenn du es nicht schon kennst, kannst du es hier nachlesen:
http://www.stlport.org/resources/StepanovUSA.html
Ich finde es ist wirklich interessant, viel Spass!
Die STL baut auf Templates auf und sowas gibt es bei "C" nicht. Um so etwas mit "C" zu machen bräuchte man eine Funktionalität der Typenersetzung, wie man es Ansatzweise nur mit Makros hinbekommt.
Ausserdem... "C" ist zwar eine prozedurorientierte Sprache, man kann aber trotzdem damit auch objektorientiert Entwickeln
Mit grossen Abstrichen der Typensicherheit, könnte man sogar die Funktionalität der STL nachbauen. Statt der Typen, würde man mit void* Zeigern arbeiten und bräuchte eine Extra-Typenbeschreibung. Wie man sowas z.B. umsetzen kann, findet man auch in dem Buch von Schreiner "OO mit Ansi-C".
In vielen Fällen kann man heutzutage auf das letzte Quäntchen Geschwindigkeit verzichten, da die Prozessoren sowieso schnell genug sind.
Es gibt aber Bereiche, wo man versuchen muss möglichst optimalen (schnellen) Code zu schreiben und dort sind komplexe Datenstrukturen teilweise extrem hinderlich.
Das Bedeutet nicht, dass man kein C++ nutzen kann, aber es gibt Fälle, wo man lieber auf OOP verzichtet (innerhalb von C++ ja kein Problem) oder in extremfällen sogar auf ASM zurückgreifen sollte.
Die STL muss nicht zwangsläufig langsamer sein, als wenn man die Datenstrukturen selbst implementiert, aber umso komplexer diese Strukutren sind, umso langsamer sind sie auch.
Das man in C++ häufig einen hybriden Code zwischen OOP und Prozeduraler Programmierung sieht liegt nicht umbedingt daran, dass die Leute es nicht besser können, sondern das es teilweise sinnvoller ist die OOP Paradigmen zu verlassen um mehr Geschwindigkeit rauszuholen.
Der Vollständigkeit halber sollte man noch erwähnen, dass C++ sowieso eine Hybridsprache ist.
Wer vollständig OOP Programmieren will sollte sich eher Sprachen wie Smalltalk widmen.
> Code zu schreiben und dort sind komplexe Datenstrukturen teilweise extrem hinderlich.
> Das Bedeutet nicht, dass man kein C++ nutzen kann, aber es gibt Fälle, wo man
> lieber auf OOP verzichtet (innerhalb von C++ ja kein Problem) oder in
> extremfällen sogar auf ASM zurückgreifen sollte.
Um mal bei der Problemstellung STL und komplexe Datenstrukturen zu bleiben: Wenn Du laufzeitkritische Operationen auf STL-Klassen machen willst, hilft Dir partielle Spezialisierung wunderbar weiter. Definiere für Deine Datentypen speziell optimierte Bearbeitungsroutinen (von mir aus mit Inline-Assembler) und schon sieht die Welt wieder besser aus. Wenn Du dann noch konsequent darauf baust, bei der Übergabe von Objektreferenzen auch wirklich Referenzen zu verwenden, anstatt die Datenstruktur jedesmal implizit kopieren zu lassen, gibt es nur noch theoretische Vorteile der Lösung, die "kurz mal das OOP außen vor läßt".
> Die STL muss nicht zwangsläufig langsamer sein, als wenn man die Datenstrukturen
> selbst implementiert, aber umso komplexer diese Strukutren sind, umso langsamer
> sind sie auch.
Das kann und will ich so einfach nicht abnicken. Die STL ist, was ihre Spezifikation angeht, ziemlich optimal implementiert. Datentypspezifische Optimierungen kann man (siehe oben) schnell und einfach selbst erledigen. Und dank der breiten Palette an Datenstrukturen hat man auch jede Menge Möglichkeiten, mit Standardfunktionalität _algorithmisch_ zu optimieren, ohne gleich Hashtabellen, Mappings, Vektoren oder Strings neu implementieren zu müssen. Überhaupt sollte man mE viel mehr Hirnschmalz investieren, algorithmisch zu optimieren. Implementationsoptimierung durch Inlining, Assembler o.ä. überdeckt für mich immer so ein bißchen die algorithmischen Schwächen. :)
lg
Erik
Aus der Nummer kommt man wirklich nur raus wenn man komplett auf Zeiger verzichtet und wirklich alles nur noch ein Objekt/Klasse ist, wo zudem ein Garbage Collector im Hintergrund sich um die Speicherverwaltung kümmert...
Das die STL langsam sein soll habe ich auch nicht gehört. Aber man lernt ja nie aus
C - mag zwar alt sein, und es gibt leider auch konkurrierende Sprachstandards
Beispiel c89, c99
in c99 kann ich das machen
..
for (int i = 0; i < 10; i++)
..
in c89 muss ich es wie folgt machen
..
int i = 0;
for ( ; i < 10 ; i++)
..
wie man daran schon sieht, es gibt "keine" Universalsprache, und jede Sprache
hat Ihre Stärken und Schwächen, im Endeffekt würde ich sagen mit C - Code verhält
es sich ähnlich wie mit Perl man kann "Perl" programmieren oder man kann "Pöährl" programmieren,
von hervorragend lesbar, bis ich brauche einen Ägyptologen, um das zu entziffern,
C nimmt einem Programmierer das Denken über die Speicherverwaltung und die eigenen
Aktionen im Speicher eben nicht ab, genauso wenig dies C++ u. Objective-C machen,
aber es gibt halt noch den Punkt der bei Menschen immer hinzu kommt, der eigene Geschmack,
ich würde z.B. eine Kombination von C (rein prozedurale Lösungen) und Java(rein objektorientierte Lösungen) vorziehen, da C++ z.B. nicht nach meinem "Geschmack" ist.
sorry das war nicht ganz deutlich, aber Du hast in Deinem Punkt natürlich recht.
In der GCC ist sogar ein Java-Compiler der in Maschinencode (nicht Bytecode) compiliert!
Und Ada wollen wir auch nicht vergessen...
Aber C,C++ ist doch der reinste Horror!