Verleitet C++ zum komplizierteren denken?

Ad aCTa

Naja, die Stdlib von C++ würde ich trotzdem noch mit Vorsicht genießen, gerade bei Anfängern.
Der Anfänger kann nicht verstehen, wieso er lieber vector statt eigenen Klassen verwenden soll? Dann sollte er erst verstehen, wieso. Es hat mir mehr gebracht, eine eigene doppel verkettete Liste zu bauen und dann zu erfahren, dass es die STL gibt als umgekehrt. Als C++-Programmierer sollte man mit allen Wassern gewaschen sein, und es ist doch besser, etwas im C-Sumpf zu beginnen, Probleme von C zu zeigen und dann im Laufe der Lernphase Lösungsvorschläge von Seiten C++ zu servieren á la STL.

volkard schrieb:

+fricky schrieb:

ach du schreck, das haste doch bestimmt mit __LINE__ gemacht, oder?

#define und files, die sich selber inkludieren.

dann bist du vielleicht identisch mit diesem typ hier: http://www.ioccc.org/2004/vik2.hint

abc.w

+fricky schrieb:

dann bist du vielleicht identisch mit diesem typ hier: http://www.ioccc.org/2004/vik2.hint

Abgefahrene Messungen:

(*) Before cpp crashed.

~john schrieb:

dffffffffffffffff schrieb:

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

Es mag vielleicht einfacher auf den ersten Blick sein, aber es ist nicht typsicher! Während es bei printf nur ärgerlich ist wird es bei scanf richtig gefährlich. Der nächste Exploit steht schon in der Tür.

wenn du ein bisschen paranoid bist (oder auch nicht), dann lässte 'nen statischen code-checker wie lint bzw. splint drüberlaufen. der findet mehr potentielle fehler als jeder c++-compiler mit seiner angeblich so tollen typsicherheit.

abc.w schrieb:

Abgefahrene Messungen:

(*) Before cpp crashed.

unter c++ codern ist es gang und gäbe, dass der compiler bei irgendwelchen templates sich 'nen wolf rechnet und schliesslich abkackt.

volkard

+fricky schrieb:

unter c++ codern ist es gang und gäbe, dass der compiler bei irgendwelchen templates sich 'nen wolf rechnet und schliesslich abkackt.

Falsch.

Ad aCTa

Wie soll denn C++ rechnen, während der Compiler die Templates auflöst? Runtime != Compiletime!

Der Grund warum Programmierer gerne eine komplexe Lösung bevorzugen ist ganz simpel: sie wollen sich selbst bei der Aufgabe fordern.
Für viele ist das Programmieren mehr als nur eine Tätigkeit um seine Brötchen zu verdienen und daher ist der Drang da sich immer wieder an neue Grenzen zu bringen.

byto

Oder sie wollen sich im Projekt unsterblich machen. Ist nüchtern betrachtet ne legitime Angelegenheit.

Ad aCTa

Sie wollen höchstens angeben und prahlen...

Was bringts, wenn sie komplizierte closed-source-apps bauen?
Wem bringts was, wenn sie unnütz-komplizierte open-source-apps bauen?

Alles sollte so einfach wie möglich gemacht sein, aber nicht einfacher.
-Einstein

Das Zitat ist auf C++ geradezu zugeschnitten.

Ad aCTa schrieb:

Sie wollen höchstens angeben und prahlen...

Was bringts, wenn sie komplizierte closed-source-apps bauen?
Wem bringts was, wenn sie unnütz-komplizierte open-source-apps bauen?

Es bringt ihnen selbst etwas, weil sie sich dabei fordern.

Nexus

+fricky schrieb:

naja, aber dann frage ich mich warum bei einigen nur grütze rauskommt. [...] ein mitbewerber hat ähnliches in C++ versucht, aber bei ihm waren die 256K ROM seines controllers schon mit tcp/ip, ethernet-treiber, webserber und 'ner XML-library voll. die haben C++ so benutzt, wie 99% aller c++ progger, nämlich auf 'schönes C++', templates, OOP+vererbung, C++-exceptions und die STL gesetzt.

Aha, und dieser Fall lässt dich auf den durchschnittlichen C++-Programmierer schliessen? C++ ist nicht die einzige Sprache, in der man schlecht programmieren kann (aber da geht es besonders gut, ich weiss...).

Einige Features haben zudem ihren Preis, für gewisse Dinge ist C ganz klar geeigneter. Aber darum gehts nicht. Tatsache ist, dass man in C++ praktisch genauso Low-Level programmieren kann, wenn man es benötigt. Dass das meistens nicht der Fall ist, erklärt die hohe Abstraktionsebene.

+fricky schrieb:

wenn du ein bisschen paranoid bist (oder auch nicht), dann lässte 'nen statischen code-checker wie lint bzw. splint drüberlaufen. der findet mehr potentielle fehler als jeder c++-compiler mit seiner angeblich so tollen typsicherheit.

Wieso nicht gleich eingebaute Mechanismen verwenden, wenn einem das C++ von sich aus bietet? Und welcher Teil der Typsicherheit passt dir nicht?

+fricky schrieb:

unter c++ codern ist es gang und gäbe, dass der compiler bei irgendwelchen templates sich 'nen wolf rechnet und schliesslich abkackt.

Nicht mal Template-Metaprogrammierung ist so gang und gäbe, wie du vielleicht annimmst. Es kann zwar manchmal nützlich und interessant sein, aber viele C++-Programmierer kennen sich damit gar nicht gross aus. Mit Templates schon, aber nicht mit Metaprogrammierung. Und selbst da passiert es nicht so schnell, dass ein Compiler abstürzt.

Nexus

Ad aCTa schrieb:

Sie wollen höchstens angeben und prahlen...

Du kannst also nicht nachvollziehen, dass es tatsächlich Programmierer gibt, die Freude am Experimentieren und Kennenlernen neuer Möglichkeiten haben?

Ad aCTa

> Es bringt ihnen selbst etwas, weil sie sich dabei fordern.

Omg, und die sollen sich bei der Softwareherstellung fördern? Das gehört doch in den C++ Kindergarten und in keine Release-Software!!!

> Du kannst also nicht nachvollziehen, dass es tatsächlich Programmierer gibt, die Freude am Experimentieren und Kennenlernen neuer Möglichkeiten haben?

Im Projekt wird herumexperimentiert, es muss so sein. Doch meistens sind die einfachste Möglichkeiten am Ende die, die man im Code finden sollte. "Freude am Experimentieren" und Spielereien sind m.E. in der Software-Herstellung völlig fehl am Platze, in der Software heißt es testen testen testen, was sich bewährt und was performant ist und NICHT, ob C++ sowas kann.

Nexus

Ad aCTa schrieb:

Im Projekt wird herumexperimentiert, es muss so sein. Doch meistens sind die einfachste Möglichkeiten am Ende die, die man im Code finden sollte. "Freude am Experimentieren" und Spielereien sind m.E. in der Software-Herstellung völlig fehl am Platze, in der Software heißt es testen testen testen, was sich bewährt und was performant ist und NICHT, ob C++ sowas kann.

Okay, dann hab ich dich wohl falsch verstanden. Ich meinte eher Fälle wie der verlinkte Thread hier oder andere Diskussionen, die es im C++-Forum ab und zu gibt. Oft geht es dabei gar nicht um den produktiven Einsatz.

Fusel.Factor schrieb:

Hallo lieber Forum,

bis vor kurzem habe ich nur für Desktop-Pcs entwickelt, aber jetzt habe ich hobbymäßig angefangen für Mikrocontroller zu programmieren. Dafür habe ich mir einen AVR Controller für paar Euro gekauft und mit C kann ich den auch wunderbar programmieren. Nun habe ich gemerkt, dass ich in C irgendwie alles viel simpler bzw. direkter programmiere. Bei allen meinen früheren Projekten habe ich 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. Geht es nur mir so oder hatten auch welche von euch dieses "Problem". Ich befürchte ich bin einfach nicht in der Lage den Spruch "Sense and simplicity" umzusetzen.

Da hast du sehr berechtigte Dinge geschrieben, die schon sehr vielen vor dir ebenfalls aufgefallen sind.

Ich versuche das Mal möglichst objektiv zu erklären:

Mit C++ ist das nämlich so eine Sache.

Das Hauptproblem ist sicherlich folgendes:

C++ ist ein Haufen Müll!

Der größte Kothaufen den die Welt gesehen hat...

bis dann Perl kam...

welches wiederum von Java als größter Kothaufen abgelöst wurde.

Also um es jetzt etwas subjektiver zu sagen:

C++ taugt nichtmal auf dem PC. Und erst recht nicht für Mikrocontroller.

Für AVRs gibt es zwei Möglichkeiten:

Assembler oder C!

Echte Programmierer nehmen natürlich Hex.

Aber ich empfehle dir als Einstieg C. Der Vorteil von Assembler ist natürlich, dass du den Kontroller besser kennen lernst, da direkter. Nachteil: Aufwendiger.

Dürfte ich anfragen was du so als Einsteigerset zur AVR-Programmierung nutzt?

Das STK500? Oder das Pollin-Board plus AVR-Programmer?

Oder machst du alles von grundauf selbst?

Fängst mit ATMega8 an oder?

Und falls du es nicht sowieso schon hast: Vergiss nicht die ganzen Kleinteile und extras, wie Taster, Kondensator, ICs, Trans, LEDs, würde auch gleich zu Anfang bereits ein einfaches Dot-Matrix LCD empfehlen.

Also nochmal kurz: Vergiss den Mist wie C++ und Bascom.
C oder Assembler ist angesagt!

C++, Java, Schäuble, Merkel, Windoof Vistarsch und Bill Gates könnte man im Grunde in einen Sack werfen, zubinden und mit nem Knüppel druf: Es würde immer den richtigen treffen.

knivil

player4245 schrieb:

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.

Einen wichtigen Bestandteil des Programms ungleich Interface fuer ein Programm. Objekte sind dazu da, Daten und dessen Funktionen zusammen zuhalten und Invarianten des Objekts zu garantieren. Kurz: Klassen/Objekte sind mehr als nur Interfaces. Interfaces kann ich auch wunderbar in C schreiben.

volkard

knivil schrieb:

Einen wichtigen Bestandteil des Programms ungleich Interface fuer ein Programm. Objekte sind dazu da, Daten und dessen Funktionen zusammen zuhalten und Invarianten des Objekts zu garantieren. Kurz: Klassen/Objekte sind mehr als nur Interfaces. Interfaces kann ich auch wunderbar in C schreiben.

Klassen/Objekte auch.

byto

knivil schrieb:

Objekte sind dazu da, [...] Invarianten des Objekts zu garantieren.

Was meinst du damit genau?

volkard

byto schrieb:

knivil schrieb:

Objekte sind dazu da, [...] Invarianten des Objekts zu garantieren.

Was meinst du damit genau?

http://de.wikipedia.org/wiki/Invariante_(Informatik)
Es gibt Personen, die auch Invarianten von Objekten verfolgen, zum Beispiel muß innerhalb des vectors immer gelten, daß empty()==(begin()==end()) oder in einem Ringknoten immer left->right==right->left && left->right==this. nicht immer, nur vor am beginn und ende jeder nichtprivaten methode.
Es gibt Personen, die das zum Zweck der Klasse erheben.
Also ich bin recht sicher, daß das damit gemeint ist. Aber wozu? Ein Ringknoten ist doch nicht dazu da, die Ringbedingung zu garantieren.

Nexus schrieb:

Tatsache ist, dass man in C++ praktisch genauso Low-Level programmieren kann, wenn man es benötigt.

das ist mir klar, aber trotzdem wehren sich c++ user mit händen und füßen gegen lowlevel-programmierung. sie peilen lieber eine abstrakte lösung an, die beliebig kompliziert werden kann. ich schätze viele c++ programmierer (natürlich nicht alle) handeln so. die frage ist nur 'warum'?

Nexus schrieb:

Und welcher Teil der Typsicherheit passt dir nicht?

z.b. sowas:

class C
{
  public: C (int i){};
};

void func (const C &o){}

int main()
{
 func(3);  // huch? ein integer? soll doch 'const C&' sein???
}

^^das sowas compiled (jedenfalls frisst es der mingw ohne warnung), finde ich doof. ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?

Nexus schrieb:

+fricky schrieb:

unter c++ codern ist es gang und gäbe, dass der compiler bei irgendwelchen templates sich 'nen wolf rechnet und schliesslich abkackt.

Nicht mal Template-Metaprogrammierung ist so gang und gäbe, wie du vielleicht annimmst. Es kann zwar manchmal nützlich und interessant sein, aber viele C++-Programmierer kennen sich damit gar nicht gross aus. Mit Templates schon, aber nicht mit Metaprogrammierung. Und selbst da passiert es nicht so schnell, dass ein Compiler abstürzt.

ist mir bei irgendwelchen experimenten mit C++ schon mehr als einmal passiert, obwohl ich wirklich sehr selten einen C++ compiler anwerfe.