Verleitet C++ zum komplizierteren denken?

[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

[+fricky]

~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.

[player4245]

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

[+fricky]

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?

[abc.w]

+fricky schrieb:

leider sind antworten im c++ oft so, dass du übertriebener abstraktion geraten wird. warum eigentlich?

Weil C++ zum komplizierteren Denken verleitet?

[Badestrand]

+fricky schrieb:

vielleicht gings ihm aber garnicht darum, was in C++ 'übliche methoden' sind.

Man sieht aber immer wieder wie sich Anfänger das Leben schwer machen, einfach weil sie vector, shared_pointer usw nicht kennen.

[Nexus]

+fricky schrieb:

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).

Ja, vielleicht. Da dieser Teil der Anfänger in C++ allerdings sehr gering ist, halte ich es für gerechtfertigt, nicht von einem Bytemanipulierer auszugehen. Und sich durch maschinennahe Sprachmittel unnötige Mühen aufzubürden, wo ein High-Level-Konstrukt viel besser geeignet ist, sehe ich als Frickelei an. Für sehr viele Fälle sind die Zeiger und Arrays eben schon ersetzbar.

+fricky schrieb:

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?

Leider kennt man als Anfänger weder Boost noch std::vector . Viele C++-Einsteigerbücher sind zudem schlecht, sodass die Wahrscheinlichkeit gar nicht mal so klein ist, dass man von wichtigen Teile der Standardbibliothek nie gehört hat. Wieso sollten wir ihm keine Methoden vorschlagen, die er noch nicht kennt? Meine Erfahrung im C++-Forum zeigt, dass es schon oft Leute gab, denen so ein Hinweis enorm geholfen hat.

[dffffffffffffffff]

Ich wette, dass viele C++ Neulinge/Anfänger zur STL/boost/whatever greifen, nur damit sie nicht durch andere C++ler gebasht werden ala "du noob, wieso nimmst du char* du C-frickler.".

Scheint wohl daher zu kommen, dass C Elemente in C++ kreisen verpöhnt sind.

Einfaches Beispiel: printf().

Meiner Meinung nach ist printf, sprintf, fprintf [...] um einiges effizienter sowie einfacher in der Handhabung als cout und die ganzen streams.

Bloß doof, dass man gleich angeschnauzt wird, wenn man ein printf in C++ code einbaut. Dabei sind format strings so komfortabel. Klar, wenn man nicht aufpasst, kann man mit dem format-string böse scheisse anstellen. Aber mit den c++ streams bekommt man das ganz gewiss auch hin. Da bin ich mir sicher.

Das Argument "format strings sind kryptisch" kann man nicht gelten lassen. Es dauert keine 5 Minuten bis man die formatstrings es voll drauf hat.

Insbesondere wenn man sauber tabellarisch etwas ausgeben möchte, sind printf & co perfekt. Mit cout kanns schon etwas hässlich werden, ganz zu schweigen von dem "<<" Inferno.

Die STL hat zwar die Absicht Arbeit abzunehmen - das tut sie auch - wenn man denn weiß was genau hinter den Kullissen geschieht. Wenn man das weniger weis, dann wird die Fehlersuche zum Abenteuerlabyrinth.

~john schrieb:

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.

Vielleicht solltest du hier genauer erläutern warum die Leute den Fehler bei sich selber suchen sollen und warum sie es einsehen sollen. Es ist doch die Sprache c++ die gerade für Anfänger fehleranfällig ist.

Es ist doch so: Leute versuchen sich in C++, tappen in jedes vorhandene Fettnäpfchen (von denen C++ genug bereitstellt), kommen kaum voran. Zufällig/aus Frust versuchen sie eine modernere Sprache und *ding*, schau an schau an, auf einmal machen die Fortschritte und das Ergebnis kann sich bereits nach kurzer Zeit sehen lassen. Vielleicht solltest du nun diesen Leuten erklären warum sie den Fehler bei sich selbst suchen sollen, wenn es denn auch einfacher geht. Denn diese Leute haben gemerkt, dass segfaults nicht sein müssen. Diese Leute haben gemerkt, dass aufwändige debugging sessions sich in Grenzen halten können. Diese Leute haben gemerkt, dass es mit weniger Aufwand auch schneller voran gehen kann.

Setzt man das Resultat an erster Stelle in der Prioritätenhierarchie, so wird die Rechtfertigung des nicht zu vernachlässigbaren Mehraufwands seitens C++ schwierig.

Achja: "moderne Sprachen sind was für Weicheier/Faule" ist keine Rechtfertigung. Das ist Stursinn.

[DieFaustAufsAuge]

Mit dem neuen C++ Standard bist 5 zählen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-245794-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
Bekommt man es noch komplizierter hin?

[+fricky]

Nexus schrieb:

+fricky schrieb:

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).

Ja, vielleicht. Da dieser Teil der Anfänger in C++ allerdings sehr gering ist, halte ich es für gerechtfertigt, nicht von einem Bytemanipulierer auszugehen. Und sich durch maschinennahe Sprachmittel unnötige Mühen aufzubürden, wo ein High-Level-Konstrukt viel besser geeignet ist, sehe ich als Frickelei an. Für sehr viele Fälle sind die Zeiger und Arrays eben schon ersetzbar.

naja, aber dadurch, dass der durchschnittliche C++ benutzer die lowlevel-fähigkeit seiner sprache meidet, wie der teufel das weihwasser, gibts viele c++ programmierer, die lowlevel-mässig keinerlei bezug haben. ich selbst hab schon einige male erlebt, dass leute in schlimme bedrängnis geraten sind, weil sie in C++ so programmiert haben, wie ihr es in eurem forum propagiert. der schlechte ruf von c++ im embedded bereich kommt fast nur daher, dass highlevel-programmierung und abstraktion bis zum erbrechen gepflegt werden, während alle lowlevel-möglichkeiten als 'grundsätzlich schlecht und fehleranfällig' und als 'c-altlasten' verteufelt werden.

DieFaustAufsAuge schrieb:

Mit dem neuen C++ Standard bist 5 zählen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-245794-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
Bekommt man es noch komplizierter hin?

*hahaha*, ja der ist lustig. allein das hier:

Array<int>()-1-2-3-4-5

absolut intuitiv und lesbar. dagegen verblassen alle meine lästereien über operatorüberladung.

[Badestrand]

+fricky schrieb:

dagegen verblassen alle meine lästereien über operatorüberladung.

Das stimmt, zum Glück kann's jetzt aber auch schon Kommas

[Blue-Tiger]

Also ich erwisch mich hin & wieder dabei, dass ich statt eines

for (int i = 0; i < v.size(); ++i)
    cout << v[i] << '\n';

erstmal ueberlege, ob das nicht schoener mit std::copy und output-iteratoren werden wuerde.

[abc.w]

+fricky schrieb:

*hahaha*, ja der ist lustig. allein das hier:

Array<int>()-1-2-3-4-5

absolut intuitiv und lesbar. dagegen verblassen alle meine lästereien über operatorüberladung.

Ja, total intuitiv, ein Array von negativen Zahlen von -1 bis -5?

[oooooooooooooooooooo]

Array<int>()-1-2-3-4-5

Ist das die moderne Form von <°)))><< ??