welche vorteile bietet c++ gegenüber c
-
hmmhmmhmm schrieb:
Nenne mir mal eine Sprache die weiter verbreitet ist als Java und dennoch einfach er erlernen ist???
keine Ahnung, ich kanns mir nur nicht vorstellen
-
cooky451 schrieb:
ZumHundertstenMal schrieb:
cooky451 schrieb:
Es ist für jeden interessant der Algorithmen jenseits von Bubblesort implementieren möchte.
Na, so langsam ist Python nun doch wieder nicht.
Wie gesagt, du magst ja schlechte Erfahrungen mit deinem Lehrer gemacht haben, aber die Sprache ist sicherlich nicht das Problem.
Es geht hier nicht um die Geschwindigkeit sondern darum, dass ich es sinnlos finde Algorithmen für einen Computer zu implementieren (nach diesem Schritt hat man die abstrakte Mathematik ja schon hinter sich gelassen) ohne sich Gedanken über Speicher, Overhead, etc. zu machen. Denn diese Überlegungen sind es doch die den Schritt Mathematik->Implementierung ausmachen. Wenn ich diesen aber nicht gehen möchte, brauche ich auch kein Python/sonstwas.
Du vielleicht nicht, aber es gibt einen ganzen Haufen Leute, die nicht programmieren, weil sie es so toll finden, sondern einfach, weil sie was ausprobieren, ein Konzept validieren, oder ein paar Sachen einmal berechnen wollen.
Dafür ist die Entwicklungszeit relevant und nicht unbedingt, ob der Speicher optimal genutzt wird oder der Code ohne Veränderungen auf irgendeiner Embedded CPU der Waschmaschine oder dem Aufzug läuft. Wenn das die Constraints sind, dann entwickelt man Software ohnehin anders, als das, was üblicherweise auf einem Desktop-System gestartet und beendet wird.
-
hmmhmmhmm schrieb:
Nenne mir mal eine Sprache die weiter verbreitet ist als Java und dennoch einfach er erlernen ist???
C
-
Daniel E. schrieb:
Dafür ist die Entwicklungszeit relevant und nicht unbedingt, ob der Speicher optimal genutzt wird oder der Code ohne Veränderungen auf irgendeiner Embedded CPU der Waschmaschine oder dem Aufzug läuft. Wenn das die Constraints sind, dann entwickelt man Software ohnehin anders, als das, was üblicherweise auf einem Desktop-System gestartet und beendet wird.
Mein Code läuft auch auf der Waschmaschine im Aufzug!
Zudem ist die Entwicklungszeit bei Programmieranfängern wohl eher irrelevant.die nicht programmieren, weil sie es so toll finden, sondern einfach, weil sie was ausprobieren,
??
ein Konzept validieren,
Aha.. und jetzt noch mal für kleine Fische, denn einen Zusammenhang zum Thema kann ich hier irgendwie nicht erkennen.
oder ein paar Sachen einmal berechnen wollen.
Dafür muss man auch eigene Programme schreiben..
-
Es geht hier nicht um die Geschwindigkeit sondern darum, dass ich es sinnlos finde Algorithmen für einen Computer zu implementieren (nach diesem Schritt hat man die abstrakte Mathematik ja schon hinter sich gelassen) ohne sich Gedanken über Speicher, Overhead, etc. zu machen.
Du sagst auf der einen Seite, dass die Geschwindigkeit nicht das Argument ist, man sich auf der anderen Seite aber trotzdem Gedanken um Overhead und Speicherverbrauch machen soll. Seltsame Argumentation...
Denn diese Überlegungen sind es doch die den Schritt Mathematik->Implementierung ausmachen.
Nein. Man kann Programme sogar so entwerfen, dass gar kein Unterschied zwischen Mathematik und Implementierung besteht (siehe Funktionale Programmierung).
Diese Überlegungen müssen gemacht werden, wenn man das letzte Quäntchen Geschwindigkeit herausholen möchte.Wichtig für Programmieranfänger (oder desinteressierte Schüler) ist doch nicht, wie ein Algorithmus mit dem Speicherplatz umgeht, sondern wie der Algorithmus funktioniert.
C
Das Problem an C ist, dass gerade desinteressierte Schüler damit überhaupt nichts gebacken bekommen werden, sobald es über "Hello World" hinausgeht. Die Sprache ist zwar nur etwas besserer Assembler und deswegen sehr einfach zu verstehen, aber wegen der geringen Abstraktionsmöglichkeiten muss man halt häufig großen Aufwand betreiben, was ich desinteressierten Schülern nicht zutraue.
-
ZumHundertstenMal schrieb:
Das Problem an C ist, dass gerade desinteressierte Schüler damit überhaupt nichts gebacken bekommen werden, sobald es über "Hello World" hinausgeht.
Alle Anfänger sind komplett bescheuert.
-
ZumHundertstenMal schrieb:
Es geht hier nicht um die Geschwindigkeit sondern darum, dass ich es sinnlos finde Algorithmen für einen Computer zu implementieren (nach diesem Schritt hat man die abstrakte Mathematik ja schon hinter sich gelassen) ohne sich Gedanken über Speicher, Overhead, etc. zu machen.
Du sagst auf der einen Seite, dass die Geschwindigkeit nicht das Argument ist, man sich auf der anderen Seite aber trotzdem Gedanken um Overhead und Speicherverbrauch machen soll. Seltsame Argumentation...
Nein. Vielleicht war das mit der Geschwindigkeit nur falsch Ausgedrückt. Es geht nicht um die absolute Geschwindigkeit, was ich damit meinte ist dass es nicht darum geht dass Python jetzt hier und da langsamer ist als C, sondern dass es bei einer Implementierung auch Sinn macht sich Gedanken über zu Speicher etc. zu machen.
Wichtig für Programmieranfänger (oder desinteressierte Schüler) ist doch nicht, wie ein Algorithmus mit dem Speicherplatz umgeht, sondern wie der Algorithmus funktioniert.
Dafür muss man nicht programmieren. Da reicht Mathe.
Das Problem an C ist, dass gerade desinteressierte Schüler damit überhaupt nichts gebacken bekommen werden, sobald es über "Hello World" hinausgeht. Die Sprache ist zwar nur etwas besserer Assembler und deswegen sehr einfach zu verstehen, aber wegen der geringen Abstraktionsmöglichkeiten muss man halt häufig großen Aufwand betreiben, was ich desinteressierten Schülern nicht zutraue.
Desinteressierte Schüler müssen auch nicht in die Oberstufe gehen und Informatik wählen.
-
Alle Anfänger sind komplett bescheuert. Anfänger != Desinteressierte Schüler
Du warst wahrscheinlich schon lange nicht mehr in einer gymnasialen Oberstufe, aber Programmierung ist nicht sonderlich angesagt.
sondern dass es bei einer Implementierung auch Sinn macht sich Gedanken über zu Speicher etc. zu machen.
Wie gesagt: Den Sinn sehe ich nicht, wenn es nur darum geht, die zugrundeliegenden Konzepte der Programmierung zu verstehen.
Und dafür reicht Python vollkommen aus.Dafür muss man nicht programmieren. Da reicht Mathe.
Ja, genau - und Informatik ist auch zu weiten Teilen Mathe.
Aber man möchte doch sicherlich auch mal testen, ob das, was man sich da überlegt hat, auch funktioniert.Desinteressierte Schüler müssen auch nicht in die Oberstufe gehen und Informatik wählen.
D.h. ihr habt interessierte Schüler bei euch im Informatikkurs, die den Unterschied zwischen '2' und 2 nicht erklären können? Schwer zu glauben.
-
ZumHundertstenMal schrieb:
Wie gesagt: Den Sinn sehe ich nicht, wenn es nur darum geht, die zugrundeliegenden Konzepte der Programmierung zu verstehen.
Und dafür reicht Python vollkommen aus.Zum Konzept der Programmierung gehört nunmal auch Speicher etc.
Dafür muss man nicht programmieren. Da reicht Mathe.
Ja, genau - und Informatik ist auch zu weiten Teilen Mathe.
Aber man möchte doch sicherlich auch mal testen, ob das, was man sich da überlegt hat, auch funktioniert.Zum testen kann mans auch einfach ausrechnen.
D.h. ihr habt interessierte Schüler bei euch im Informatikkurs, die den Unterschied zwischen '2' und 2 nicht erklären können? Schwer zu glauben.
Ich glaube es gibt einen Unterschied zwischen Schülern, die desinteressiert sind und solchen, die den oups: nicht ganzen Tag irgendwelche Diskussionen über das Lehren von Programmiersprachen führen
-
cooky451 schrieb:
sondern dass es bei einer Implementierung auch Sinn macht sich Gedanken über zu Speicher etc. zu machen.
Falsch, Gedanken zu Laufzeit und Speicherverbrauch hat man sich in der Theorie wenn man einen Algorithmus entwickelt (oder viel eher wenn man ihn nachvollzieht im Unterricht). Schließlich sind die verschiedenen Sortieralgorithmen Musterbeispiele für die verschiedenen Laufzeiten und den verschiedenen Speicherverbrauch bei unterschiedlichen Algorithmen. Das hat aber mit programmieren nichts zu tun.
cooky451 schrieb:
Zum Konzept der Programmierung gehört nunmal auch Speicher etc.
Richtig, aber nicht Interna wie "Speicher anfordern" und "Speicher freigeben":
function x() {
integer i; // speicher für eine einzelne Zahl wird angefordert
...
return;
} // speicher wieder frei
-
BierzeltOmi schrieb:
cooky451 schrieb:
sondern dass es bei einer Implementierung auch Sinn macht sich Gedanken über zu Speicher etc. zu machen.
Falsch, Gedanken zu Laufzeit und Speicherverbrauch hat man sich in der Theorie wenn man einen Algorithmus entwickelt (oder viel eher wenn man ihn nachvollzieht im Unterricht). Schließlich sind die verschiedenen Sortieralgorithmen Musterbeispiele für die verschiedenen Laufzeiten und den verschiedenen Speicherverbrauch bei unterschiedlichen Algorithmen. Das hat aber mit programmieren nichts zu tun.
Wenn man sich schon ein Speicherkonzept überlegt hat, warum soll man es dann nicht auch implementieren? Dann hat man doch quasi schon eine "C Lösung", warum dann nicht auch C nutzen?
cooky451 schrieb:
Zum Konzept der Programmierung gehört nunmal auch Speicher etc.
Richtig, aber nicht Interna wie "Speicher anfordern" und "Speicher freigeben":
function x() {
integer i; // speicher für eine einzelne Zahl wird angefordert
...
return;
} // speicher wieder freiHä? So sieht das doch aber in C aus? Ich verstehe nicht, was Du damit sagen willst.
-
Hä? So sieht das doch aber in C aus? Ich verstehe nicht, was Du damit sagen willst.
Ich glaube es geht eher darum, dass der Compiler hier für
integer iSpeicherplatz reserviert, den er automatisch wieder frei gibt - und das ohne dein Zutun.Du möchtest nunmal eher low-levelig verstehen, was im Computer genau vor sich geht. Dabei ziehst du allerdings ziemlich willkürlich die Grenze bei der Hochsprache (!) C, obwohl du noch viel weiter runter gehen könntest (Assembler, Maschinensprache, genaue Funktionsweise einer ALU, etc.).
Das ist zwar alles interessant, hat aber irgendwann nicht mehr sonderlich viel mit Informatik zu tun und ist deshalb auch kein sinnvoller Einstieg in die Programmierung. Besonders, wo es doch heutzutage so viele Sprachen gibt, die diese ganzen Details erstmal verstecken, davon abstrahieren, sodass man sich voll und ganz auf das Lösen des Problems konzentrieren kann.
Natürlich sollte so etwas wie Speicherverbrauch und Geschwindigkeit kein totales Fremdwort sein, aber zunächst sollte dort nicht der Hauptaugenmerk liegen.
Ich glaube es gibt einen Unterschied zwischen Schülern, die desinteressiert sind und solchen, die den ganzen Tag irgendwelche Diskussionen über das Lehren von Programmiersprachen führen
Und welche kennen den Unterschied zwischen '2' und 2 nicht? Sicherlich die Desinteressierten. Aber dann liegt es an ihnen oder/und am Lehrer und nicht an der Sprache.
-
ZumHundertstenMal schrieb:
Ich glaube es gibt einen Unterschied zwischen Schülern, die desinteressiert sind und solchen, die den ganzen Tag irgendwelche Diskussionen über das Lehren von Programmiersprachen führen
..
Sorry, da fehlte ein "nicht" in dem Satz. Sollte lauten:
Ich glaube es gibt einen Unterschied zwischen Schülern, die desinteressiert sind und solchen, die nicht den ganzen Tag irgendwelche Diskussionen über das Lehren von Programmiersprachen führen
Und ja, wie ein Compiler in etwa funktioniert bzw. wie eine ALU arbeitet ist natürlich auch interessant und sollte erklärt werden. Auch Schaltkreise und Assembler sollte man mal besprochen haben. Man muss das ja nicht bis zum erbrechen machen, aber Informationsverarbeitung gehört halt doch dazu
Und ich ziehe die Grenze bei C, weil weil man hier einerseits relativ leicht auf die Abläufe in Assembler schließen kann, aber andereseits eine schöne, Systemunabhängige Sprache hat.
-
C und auch C++ würde ich auch heute nicht mehr als Hochsprache definieren, sondern C eher als portabler Assembler und C++ als Aufsatz der versucht wurde so viel Paradigmen wie möglich zu integrieren.
Man muss heute schon ziemlich blöd sein um ein Projekt komplett in einer Systemsprache zu realisieren, wenn es nicht wirklich 100% nötig ist. Die nachteilen von solchen portablen Assembler sind einfach zu hoch und die Lernkurve ziemlich flach. Der Kosten-/Nutzenfaktor stimmt bei den meisten Projekten einfach nicht mehr.
Aber zum Glück muss man seine Brötchen als Entwickler heute nicht mehr mit portablen Assembler verdienen oder wie noch früher mit Lochkarten.
-
Und ja, wie ein Compiler in etwa funktioniert bzw. wie eine ALU arbeitet ist natürlich auch interessant und sollte erklärt werden. Auch Schaltkreise und Assembler sollte man mal besprochen haben. Man muss das ja nicht bis zum erbrechen machen, aber Informationsverarbeitung gehört halt doch dazu
Ja, meinetwegen. Aber dann soll es vielleicht an zwei, drei Terminen besprochen werden und gut ist's.
Um mal zusammenzufassen:
- Man braucht kein C um C++ lernen zu können, da es genug gute Bücher gibt, die C++ didaktisch gut aufbereiten (und die natürlich trotzdem auch auf Zeiger, Speicherverwaltung, etc. eingehen!)
- Für die Schule mag C angemessen sein, wenn es darum geht Computerinterna zu lehren (also wie Speicher verwaltet wird, was Zeiger sind, etc.)
- Wenn es allerdings darum geht zu Programmieren, kann man auch ruhig auf eine Sprache wechseln, die das Programmieren erstmal so einfach wie möglich macht (also z.B. Python), damit man sich voll auf die Problemlösung konzentrieren kann
-
C ist ja viel liberaler als C++.
Wenn ich in C irgend eine große Aufgabe schön in Teilaufgaben zerlege (aka pro-
zedural programmiere) - nach dem Motto: 'Teile und Herrsche' - und damit letzten
Endes die Aufgabenstellung löse, ist ja alles in bester Ordnung.
Aber schon allein diese Herangehensweise ist ja aus C++ Sicht fehlerhaft.
Mit C++ versucht man's ja idR umgekehrt: Erstmal eine paar Klassen und Templates
erfinden, und die dann irgendwie krampfhaft zur Lösung der Aufgabe
zusammenbasteln, ob die Grundobjekte nun passen oder nicht ist ja sekundär.
Darüber hinaus bevorzugt man in C++ ja auch lieber verbuggten
(dafür aber schön objektorientierten) Quellcode, gegenüber jeder
prozeduralen Lösung - und wenn auch letztere noch so zufriedenstellend funk-
tionieren sollte - das (aus C++ Sicht) miese Design spricht ja dagegen.
Beim Programmieren mit C steht ja im Vordergrund, dass ein Programm das
tut, was es soll (It gets the job done ...).
Bei C++ haben da eher so Dinge wie Design und klinisch reiner
(uninspirierter) Quellcode Vorrang vor dem korrekten Funktionieren des
Programms.
Selbstverständlich verwendet man auch in C vorgefertigte Bibliotheken und
erfindet nicht immer das Rad von vorne. Aber ob man in C eine Aufgabe nun
schön prozedural/modular löst, oder objektorientiert, oder in sonst irgend
einer Weise - ist in erster Linie dem Programmierer überlassen, und viel
weniger von den Design-Vorstellungen irgendwelcher Elfenbeinturm-Ästheten &
'Standardisierer'.
Und mit C braucht man sich dann angesichts funktionierender Lösungen selten
was anzuhören, wie mies doch das Design wäre und was doch der liebe Standard
eigentlich 'vorschreibt' etc.
Also C++ schränkt mir die Freiheiten als Programmierer so massiv ein, dass
man nichtmal prozedural programmieren darf und deshalb schonmal 90% aller
Aufgabenstellungen gar nicht oder grob suboptimal lösbar sind.C ist ja auch viel besser geeignet, um eine mittelgroße Aufgabe 'frontal'
anzugehen, ich hab mit meinem Freund vor ca. 2 Monaten einen kleinen
Wettkampf gestartet (Umsetzung eines Schachprogramms: Er sollte C++, ich C
verwenden).
Während er immer noch beim Planen ist und noch nichtmal ein paar
Grundfunktionen implementiert hat, gibt's von meinem Programm längst schon
eine funktionierende Beta-Version, die obendrein auch recht stark spielt.
Also es ist ja nichtmal wahr, dass sich mit C++ ein Programm irgendwie schneller
umsetzen ließe, als mit C (hört man ja auch gerne, dieses (unzutreffende)
Argument).Die C++ - Skriptkiddies sind ja nichts weiter als die Restl-Verwerter
irgendwelcher verbuggten Code-Schnippsel, die ein paar andere 'C++ Experten,'
ohne Ahnung vom prozeduralen Paradigma, im Laufe der Jahre und
Jahrzehnte 'weiter' entwickelt haben (ohne zu wissen, was eigentlich das
End-Resultat sein soll). Programmierung ohne konkreter Vorstellung vom ge-
wünschten End-Resultat kann ja nunmal zu nichts Sinnvollem führen.
Kurzum - C ist auch wesentlich konkreter als C++.Also mE bietet C++ nur sehr viele Nachteile gegenüber C, weil C++ die Freiheiten
des Programmierers so sehr einschränkt und deshalb nur zur Entwicklung von
verbuggten und - in Punkto Endresultat - unspezifizierten
Programmen geeignet ist.
-
freigeist3 schrieb:
C ist ja auch viel besser geeignet, um eine mittelgroße Aufgabe 'frontal'
anzugehen, ich hab mit meinem Freund vor ca. 2 Monaten einen kleinen
Wettkampf gestartet (Umsetzung eines Schachprogramms: Er sollte C++, ich C
verwenden).
Während er immer noch beim Planen ist und noch nichtmal ein paar
Grundfunktionen implementiert hat, gibt's von meinem Programm längst schon
eine funktionierende Beta-Version, die obendrein auch recht stark spielt.
Also es ist ja nichtmal wahr, dass sich mit C++ ein Programm irgendwie schneller
umsetzen ließe, als mit C (hört man ja auch gerne, dieses (unzutreffende)
Argument).Weil Du gut C kannst und er schlecht C++.
Hättest den Test mal mit mir machen sollen, höhöhö.
-
freigeist3 schrieb:
Also mE bietet C++ nur sehr viele Nachteile gegenüber C, weil C++ die Freiheiten
des Programmierers so sehr einschränkt und deshalb nur zur Entwicklung von
verbuggten und - in Punkto Endresultat - unspezifizierten
Programmen geeignet ist.
Kompletter Unfug. Man ist natürlich in C++ viel freier, denn man kann mit dem C++-Compiler ja auch guten C-Code machen. Aber man darf auch, wo es passend ist, Templates, RAII, Exceptions, Funktionsüberladung, Operatorenüberladung, Laufzeitpolymorphie und dies und das benutzen. Ist man nicht freier, wenn man mehr darf?
-
Naja, irgendwo muss ich ihm schon Recht geben. Während man irgendwas in C++ programmiert, das etwas zu kompliziert ist, um es von Anfang an richtig (tm) zu implementieren, hat man verhältnismäßig mehr Arbeit, um das ganze wieder zu refactoren. Hängt natürlich auch so ein bisschen vom Menschen ab. Aber ich hatte schon oft die Situation, in der die Idee einfach war, aber unter dem Gesichtspunkt der "du hast ein Fehler in deinem Design"-Klatsche auf einmal zu einem wahren Akt wurde. Der ganze Klassenschmu mit all seinen Freiheiten nimmt einem halt nicht die Arbeit einer iterativen Implementierungsweise ab (außer natürlich in den Simpelbeispielen, die man in den Büchern immer findet), sondern behindert einen dabei so ein bisschen. Auch habe ich den Eindruck, dass in der C++-Welt mehr Künstlerprogrammierer unterwegs sind.
Und zu dem anderen Punkt: Mit großer Freiheit kommt eben auch große Verantwortung. In C++ hat man halt x-mal so viele Wege, sich in den Fuß zu schießen.Nichtsdestotrotz programmiere ich gern mit C++, aber schließlich war ich schon immer ein komischer Typ
-
Decimad schrieb:
Der ganze Klassenschmu mit all seinen Freiheiten nimmt einem halt nicht die Arbeit einer iterativen Implementierungsweise ab (außer natürlich in den Simpelbeispielen, die man in den Büchern immer findet), sondern behindert einen dabei so ein bisschen.
Klar, wenn man eine Klasse Heapsort baut, ist das einfach schlecht. Aber neulich erst geisterte sie im Forum rum.
Decimad schrieb:
Auch habe ich den Eindruck, dass in der C++-Welt mehr Künstlerprogrammierer unterwegs sind.
Und viel zu viele, die alles übertreiben.
Decimad schrieb:
Und zu dem anderen Punkt: Mit großer Freiheit kommt eben auch große Verantwortung. In C++ hat man halt x-mal so viele Wege, sich in den Fuß zu schießen.
C++ ist halt schärfer.
Decimad schrieb:
Nichtsdestotrotz programmiere ich gern mit C++, aber schließlich war ich schon immer ein komischer Typ.
Ist doch logisch. Kannst auch zur Selbtfesselung greifen und die Pizza mit dem Löffel essen, weil man sich damit nicht in den Finger schneiden kann. Aber sehr schlau wäre das nicht.