Warum wird C mehr benutzt als C++?
-
C-reator schrieb:
und nicht so viele extremkryptische Funktionen wie "strcmp" oder "isalnum"
und was findest du "extrem kryptisch" an diesen 2 Funktionen (wobei das letzte ein Makro ist)? Was "kryptisch" anbetrifft, schlägt C++ C um Längen, vor allem, wenn man mit Templates (von templates von templates ...) arbeitet. *Das* finde ich kryptisch
-
Weil C++ viel schwieriger ist als C.
Außerdem hat C++ das Problem das es auf C aufbaut das führt oft zu seltsamen Effekten, deshalb muss man sehr gut C++ können um z.B. eine ordentliche libary zu schreiben.
Und wenn jemand sehr gut C++ schreiben kann, dann gibt es nur wenige die seinen Code verstehen.C++ ist zwar hochperformant und OO aber man braucht meist nicht diese Performance und OO Sprachen gibt es genug.
-
C-reator schrieb:
C++ ist meiner Meinung nach doch viel besser strukturiert
findeste? meiner meinung nach ist C++ ein undurchdachter mix aus features, die teilweise noch nicht mal zusammenpassen.
C-reator schrieb:
...und nicht so viele extremkryptische Funktionen wie "strcmp" oder "isalnum" und so weiter
ja, manche namen sind doof, aber c++ programme werden in der regel kryptischer.
C-reator schrieb:
Oder ist C schneller als C++?
eigentlich nicht, das liegt an den programmierern. c++ programmierer denken zu kompliziert und das hat manchmal lahme programme zur folge.
-
;fricky schrieb:
C-reator schrieb:
Oder ist C schneller als C++?
eigentlich nicht, das liegt an den programmierern. c++ programmierer denken zu kompliziert und das hat manchmal lahme programme zur folge.
Man braucht dazu nichtmal C++. Ich hatte kürzlich einen in C geschriebenen Ini- Parser in ein Projekt gelinkt, weil er augenscheinlich ging. Später hat sich herausgestellt, daß das Ding bei ganz bestimmten Strings als Parameter crasht, da hab' ich es mal auseinandergenommen. Der Autor hat sich mit Hashtables, Preindices usw. dermaßen verkopft, daß ihm bei Spezialfällen ein paar miss-by-ones entgangen sind.
Ich hab's mit sequentieller Suche primitivo nachgestrickt und dabei 4 kB Objectcode sowie (bei 50 Parametern in der ini) 50 kB überwiegend leerstehendes RAM auf dem Heap gespart und keine Crashes mehr. Bis 50 Parametern ist mein Nachbau sowieso schneller.Jetzt halte ich mich nicht für den Supercoder, aber der ursprüngliche Autor ist wohl in ein Fahrwasser geraten, so daß er "unstrukturierte Daten = Hashtable + Indexing" als einzig gangbaren Weg gesehen und dabei die ursprüngliche Aufgabe, ein paar Parameter ausm ini auszulesen, übersehen hat. Dafür ist das zu oversized und umständlich, da kommen Bugs und lahmes Verhalten von selbst.
Bei C++ tritt das verschärft auf, weil die Leutchen oft auf Teufel- komm- raus Probleme auf die STL- Bestandteile abbilden wollen, die sie kennen. Da spielt auch der Kenntnisstand eine große Rolle, ob das passend wird; oft genug wird lahmer Murks draus, weil mehr darüber nachgedacht wird, Daten und Aufgaben auf die STL zurechtzuhämmern, als die Aufgabe an und für sich zu lösen.
Lahmen Käse kannst Du aber in C wie in C++ produzieren.
-
pointercrash() schrieb:
Bei C++ tritt das verschärft auf, weil die Leutchen oft auf Teufel- komm- raus Probleme auf die STL- Bestandteile abbilden wollen, die sie kennen. Da spielt auch der Kenntnisstand eine große Rolle, ob das passend wird; oft genug wird lahmer Murks draus, weil mehr darüber nachgedacht wird, Daten und Aufgaben auf die STL zurechtzuhämmern, als die Aufgabe an und für sich zu lösen.
Komisch. Wenn ich die Übersicht zu verlieren drohe, oder einen guten Trick deswegen nicht einbauen kann, verstärke ich den Objektorientierungsdruck und alles wird wieder gut.
-
Ich hatte kürzlich einen in C geschriebenen Ini- Parser in ein Projekt gelinkt
War das für eine "große" Maschine? In solchen Fällen bin ich auf den Geschmack von Lua gekommen. Wäre etwas in der Art zu groß gewesen?
-
µngbd schrieb:
Ich hatte kürzlich einen in C geschriebenen Ini- Parser in ein Projekt gelinkt
War das für eine "große" Maschine? In solchen Fällen bin ich auf den Geschmack von Lua gekommen. Wäre etwas in der Art zu groß gewesen?
Definitiv.
War eine Multiplattform- Schreibe, an ANSI-C gebunden. Je nach include guards wird eine Win-DLL, eine Linux- oder Win- Konsole oder ein µC- Compilat derzeit für M16/32C bzw. SH draus. Inis zu parsen ist nur eine Unterfunktion. Ich sehe nichtmal, wie mir da Lua hätte helfen können, ich muß mir ja derzeit nur zu Beginn 53 Parameter einpfeifen.volkard schrieb:
Komisch. Wenn ich die Übersicht zu verlieren drohe, oder einen guten Trick deswegen nicht einbauen kann, verstärke ich den Objektorientierungsdruck und alles wird wieder gut.
- Gute Tricks sind immer schlechte Tricks für die Lesbarkeit und tendieren zu Seiteneffekten.
- Wenn Du die Übersicht verlierst, hast Du wahrscheinlich falsch und/oder konzeptlos angefangen.
- Mit OOP als propagiertes Allheilmittel hast Du eher prozedurale Programmierung nicht mehr souverän im Hinterkopf.Letztlich rattern die Kisten nur Maschinencode ab, ohne sich um OOP usw. zu kümmern, HL-Sprachen sind ja nur Abstraktionskonzepte. Ohne OOP den Überblick zu verlieren ist wirklich kein Konzept, sondern nur voll "komisch".
-
pointercrash() schrieb:
Lahmen Käse kannst Du aber in C wie in C++ produzieren.
ja, aber in C musste dich anstrengen, irgendwas unnötig kompliziert und lahm zu machen. in C++ geht sowas wie von selbst.
µngbd schrieb:
Ich hatte kürzlich einen in C geschriebenen Ini- Parser in ein Projekt gelinkt
War das für eine "große" Maschine? In solchen Fällen bin ich auf den Geschmack von Lua gekommen. Wäre etwas in der Art zu groß gewesen?
dort wo C eingesetzt wird, sind rechenpower und speicher oft mangelware. ein skriptsprachen-interpreter wäre in vielen fällen nur ein klotz am bein.
-
;fricky schrieb:
pointercrash() schrieb:
Lahmen Käse kannst Du aber in C wie in C++ produzieren.
ja, aber in C musste dich anstrengen, irgendwas unnötig kompliziert und lahm zu machen. in C++ geht sowas wie von selbst.
Betrifft nur Anfänger. Also irrelevant.
-
;fricky schrieb:
dort wo C eingesetzt wird, sind rechenpower und speicher oft mangelware. ein skriptsprachen-interpreter wäre in vielen fällen nur ein klotz am bein.
Richtig.
Wer an C bzw. C++ denkt, darf sein Blickfeld nicht auf Windows- und Linux- Rechner (mit leistungsfähigen Rechnern) beschränkt sehen.Gerade in der embedded Welt ist "C" DIE am meisten verbreitete Sprache, insbesondere bei 4-, 8- und 16-bit µC (Mikro-Controllern).
In jeder Waschmaschine, in jedem Elektronik-Firlefanz im Auto steckt so eines oder mehrere µC drin ... mit oftmals nur einige 100 Bytes (!) RAM...
Martin
-
Mmacher schrieb:
mit oftmals nur einige 100 Bytes (!) RAM...
Das ist ja eh schon einiges... ein Attiny13 hat 64Byte Ram und 1024Byte Programmspeicher.
-
volkard schrieb:
;fricky schrieb:
pointercrash() schrieb:
Lahmen Käse kannst Du aber in C wie in C++ produzieren.
ja, aber in C musste dich anstrengen, irgendwas unnötig kompliziert und lahm zu machen. in C++ geht sowas wie von selbst.
Betrifft nur Anfänger. Also irrelevant.
kommt drauf an, ab welchem level sich ein c++-user als fortgeschrittener bezeichnen darf. viele glauben das vielleicht von sich selbst, weil sie mit stl und boost jonglieren können und den standard auswendig gelernt haben. aber wahrscheinlich ist gerade das irrelevant.
-
volkard schrieb:
Betrifft nur Anfänger. Also irrelevant.
Unsinn. Ich hatte mal vor über 10 Jahren C- Code hergegeben, der ging an ein Softwarehaus und ich habe selber parallel, zeitweilig in Assembler, FORTH, zuletzt in C dran weitergewurschtelt, die "Profis" durchgängig in C++. Daraus ist ein 900 kB- Monster geworden und wird jetzt abgeschafft.
Meine Version kommt mit 80 kB aus, hat etliche Features mehr und rennt am Win-PC etwa 10mal so schnell. Argumente genug, der Endkunde lizensiert das als DLL neu.Ich kann nicht zaubern, bin kein selbsternannter Hackergott, sondern habe mich nur um ein spezielles Problem gekümmert und es in C gelöst.
Auf der C++ Seite waren nacheinander drei Jungs dran, alle studiert, abgeschlossen und mit mindestens drei Jahren praktischer Erfahrung.
Das waren keine Anfänger, sondern schlimmstenfalls Verblendete.Warum also soll es irrelevant sein, wenn ich als C- Gelegenheitsprogrammierer was objektiv Besseres hinkriege als C++- Vollzeitprofis? Die sind nicht doof, die denken nur zu kompliziert.
-
pointercrash() schrieb:
Auf der C++ Seite waren nacheinander drei Jungs dran, alle studiert, abgeschlossen und mit mindestens drei Jahren praktischer Erfahrung.
Können trotzdem Anfänger sein. Traurig aber wahr, sowas seh ich jeden Tag. Manche hören wohl nach dem Studium auf, sich weiterzuentwickeln.
Allerdings widerspricht das Volkards These. Dinge, die nur Anfänger betreffen, sind trotzdem relevant.
-
Kein Bange, die hätten das auch in C vergeigt.
-
volkard schrieb:
Kein Bange, die hätten das auch in C vergeigt.
das kann man nicht verallgemeinern. pc()'s erfahrung kann ich insofern bestätigen, als dass ich auch einige vollkommen vergurkte C++ projekte gesehen habe, aber noch nie C-programme, die schon im kern dermaßen kaputt waren, dass es kaum rettung gab. konkret: zwei hatten speicherhunger und kopierorgien beliebter c++-konstrukte unterschätzt (embedded system), ein anderer hat mit kreuz-und-quer mehrfachvererbung im generalisierungswahn ein unwartbares chaos geschaffen. wenn du sagst, dass das alles c++anfänger waren, dann hast du vieleicht recht, aber wie oft muss einer mit c++ auf die nase fliegen, um nicht mehr als anfänger zu gelten?
-
Hallo,
C kannst du meines Wissens komplett vergessen.
-
;fricky schrieb:
volkard schrieb:
Kein Bange, die hätten das auch in C vergeigt.
das kann man nicht verallgemeinern. pc()'s erfahrung kann ich insofern bestätigen, als dass ich auch einige vollkommen vergurkte C++ projekte gesehen habe, aber noch nie C-programme, die schon im kern dermaßen kaputt waren, dass es kaum rettung gab. konkret: zwei hatten speicherhunger und kopierorgien beliebter c++-konstrukte unterschätzt (embedded system), ein anderer hat mit kreuz-und-quer mehrfachvererbung im generalisierungswahn ein unwartbares chaos geschaffen. wenn du sagst, dass das alles c++anfänger waren, dann hast du vieleicht recht, aber wie oft muss einer mit c++ auf die nase fliegen, um nicht mehr als anfänger zu gelten?
Er kann tausendmal auf die Nase fliegen und nicht "Effektiv C++ programmieren" oder ein anderes gutes C++-Buch lesen und hundert Jahre lang C++-Anfänger bleiben.
Das scheint mir gerade bei den embedded-Programmierern auch sehr üblich zu sein, daß man sich für den C-Gott hält, und andere Sprachen kraft Göttlichkeit zu beherrschen wähnt. Dir nehme ich aber nichmal mehr ab, daß Du gut in C bist.Und wenn der Bauer nicht schwimmen kann, ist die Badehose dran schuld.
-
volkard schrieb:
Er kann tausendmal auf die Nase fliegen und nicht "Effektiv C++ programmieren" oder ein anderes gutes C++-Buch lesen und hundert Jahre lang C++-Anfänger bleiben.
ja, ich befürchte auch, dass es ohne viel gute literatur garnicht möglich ist, dem c++ anfängertum zu entfleuchen. aber man muss das gelesene auch in der praxis sinnvoll anwenden können, was auf c++ bezogen scheinbar eine grosse hürde ist. erst wenn das einigermassen klappt, lässt man das embryonale stadium so langsam hinter sich.
volkard schrieb:
Das scheint mir gerade bei den embedded-Programmierern auch sehr üblich zu sein, daß man sich für den C-Gott hält, und andere Sprachen kraft Göttlichkeit zu beherrschen wähnt.
nee, ganz im gegenteil. die embedded-leute sind eigentlich grösstenteils sehr empfänglich für kritik, was ihre programmierkünste angeht. sie lernen gern voneinander und sind sehr hilfsbereit, wenn z.b. mal einer nicht weiterkommt oder wissenslücken hat. vielleicht liegts daran, dass sie für ihr selbstwertgefühl nicht die tatsache brauchen, ein toller coder zu sein, sondern weil programmiererei nur ein teil des jobs ist. je weniger code einer schreiben muss, um sein ziel zu erreichen und je einfacher der code wird, desto mehr freut ihn das. wenn er dabei noch hilfe bekommt - umso besser.
volkard schrieb:
Dir nehme ich aber nichmal mehr ab, daß Du gut in C bist.
stimmt ja auch. ich hab' schon mehr als einmal extremen mist programmiert, bei dem ich mich am nächsten tag gefragt habe, wie das überhaupt funktionieren konnte.
-
;fricky schrieb:
volkard schrieb:
Er kann tausendmal auf die Nase fliegen und nicht "Effektiv C++ programmieren" oder ein anderes gutes C++-Buch lesen und hundert Jahre lang C++-Anfänger bleiben.
ja, ich befürchte auch, dass es ohne viel gute literatur garnicht möglich ist, dem c++ anfängertum zu entfleuchen. aber man muss das gelesene auch in der praxis sinnvoll anwenden können, was auf c++ bezogen scheinbar eine grosse hürde ist. erst wenn das einigermassen klappt, lässt man das embryonale stadium so langsam hinter sich.
Das erinnert mich an die Mathematik. Fehlgeleitete berechnen mit ihr auch viel Mist. Aber ob das ein Grund ist, immer beim Schätzen zu bleiben?