Programiersprache für Anfänger

JustAnotherNoob

3. unabhängige Referenzen (int& a)
4. pass-by-reference bei Argumentübergabe in Funktionsaufrufen
5. Referenzrückgabe von Funktionen

Ahja, das sollten natürlich alles unterschiedliche Zeichen oder Schlüsselwörter sein, wär ja auch viel klarer.

tfa

Bulli schrieb:

Yo, ich kann auch eine Gegenkritik schreiben. Jeder kann eine Kritik schreiben. Muß aber deshalb nichts heißen.

Ach ja? Dann mach mal!

asc

tfa schrieb:

Ach ja? Dann mach mal!

Wie wäre es wenn du einfach das Netz bemühst. Für bislang jede Sprache mit der ich gearbeitet habe gab es im Netz mehrere Kritikseiten.

Immer wieder erstaunlich...

tfa

asc schrieb:

tfa schrieb:

Ach ja? Dann mach mal!

Wie wäre es wenn du einfach das Netz bemühst. Für bislang jede Sprache mit der ich gearbeitet habe gab es im Netz mehrere Kritikseiten.

Warum sollte ich denn? Hier wollte jemand eine Gegenkritik schreiben. Also bitte!
Wenn du mehrere Kritikseiten im Netz kennst, verrat sie uns doch einfach. Aber sie sollten schon ansatzweise so ausführlich, fundiert und kompetent sein wie die Seite, die ich gepostet habe. "Rants" von irgendwelchen Fanboys eignen sich vielleicht für Flamewars, sind aber sonst uninteressant.

Zur Inspiration noch zwei zu C++: 1 2
Zugegebenermaßen weniger fundiert. Die fallen eher in die Sparte Flamewar-Fanboys

Zum Thema find ich dieses Zitat noch passend:

Der Große B.S. schrieb:

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.

Wobei man über "makes it harder" natürlich auch wieder streiten kann...

LordJaxom schrieb:

aber mich würde interessieren, wo Du hier (mindestens zwei! :D) neue Problemchen findest:
printf("%d", "hallo, welt");
// vs.
cout << "hallo, welt";

problemchen 1: 'cout' interpretiert seine eingabe. das kann schief gehen bzw. anders aussehen als gewünscht (hier gabs mal 'nen thread, in dem 'cout' in verbindung mit volatile sich ziemlich seltsam verhielt).
problemchen 1.5: deine printf-zeile enthält einen fehler.
problemchen 2: ein 'cout'-ausdruck, der mehrere objekte formatiert ausgeben soll, wird sehr lang und hässlich, jedenfalls im vergleich zu 'printf'.

Bulli schrieb:

Wo ist also in C++ da das Problem, wenn selbst ein dummer Compiler versteht, was gemeint ist?

mensch Artchi, poste doch wieder unter deinem richtigen namen.

Bulli schrieb:

Wo ist also in C++ da das Problem, wenn selbst ein dummer Compiler versteht, was gemeint ist?

das *ist* das Problem: Was für einen "dummen" Computer oder Compiler gut verständlich ist, ist in der Regel für den Menschen schwer verständlich, und umgekehrt. Man denke an Binärcode.

Abgesehen davon finde ich es auch komisch, daß ich in C++ alle Typen selbst vereinbaren muß, aber sobald ich einen Typ-Fehler begehe, mich der Compiler ermahnt, und sogar hinweist, wie der richtige Typ lauten würde a la "expected: int*, got: int**" - warum typisiert er nicht einfach selber, statt dem Programmierer diese fehlerträchtige Arbeit aufzuhalsen - offenbar kann er es ja ?

Bulli schrieb:

Es ist aber nicht so schwer zu lernen, wie es hier einige verkaufen wollen.

das hängt vom Background ab. Als ich C lernte, konnte ich schon mehrere Assemblersprachen, da war C also kein Problem.

Mir scheint, daß die Gewöhnung an logisches Denken ein Hindernis beim Lernen von C++ ist. C++ ist teilweise nicht logisch, es gibt keine eindeutige Zuordnung zwischen Syntax-Elementen und Konzepten, viele Symbole und Schlüsselwörter sind mehrfach überladen mit Bedeutungen, die teilweise nichts miteinander zu tun haben.

asc schrieb:

Der Name ist Programm... Wenn du C++ als " Unlogisch und kompliziert" betrachtest, gilt dies erst recht für C.

http://www.artima.com/cppsource/safebool.html
Kannst du mal schnell das mit dem safe bool idiom und dem Rückgabewert bool oder void* erklären, ich hab das noch nicht ganz verstanden. Sollte doch auch einfach, logisch und unkompliziert ohne 3 Seiten Text gehen, da C++. Und wie war das mit dem assign operator und exception safety?

kajott89

naja, da jetzt meine anfängliche frage zur diskussion über c bzw. c++ wurde kann das thema auch geschlossen werden weil es keinen sinn mehr hat. ich werde mir jetzt einfach mal 2-3 bücher über c++ holen und bin gerade dabei mir phyton anzugucken. ich hoffe es klappt aber erwarte auch nicht von mir selbst, das ich in 1 monat programmieren kann. trotzdem vieln dank für eure beiträge und vll. bis bald mal wieder...

asc

isklar schrieb:

asc schrieb:

Der Name ist Programm... Wenn du C++ als " Unlogisch und kompliziert" betrachtest, gilt dies erst recht für C.

http://www.artima.com/cppsource/safebool.html
Kannst du mal schnell das mit dem safe bool idiom und dem Rückgabewert bool oder void* erklären, ich hab das noch nicht ganz verstanden. Sollte doch auch einfach, logisch und unkompliziert ohne 3 Seiten Text gehen, da C++. Und wie war das mit dem assign operator und exception safety?

Interessantes Problem, aber es erklärt nich nicht warum C weniger Kompliziert ist als C++, da es die gleichen Probleme hat, weniger Typsicherheit besitzt...

Und nur das zweifel ich hier an. Ich habe niemals gesagt das C++ unkompliziert ist, aber mehr als C (Alleine die vielen Zusatzbedingungen die man in der C-Bibliothek wissen muss um Funktionen aufzurufen, ohne in Laufzeitfehler zu rennen, die in der C++ Bibliothek zum Großteil dank Typsicherheit, Klassen etc. bereits in der Compilezeit aufgedeckt werden können).

Ich lobe weder C++ in den Himmel, noch ziehe ich C die Existenzberechtigung ab. Nur von der Komplexität sind beide ähnlich. Und beide ebenso schwer für ein Anfänger zu lernen.

fricky schrieb:

problemchen 1: 'cout' interpretiert seine eingabe. das kann schief gehen bzw. anders aussehen als gewünscht (hier gabs mal 'nen thread, in dem 'cout' in verbindung mit volatile sich ziemlich seltsam verhielt).
problemchen 1.5: deine printf-zeile enthält einen fehler.
problemchen 2: ein 'cout'-ausdruck, der mehrere objekte formatiert ausgeben soll, wird sehr lang und hässlich, jedenfalls im vergleich zu 'printf'.

Zu 1 & 1.5: cout interpretiert seine Aussage wenigstens typsicher. Der Fehler in der C-Zeile soll wohl nur auf die Leichtigkeit hinweisen wie man in C einen Laufzeitfehler hinbekommt. Und Anfänger werden mit volatile (Das ich übrigens bislang nur sehr selten -eher nie- in Anwendungsprogrammen begegnet bin) wohl nur wenig bis garnicht in Kontakt kommen.
Zu 2: Wenn ich dafür die Fehler zur Compilezeit statt zur Laufzeit geliefert bekomme, ist es zumindestens mir das wert.

u-ser_l schrieb:

Mir scheint, daß die Gewöhnung an logisches Denken ein Hindernis beim Lernen von C++ ist.

Das mag dir so gehen, ich finde C++ in vielen Bereichen logischer und vor allem auch sicherer als seine C-Altlasten...

cu André

LordJaxom

~fricky schrieb:

problemchen 1.5: deine printf-zeile enthält einen fehler.

Ja, mit voller Absicht, um direkt eines der Probleme von printf aufzuzeigen.

problemchen 2: ein 'cout'-ausdruck, der mehrere objekte formatiert ausgeben soll, wird sehr lang und hässlich, jedenfalls im vergleich zu 'printf'.

Der Formatstring von printf ist hässlich, jedenfalls im Vergleich zu cout. Oder anders: Geschmacksfragen sollten wir entweder aussen vor lassen oder gegeneinander aufwiegen :p

asc schrieb:

ich finde C++ in vielen Bereichen logischer und vor allem auch sicherer als seine C-Altlasten...

ich finde C++ auch angenehmer als C, vor allem wegen Strings, STL-Containern und wegen der Datenkapselung durch das OO-Modell.

Logischer finde ich C++ deswegen aber nicht - eher unlogischer. Hatte man bei C nur eine Art von Referenzen (nämlich Zeiger), so hat man jetzt zwei. Und schon hat das '&'-Zeichen drei weitere Bedeutungen, zusätzlich zu den zweien, die es schon in C hat. Der Programmierer muß in C++ einfach zu viel Verwaltungskram selbst machen, den auch der Compiler erledigen könnte: Prototypen, Typisierung, Garbage Collection (klar - geht nicht, wenn man Zeiger zuläßt), ...

Die Seitenzahl der Referenzbücher spricht da eine deutliche Sprache - je mehr erklärt werden muß, umso weniger intutiv muß eine Sprache wohl sein.

asc schrieb:

Zu 1 & 1.5: cout interpretiert seine Aussage wenigstens typsicher. Der Fehler in der C-Zeile soll wohl nur auf die Leichtigkeit hinweisen wie man in C einen Laufzeitfehler hinbekommt. Und Anfänger werden mit volatile (Das ich übrigens bislang nur sehr selten -eher nie- in Anwendungsprogrammen begegnet bin) wohl nur wenig bis garnicht in Kontakt kommen.
Zu 2: Wenn ich dafür die Fehler zur Compilezeit statt zur Laufzeit geliefert bekomme, ist es zumindestens mir das wert.

Warnung: format »%d« erwartet Typ »int«, aber Argument 2 hat Typ »char *«

...

u_ser-l schrieb:

Und schon hat das '&'-Zeichen drei weitere Bedeutungen, zusätzlich zu den zweien, die es schon in C hat.

Zähl mir doch bitte mal alle Mehrdeutigkeiten von static in C auf...

asc

u_ser-l schrieb:

ich finde C++ auch angenehmer als C, vor allem wegen Strings, STL-Containern und wegen der Datenkapselung durch das OO-Modell.

Warum diskutieren wir dann überhaupt?

u_ser-l schrieb:

Logischer finde ich C++ deswegen aber nicht - eher unlogischer. Hatte man bei C nur eine Art von Referenzen (nämlich Zeiger), so hat man jetzt zwei.

Die aber unterschiedliche Bedeutung haben, und zusätzlich je nach Verwendung vom Compiler auch anders umgesetzt werden können (Referenzen können intern Zeiger sein, können aber ebenso gänzlich wegoptimiert werden).

u_ser-l schrieb:

Und schon hat das '&'-Zeichen drei weitere Bedeutungen, zusätzlich zu den zweien, die es schon in C hat.

Es ist klar das wenn man einerseits weitgehen C-Kompatibel sein will, anderseits aber neue Möglichkeiten eröffnen will, eine Sprache mehr Befehle oder Zeichen verwenden muss (bzw. Zeichen auch noch mehrere Kontextspezifische Bedeutungen gibt).

Nichts desto trotz spart man sich in C++, sofern man auch wirklich C++ und nicht C Programmiert, viele Fallstricke aus C. Daher sehe ich beides von der Komplexität gleich an. Ansonsten müsste man sagen das C#/Java komplexer als C/C++ ist, weil der Bibliotheksumfang größer ist.

Man kommt als Anfänger immer nur mit einem Teil in Berührung. Und nicht nur als Anfänger. Ich frage mich wieviele C++ Programmierer (prozentual) jemals direkt mit der Templatemetaprogrammierung zu tun haben. Ich tippe eher wieder auf die 90:10 Regel (90 Prozent werden es niemals direkt verwenden, indirekt über Bibliotheken vielleicht).

u_ser-l schrieb:

Der Programmierer muß in C++ einfach zu viel Verwaltungskram selbst machen, den auch der Compiler erledigen könnte: Prototypen, Typisierung, Garbage Collection (klar - geht nicht, wenn man Zeiger zuläßt), ...

Und wo bitte ist da C besser (Ich habe niemals gesagt das C++ besser, leichter... als andere Sprachen ist, verwehre mich nur dagegen das C weniger Komplex sein soll. Für einen Anfänger eher nicht.

u_ser-l schrieb:

Die Seitenzahl der Referenzbücher spricht da eine deutliche Sprache - je mehr erklärt werden muß, umso weniger intutiv muß eine Sprache wohl sein.

Dann sie bitte auch meine (Anwendungsfallspezifische) Empfehlung an. Siehst du dort an vielen Stellen C++?

cu André

asc

Tim schrieb:

asc schrieb:

...Zu 2: Wenn ich dafür die Fehler zur Compilezeit statt zur Laufzeit geliefert bekomme, ist es zumindestens mir das wert.
Warnung: format »%d« erwartet Typ »int«, aber Argument 2 hat Typ »char *«
...

Das klappt aber nur wenn der C-Compiler komplexes Parsing betreibt, und das machen beileibe nicht nicht alle. Ich weiß noch wieviele Laufzeitfehle ich wegen falscher Benutzung von C-Funktionen in Programmen suchen durfte (und nein, die C-Funktionen habe nicht ich eingebaut, ich durfte sie nur ausbaden).

cu André

asc schrieb:

Das klappt aber nur wenn der C-Compiler komplexes Parsing betreibt, und das machen beileibe nicht nicht alle.

Sollen wir darüber diskutieren wieviele C++ Compiler nicht komplett z.B. Templates umsetzen?
Ich wollte lediglich andeuten, dass die Beispiele die hier gegeben werden nicht sonderlich sinnvoll sind. Aber durchaus passend zur Diskussion...

Tim schrieb:

Zähl mir doch bitte mal alle Mehrdeutigkeiten von static in C auf...

wieso? Hast Du kein C++ Buch ?

1. static Variable innerhalb einer Funktion
2. static globale Variable innerhalb ihrer Datei
3. static Deklaration in Klassen, vor Variablen und Funktionen

3 verschiedene Konzepte teilen sich 1 Schlüsselwort. Das ist nicht logisch und dient nicht der Erfaßbarkeit der Sprache für Anfänger.

Bashar

Ohne dass dazu ausreichend relevante Aussagen von Anfängern vorliegen ist das einfach eine unbelegte Behauptung.

JustAnotherNoob

ich verstehe auch nicht, warum das Hinderlich sein soll. Ich kann zwischen den Konzepten sogar Paralellen erkennen. Das in Funktionen und das in Klassen ist für ihren Anwendungsbereich im Prinzip sogar das gleiche. Zumindest aus rein logischer Sicht. Die Konzepte die du nennst, sind wieder die technische Sicht, die du selbst kritisierst.

u_ser-l schrieb:

Tim schrieb:

Zähl mir doch bitte mal alle Mehrdeutigkeiten von static in C auf...

wieso? Hast Du kein C++ Buch ?

Ich habe in der Tat kein C++-Buch. Ich habe auch kein C-Buch, aber das war trotzdem nicht der Grund warum ich explizit nach static in C fragte.
Kurzum, C hat ebenso Mehrfachbelegung von Schlüsselwörtern/Operatoren. Teilweise sogar richtig unsinnige.