"C++ is the dumpest language in the world"

[Shade Of Mine]

~fricky schrieb:

mag sein, dass es parallelen zu anderen sprachen gibt, die auch sowas wie 'global friend functions' kennen, aber das ist eher zufall.

Ich sehe das ganze eben abstrakter.
Das Buch ist keine Anleitung um gute Python Programme zu schreiben. Aber du wenn du das alles verstanden hast was gesagt wurde, dann entwickelst du bessere Python, Ruby,... programme.

Solche Bücher müssen auf konkrete Sprache bezogen geschrieben werden um die Denkweisen darlegen zu können.

Sprachen sind nur Werkzeuge, dumme Werkzeuge um genau zu sein. Die wirkliche Arbeit macht dein Geist.

Aber du hast die Aussage ja auch nicht verstanden - es geht nicht um globale Funktionen, sondern um den Ansatz wie man generische Algorithmen schreibt. Das betrifft in gewisser Weise alle Sprachen die diese möglichkeit bieten und man versteht dann auch warum dass in Java so schwer ist und wo das Von-Interfaces-Erben-Modell seine schwachstellen hat.

Es ist aber keine Anleitung die du 1:1 befolgen kannst, es geht darum den Horizont zu erweitern. Wenn das Buch über Ruby oder Fortran wäre (2 Sprachen die ich nicht nutze) würde ich mir das Buch dennoch kaufen.

Aber es ist eben abstrakt und das ist das Problem. Die meisten Leute wollen keine Horizont Erweiterung sondern Anleitungen...

PS:
die erwartungshaltung ist natürlich bei dem titel eine andere als das buch im endeffekt hergibt. aber dennoch muss man kein c++ programmierer sein um daraus etwas zu gewinnen.

[~fricky]

Shade Of Mine schrieb:

Solche Bücher müssen auf konkrete Sprache bezogen geschrieben werden um die Denkweisen darlegen zu können.

dagegen hat ja auch keiner was. stepanovs buch kann für c++ programmierer sehr nützlich sein. für alle anderen leider weniger, weil die wenigen, grundlegenden konzepte, die darin vorkommen, zu sehr mit c++ 'verseucht' sind.

Shade Of Mine schrieb:

Aber es ist eben abstrakt und das ist das Problem.

stepanovs buch ist eben nicht abstrakt, aber das ist auch kein problem. wenn ich was über kugeln wissen will, dann kaufe ich mir auch keine orangen und denke mir alle eigenschaften weg, sondern hole mir ein geometrie-lehrbuch oder sowas.

[C++-Progger]

Ich lese gerade die Notes on Programming und könnt ihr mir sagen, was an folgendem Code falsch ist?

One of the omissions that I made in STL was the omission of relational operators on iterators. STL requires them only for random access iterators and only when they point to the same container. It makes it impossible to have a set of iterators into a list. Yes, it is impossible to assure the topological ordering of such iterators – the property that if a < b then ++a < ++b or, in other words, that the ordering imposed by < coincides with the traversal ordering – but such a property is unneeded for sorting. The reason that I decided not to provide them was that I wanted to prevent people writing something like
for (std::list<int>::iterator i = mylist.begin();
i < mylist.end(); ++i) sum += *i;

[volkard]

[quote="C++-Progger"]Ich lese gerade die Notes on Programming und könnt ihr mir sagen, was an folgendem Code falsch ist?[quote]
es wäre eklig langsam.
iteratoren in listen müßten für nen op< immer die liste ablaufen. das ist unnötig. die schleife klappt auch super mit !=.

[C++-Progger]

[quote="volkard"][quote="C++-Progger"]Ich lese gerade die Notes on Programming und könnt ihr mir sagen, was an folgendem Code falsch ist?

es wäre eklig langsam.
iteratoren in listen müßten für nen op< immer die liste ablaufen. das ist unnötig. die schleife klappt auch super mit !=.

Danke, für den Hinweis, das ist mir beim Starren auf den Codeschnipsel gar nicht aufgefallen und ich wunderte mich noch, da ich so etwas ähnliches schon so oft geschrieben habe

[asdfghjklö]

C++-Progger schrieb:

Ich lese gerade die Notes on Programming und könnt ihr mir sagen, was an folgendem Code falsch ist?

...
for (std::list<int>::iterator i = mylist.begin();
i < mylist.end(); ++i) sum += *i;

Hm. Ist es vielleicht das?

for (std::list<int>::iterator i = mylist.begin();
i != mylist.end(); ++i) sum += *i;

!= statt <

[rüdiger]

@~fricky
Das Buch von ihm ist abstrakter, zumindest das erste Kapitel, was es schon Online gibt. Da führt er ziemlich Abstrakt in eine Begriffswelt ein.

Und die STL hat er ja immerhin erst für Ada entworfen.

[Bashar]

Den Absatz finde ich richtig gut:

Stepanov schrieb:

Every type has a (potentially infinite) set of computable functions definable on it. Out of this set we can select a subset such that all other functions can be defined in terms of it. I call such a subset a computational basis of a type. I call a computational basis efficient if all the functions on the type can be expressed in terms of the basis as efficiently as if they had access to the bit representation of the type. I call a computational basis orthogonal if no functions in it can be expressed in terms of other functions without loss of efficiency.

[Tachyon]

rüdiger schrieb:

Und die STL hat er ja immerhin erst für Ada entworfen.

Ulkig, dass STL-ähnliche Komponenten erst in Ada 2005 Einzug gehalten haben...

[Wissensdurstiger]

wo findet man den diese sample chapter von den elements?

[rüdiger]

Wissensdurstiger schrieb:

wo findet man den diese sample chapter von den elements?

Komisch, er scheint es entfernt zu haben. Das war unter http://www.stepanovpapers.com/eop/eop.pdf zu finden.

http://www.elementsofprogramming.com/ da findet man leider auch noch nichts.

[berniebutt]

namespace invader schrieb:

Wenn es nur darum geht, irgendwas irgendwie zum Laufen zu kriegen, kommt man mit C++ sicher schneller zum Ziel als mit C. Aber elegante Programme kann man damit nicht schreiben.

Wieso nicht? Ich benutze die erweiterten Dinge von C++ dort, wo sie mir nützlich sind - konkret Streams, Overloads und Klassen. Das habe ich mit C einfach nicht. Ein Programm ist nur dann elegant, wenn es übersichtlich zu strukturieren und damit einfach zu warten ist. Das geht mit mit C++ sogar besser als nur mit reinem C!

[Diskussionsstarter]

Wow, das Paper "Notes on Programming" ist ja wirklich klasse, da lernt man noch richtig was
Da hat sich dieser Thread für mich ja richtig gelohnt, vor allem die Allgemeingültigkeit ist wirklich beeindruckend. Schade nur, dass man bei den Sprachen kaum Auswahl, denn außer C++ fällt mir gerade gar keine ein, wo man das halbwegs transparent implementieren kann.
Kennt ihr sonst noch Sprachen die nahe genug an der Hardware sind und ausreichend Abstraktionsmechanismen besitzen um die Konzepte umzusetzen?

[~fricky]

Diskussionsstarter schrieb:

Schade nur, dass man bei den Sprachen kaum Auswahl, denn außer C++ fällt mir gerade gar keine ein, wo man das halbwegs transparent implementieren kann.

was davon meinst du denn?

[Diskussionsstarter]

~fricky schrieb:

Diskussionsstarter schrieb:

Schade nur, dass man bei den Sprachen kaum Auswahl, denn außer C++ fällt mir gerade gar keine ein, wo man das halbwegs transparent implementieren kann.

was davon meinst du denn?

Bin noch nicht sonderlich weit in dem Paper (die ersten 7 Lektionen habe ich bisher durch). Konkret meine ich damit ein effizientes und transparentes swap.

[Christoph]

Diskussionsstarter schrieb:

~fricky schrieb:

Diskussionsstarter schrieb:

Schade nur, dass man bei den Sprachen kaum Auswahl, denn außer C++ fällt mir gerade gar keine ein, wo man das halbwegs transparent implementieren kann.

was davon meinst du denn?

Bin noch nicht sonderlich weit in dem Paper (die ersten 7 Lektionen habe ich bisher durch). Konkret meine ich damit ein effizientes und transparentes swap.

In manchen anderen Sprachen, z.B. in Haskell, gibt es das Konzept "swap" überhaupt nicht. Nur weil man eine Idee in einer Sprache schön implementieren kann, bedeutet das nicht, dass diese Idee in anderen Sprachen überhaupt sinnvoll ist.

[Bashar]

In den meisten Sprachen ist so ein allgemeines swap auch nicht sinnvoll, weil Value-Objekte nicht den Stellenwert haben, den sie in C++ haben. Man arbeitet also wenn dann mit Referenzen.

swap in Lisp:

(rotatef a b) 
; allgemeiner als swap:
(rotatef a b c d)

swap in Python:

a, b = b, a

swap in Java:

// F#%&...

[lolnoob]

Bashar schrieb:

swap in Python:

a, b = b, a

sieht ja scheiße aus

[Diskussionsstarter]

Bashar schrieb:

In den meisten Sprachen ist so ein allgemeines swap auch nicht sinnvoll, weil Value-Objekte nicht den Stellenwert haben, den sie in C++ haben. Man arbeitet also wenn dann mit Referenzen.

swap in Lisp:

(rotatef a b) 
; allgemeiner als swap:
(rotatef a b c d)

swap in Python:

a, b = b, a

swap in Java:

// F#%&...

Stimmt, so gesehen hast du recht.

[~fricky]

Diskussionsstarter schrieb:

Konkret meine ich damit ein effizientes und transparentes swap.

ein 'swap' ist doch bloss das vertauschen zweier dinge, bzw. eine 'rotation' von etwas, das nur aus zwei elementen besteht. dass unter C++ aus solch einfachen dingen eine wissenschaft gemacht wird, ist mal wieder bezeichnend.