Verleitet C++ zum komplizierteren denken?

volkard

+fricky schrieb:

volkard schrieb:

aber ich sehe einen silberstreif am horizont: http://www.c-plusplus.net/forum/viewtopic-var-t-is-245723.html

das ist doch ein typisches beispiel. da will einer ein simples pointer-array haben und wir gleich mit boost, shared_ptrs und vector<blubb> zugetextet.

Aber wie wenig! Nur drei von sieben!!!

das konzept der klassen ist ja so gedacht, dass man eine "schnittstelle" für das programm schafft, so muss man sich in den eigentlichen funktionen nur um den ablauf kümmern. Ich muss allerdings gestehen das ich damit noch nie was funktionierendes hingekriegt habe :-), aber das liegt daran, dass ich eher mit C programmiere.

player4245 schrieb:

das konzept der klassen ist ja so gedacht, dass man eine "schnittstelle" für das programm schafft, so muss man sich in den eigentlichen funktionen nur um den ablauf kümmern. Ich muss allerdings gestehen das ich damit noch nie was funktionierendes hingekriegt habe

OOP usw. sehe ich nicht als ursprung des bösen. eher sowas:

Fusel.Factor schrieb:

...und manchmal kam es mir so vor als wollte ich unbedingt bestimmte Features von C++ benutzen nur weil es sie gibt und sie im späteren Projektverlauf sinnvol sein könnten.

solche 'features' zu nutzen, ohne ihre grenzen und schwächen zu kennen, kann schon ziemlich ins auge gehen. und C++ besteht fast nur aus dingen, die auf den ersten blick toll sind, aber falsch angewendet oder in kombination fehlerquellen auftun, an die man nicht im traum gedacht hat.

btw: http://esr.ibiblio.org/?p=532
(leider kann ich den originaltext nicht finden).

btw2: immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

volkard

+fricky schrieb:

btw2: immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

95% des c++-bashings kommt doch vor dir. sag du uns, wie lange das noch geht.

volkard schrieb:

+fricky schrieb:

volkard schrieb:

aber ich sehe einen silberstreif am horizont: http://www.c-plusplus.net/forum/viewtopic-var-t-is-245723.html

das ist doch ein typisches beispiel. da will einer ein simples pointer-array haben und wir gleich mit boost, shared_ptrs und vector<blubb> zugetextet.

Aber wie wenig! Nur drei von sieben!!!

Warum hat da noch keiner ne template funktion zum erstellen des pointer-arrays hingeschrieben? Mit operator überladung natürlich.

volkard schrieb:

+fricky schrieb:

btw2: immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

95% des c++-bashings kommt doch vor dir. sag du uns, wie lange das noch geht.

ich war nie der thread-starter, hab' auch keine ahnung, wieso in letzter zeit threads wie dieser so häufig auftauchen. früher war's vielleicht einmal pro monat.

komisch schrieb:

Warum hat da noch keiner ne template funktion zum erstellen des pointer-arrays hingeschrieben? Mit operator überladung natürlich.

warts ab, das kommt vielleicht noch.

Fusel.Factor

immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

Das war nicht als Anti C++ Thread gedacht. Ich habe nur gemerkt, dass wenn ich viele Möglichkeiten zu Verfügung habe diese dann auch immer benutzen möchte auch wenn es simpler ginge. Im Grunde interessiert mich wie man nicht übers Ziel hinausschießt.

Fusel.Factor schrieb:

immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

Das war nicht als Anti C++ Thread gedacht. Ich habe nur gemerkt, dass wenn ich viele Möglichkeiten zu Verfügung habe diese dann auch immer benutzen möchte auch wenn es simpler ginge.

ich glaube dir, dass du's ernst meinst, obwohl ich auch glaube dass mindestens die hälfte der c++ flamethreads trollversuche sind (weil sie's vielleicht lustig finden, wie ein gewisser +fricky sich wieder mal zum horst macht).

Fusel.Factor schrieb:

Im Grunde interessiert mich wie man nicht übers Ziel hinausschießt.

was speziell C++ angeht, müssteste vielleicht volkard fragen. ich denke er ist einer der sehr² wenigen leute, die das können.

+fricky schrieb:

immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

btw3: Die C++ Anhänger werden einsichtig.

knivil

immer sehr lange an dem Klassendesign gessen und manchmal kam es mir so vor als wollte ich unbedingt bestimmte Features von C++ benutzen nur weil es sie gibt und sie im späteren Projektverlauf sinnvol sein könnten

a) Klassen ... einfach einige grundlegende Regeln befolgen (siehe gutes FAQ)
b) premature generalisation

Loesung: Disziplin beim Programmieren.

das konzept der klassen ist ja so gedacht, dass man eine "schnittstelle" für das programm schafft ... eher mit C programmiere.

Nein! Vielleicht ist dein mangelndes Verstaendnis auf die geringe Erfahrung in C++/Java/... zurueckzufuehren.

*john 0

+fricky schrieb:

diese fundamentalen konzepte passen aber nicht immer.

Die Kunst ist es gerade viele Konzepte zu kennen, und für die jeweilige Lösung die richtigen Konzepte zu nutzen. Wer bei einer Programmiersprache, die mehr Konzepte direkt unterstützt, unbedingt alle Konzepte nutzen muß, nur weil es möglich ist, macht definitiv etwas falsch. Und da sind wir wieder bei der Qualität der Programmierer. Wer bei einer Multiparadigmensprache nicht die richtigen Konzepte auswählen kann, der ist offensichtlich überfordert, und das Problem ist somit nicht die Sprache sondern das mangelnde Wissen des Programmierers.

+fricky schrieb:

und wenn du eine lösung für umständlich hältst, weil sie in deinem katalog der fundamentalen softwarekonzepte nicht auftaucht, dann kann ich dir auch nicht helfen.

Es ist mal wieder goldig, wie fricky sich seine Wahrheit zurecht biegt. C unterstützt von Haus aus weniger Konzepte direkt als C++. Daher muß man für C++ mehr Wissen haben, um damit überhaupt nur die eingebauten Konzepte zu verstehen. Dazu kommen bei beiden Sprache die unterschiedlichen Konzepte, die die Sprachen nicht unterstützen, und die man somit von Hand durch Code implementieren muß. Ja, ich stelle die These auf, daß Personen, die mit C++ überfordert sind (d.h. nicht das man C++ toll finden müßte, man sollte damit programmieren können), auch mit anderen Sprachen schlechte Programme schreiben.

*john 0

+fricky schrieb:

btw2: immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

Die Ursache ist einfach. Personen scheitern an C++ und da sie nicht in der Lage sind den Fehler bei sich selbst zu suchen muß es natürlich diese absolut schlimme Programmiersprache sein. Und dieses Problem wird nie verschwinden, denn dazu müßte diese Personengruppe ihren Fehler einsehen, und das wird erfahrungsgemäßt nicht eintreten.

*john 0

Fusel.Factor schrieb:

Ich habe nur gemerkt, dass wenn ich viele Möglichkeiten zu Verfügung habe diese dann auch immer benutzen möchte auch wenn es simpler ginge. Im Grunde interessiert mich wie man nicht übers Ziel hinausschießt.

Als erstes solltest Du Dich mehr mit Softwaredesign vertraut machen, und dann die Konzepte die C++ direkt unterstützt sicher beherrschen. Der Rest ist Selbstdisziplin und ein Bekenntnis zu klaren Industriedesign: Form follows function. Und der wichtigste Punkt ist einfach Erfahrung, ohne diese wird es nichts mit guten Design. Je mehr man programmiert desto größer ist die Chance, daß man aus den eigenen Designfehlern lernt, das ist aber wiederum kein Automatismus.

volkard

~john schrieb:

+fricky schrieb:

btw2: immer wenn hier ein anti-C++ thread durch ist, fängt bereits der nächste an. wieso ist das so und wie lange soll das noch gehen?

Die Ursache ist einfach. Personen scheitern an C++ und da sie nicht in der Lage sind den Fehler bei sich selbst zu suchen muß es natürlich diese absolut schlimme Programmiersprache sein. Und dieses Problem wird nie verschwinden, denn dazu müßte diese Personengruppe ihren Fehler einsehen, und das wird erfahrungsgemäßt nicht eintreten.

Nein, das ist es nicht. Die Argumentation ist mir allzu austauschbar.

Personen scheitern an Intercal und da sie nicht in der Lage sind den Fehler bei sich selbst zu suchen muß es natürlich diese absolut schlimme Programmiersprache sein. Und dieses Problem wird nie verschwinden, denn dazu müßte diese Personengruppe ihren Fehler einsehen, und das wird erfahrungsgemäßt nicht eintreten.

Personen scheitern an Java und da sie nicht in der Lage sind den Fehler bei sich selbst zu suchen muß es natürlich diese absolut schlimme Programmiersprache sein. Und dieses Problem wird nie verschwinden, denn dazu müßte diese Personengruppe ihren Fehler einsehen, und das wird erfahrungsgemäßt nicht eintreten.

Personen scheitern an Basic und da sie nicht in der Lage sind den Fehler bei sich selbst zu suchen muß es natürlich diese absolut schlimme Programmiersprache sein. Und dieses Problem wird nie verschwinden, denn dazu müßte diese Personengruppe ihren Fehler einsehen, und das wird erfahrungsgemäßt nicht eintreten.

Personen scheitern an C und da sie nicht in der Lage sind den Fehler bei sich selbst zu suchen muß es natürlich diese absolut schlimme Programmiersprache sein. Und dieses Problem wird nie verschwinden, denn dazu müßte diese Personengruppe ihren Fehler einsehen, und das wird erfahrungsgemäßt nicht eintreten.

und so weiter...

*john 0

volkard schrieb:

Nein, das ist es nicht. Die Argumentation ist mir allzu austauschbar.

Dann begehst Du den Fehler, daß Du hier die Sprachen als gleichwertig (*) einordnest, was eindeutig nicht der Fall ist. Mir geht es hier nicht um die persönlichen Vorlieben, die sind relativ egal, sondern um das Verständnis von Konzepten der Softwaretechnik. Als guter Softwareentwickler muß man in der Lage sein, Programme unabhängig von der Programmiersprache formulieren zu können. Ergo mit jeder beliebigen Programmiersprache sollte man nach einer hinreichenden Einarbeitungszeit in der Lage sein korrekte Programme zu formulieren.

(*) Gleichwertig im Sinne der direkt unterstützten Konzepte

~john schrieb:

C unterstützt von Haus aus weniger Konzepte direkt als C++. Daher muß man für C++ mehr Wissen haben, um damit überhaupt nur die eingebauten Konzepte zu verstehen.

ok, aber es sind weniger die konzepte selbst, die schwierigkeiten bereiten, sondern 'wie' sie realisiert sind. sehr viel wissen und erfahrung ist nötig, um die in die sprache integrierten features korrekt zu verwenden und natürlich den passenden subset von 'features' auszuwählen, der dem problem angemessen ist. das führt dazu, dass man mehr zeit damit verbringt, die programmiersprache richtig zu bedienen, anstatt sich um die eigentliche aufgabenstellung zu kümmern (siehe dazu auch das erste posting des thread-starters). und sowas macht, meiner meinung nach, eine programmiersprache praktisch unbrauchbar. denksportler mögen natürlich ihren spass daran haben.

~john schrieb:

Ja, ich stelle die These auf, daß Personen, die mit C++ überfordert sind ... auch mit anderen Sprachen schlechte Programme schreiben.

deine these ist unhaltbar, weil es in C++ einfach unglaublich viel mehr möglichkeiten gibt, fehler zu machen, als in 90% aller anderen programmiersprachen dieses planeten. <-- meine these.

~john schrieb:

Ergo mit jeder beliebigen Programmiersprache sollte man nach einer hinreichenden Einarbeitungszeit in der Lage sein korrekte Programme zu formulieren.

'hinreichend' für was? nimm einfach die absolute zeit und dann wirste feststellen, dass die sehr unterschiedlich ist. in einigen sprachen kannste nach kurzer korrekte programme schreiben, in anderen dauert es jahre.

Nexus

+fricky schrieb:

das ist doch ein typisches beispiel. da will einer ein simples pointer-array haben und wir gleich mit boost, shared_ptrs und vector<blubb> zugetextet.

Klar, der Anfänger soll auch nicht denken, dass Rumfrickeleien mit Zeiger-Arrays in C++ die übliche Methode sind, um mehrere Werte gemeinsam zu speichern. Ich habe dennoch versucht, ihm diese Thematik zu erklären, damit er Verständnis von den Grundlagen bekommt - dass es bessere Möglichkeiten gibt, habe ich nur als Randbemerkung erwähnt. Übrigens, shared_ptr fände ich hier zum Beispiel nicht nur übertrieben, sondern ein falsch eingesetztes Mittel.

Aber davon abgesehen: std::vector ist um Längen einfacher anzuwenden als ein mit new oder malloc() angelegtes dynamisches Array. Da muss man sich viel weniger überlegen, kann gleich die Funktionalität nutzen. Solche Abstraktionen trifft man in C++ oft an, ein rohes Array bietet in den meisten Fällen keinen Vorteil. Damit du das nicht als Flame gegen C oder so verstehst: Ich will nur zeigen, dass dein Vergleich "simples" Array <-> std::vector nicht unbedingt der geeignetste ist, um die Kompliziertheit von C++-Lösungen aufzuzeigen.

Fusel.Factor schrieb:

Das war nicht als Anti C++ Thread gedacht. Ich habe nur gemerkt, dass wenn ich viele Möglichkeiten zu Verfügung habe diese dann auch immer benutzen möchte auch wenn es simpler ginge. Im Grunde interessiert mich wie man nicht übers Ziel hinausschießt.

Das ist, wie schon angetönt wurde, dein Fehler. Du musst nicht immer alle Möglichkeiten der Sprache ausreizen. Gerade wenn es simpler genauso gut geht, kann das ein Hinweis darauf sein, dass ein komplexeres Sprachmittel für diesen Fall ungeeignet ist. Allerdings sind "simpel" und "genauso gut" oft auch von der Sicht des Programmierers abhängig. Verliert man mit der Einfachheit zum Beispiel Sicherheit?

Es braucht auch einige Erfahrung, um genau abzuschätzen, welche Sprachmittel man wo am besten einsetzt. Die Ansicht, dass ein Nichtbenutzen gewisser Features schade ist, hindert einen definitiv daran. Am ehesten kann man dem Richtig-Einsetzen gerecht werden, indem man sich die ursprüngliche Intention hinter den Sprachmitteln veranschaulicht. Funktionsüberladung? Ich will eine Funktion für unterschiedliche Parametertypen gleich ansprechen. Enum? Eine Aufzählung von festgelegten Zuständen, welche ein Objekt dieses Typs annehmen kann. Und so weiter...

Fusel.Factor, hast du ein konkretes Beispiel, bei dem du in C++ komplizierter programmiert hast als für etwas Gleichwertiges in C? Du darfst ausserdem auch ruhig ab und zu C-Mittel in C++ verwenden, nicht umsonst ist C++ zum grössten Teil abwärtskompatibel.

knivil schrieb:

Nein! Vielleicht ist dein mangelndes Verstaendnis auf die geringe Erfahrung in C++/Java/... zurueckzufuehren.

natürlich ist es so. Die Klasse wird so gemacht, dass ein Objekt der Klasse einen wichtigen bestandteil des programms abdeckt, sodass man längere codebestandteile sinnvoll auslagern kann.

int main()
{
  Anschrift a;

  a.getData();
  a.SaveInFile();
}

so zum beispiel. Ich frage mich bei wem es an verständnis mangelt.

P.S. java lerne ich auch gerade

Nexus schrieb:

+fricky schrieb:

das ist doch ein typisches beispiel. da will einer ein simples pointer-array haben und wir gleich mit boost, shared_ptrs und vector<blubb> zugetextet.

Klar, der Anfänger soll auch nicht denken, dass Rumfrickeleien mit Zeiger-Arrays in C++ die übliche Methode sind, um mehrere Werte gemeinsam zu speichern.

vielleicht gings ihm aber garnicht darum, was in C++ 'übliche methoden' sind. zeiger und arrays und auch arrays von zeigern sind keine rumfrickelei, sondern sehr effiziente, maschinennahe konstrukte, die durch nichts ersetzbar sind (ausser man programmiert gleich in assembler). hätte er gefragt, wie man am besten mit einem boost::tr1::std::shared_ptr::was_weiss_ich umgehen kann, wäre es was anderes gewesen. aber so seid ihr mit euren antworten weit übers ziel hinausgeschossen. leider sind antworten im c++ oft so, dass du übertriebener abstraktion geraten wird. warum eigentlich?