NULL

Shade Of Mine

+fricky schrieb:

hast du'n beispiel, wo postinkrement in Java (oder C) langsamer ist, als preinkrement?

Klar.

int i=0;
++i;

Nur weil dein java compiler das optimieren kann heisst es ja nicht dass es meiner können muss.

Die Sache ist halt die, dass es sehr sehr leicht optimierbar ist - keine Frage. Aber die Semantik ist komplett gleich. Ich hab übrigens nen C compiler der das nicht optimieren kann... Wenn für ++x immer x++ verwendet wird, ist das nunmal ein Fehler des programmierers. Kein großer Fehler, aber ein Fehler. Und in gewissen Situationen bestraft C++ nun diesen Fehler. Ich sehe das kein Problem.

und genau das ist falsch. 'manchmal' reicht nun mal als grund nicht aus.

Dir ist schon bewusst dass alle Sprachfeatures nur manchmal gebraucht werden. zB wozu brauch ich for und do while in C? vollkommen unnötig weil redundant.
operatoren überladung fügt dafür ein neues konzept hinzu. ein neues konzept kann definitions bedingt nicht redundant sein.

natürlich können wir jetzt generell allen sprachen alle features wegdiskutieren. wozu zB int, short und long? reicht nicht double für alles?

wozu funktionen wenn wir goto haben...

Ach fricky, bemüh dich doch wenigstens

JustAnotherNoob

^^wo siehst du da 'nen unterschied? x++ bzw. ++x brauchen jeweils 3 bzw. 4 operationen. wieso sollte ++x schneller sein als x++. unter C++ mag es ja so sein, aber normal ist das nicht.

Wie kommst du denn darauf?
x++ ist ein Ausdruck der seperat ausgewertet wird(wenn ers nicht wird, optimiert der Compiler).

Shade Of Mine

+fricky schrieb:

^^wo siehst du da 'nen unterschied? x++ bzw. ++x brauchen jeweils 3 bzw. 4 operationen. wieso sollte ++x schneller sein als x++. unter C++ mag es ja so sein, aber normal ist das nicht.

doch ist normal, weil keine kopie nötig ist.

natürlich muss ++x nicht schneller sein, aber es kann. eben weil lesen und zuweisen nicht zwangsläufig notwendig sind.

und
++x -> hochzählen
x++ -> zuweisen, hochzählen
plötzlich doch unterschiedlich ist.

JustAnotherNoob schrieb:

Infixnotation ist praktisch aber wie wird das mit der Operatorenpriorität geregelt?

In Smalltalk gibt es keine Operatoren in genau dem Sinne, wie es sie in C++ gibt, sondern nur Nachrichten. Die Prioritätsfolge ist:

Nachrichten ohne Argument (unär)
Nachrichten mit genau einem Argument (binär)
Nachrichten mit Schlüsselwort:/-wörtern:

Außerdem gibt es Klammern zur Manipulation der Auswertungsreihenfolge.

ZB ist in Smalltalk 1 + 2 * 3 gleich 9. Wem das nicht paßt, der muß 1 + (2 * 3) schreiben.

JustAnotherNoob schrieb:

x++ ist ein Ausdruck der seperat ausgewertet wird(wenn ers nicht wird, optimiert der Compiler).

das gilt für ++x ebenso, wenn der ausdruck ausgewertet wird. wird er's nicht, dann wird eben nur hochgezählt, egal auf welcher seite sich das ++ befindet. bei einem überladenen C++ postinkrement-op würde zuerst eine kopie erzeugt, dann aber weggeworfen werden.

Shade Of Mine schrieb:

und
++x -> hochzählen
x++ -> zuweisen, hochzählen
plötzlich doch unterschiedlich ist.

wo wird da noch was zugewiesen (ausser dem 'x', sein vorheriger wert+1, in beiden fällen)?

Shade Of Mine schrieb:

Wenn für ++x immer x++ verwendet wird, ist das nunmal ein Fehler des programmierers. Kein großer Fehler, aber ein Fehler. Und in gewissen Situationen bestraft C++ nun diesen Fehler.

es ist ein fehler, der direkt daraus folgt, wie überladene postinkrement-ops in C++ realisiert sind.

auch hier sieht man mal wieder, wie komplizierte Syntax zu eigentlich überflüssigen Einschränkungen in der OOP führen kann.

In einer reinen Objektwelt bedürfte es eigentlich nur Nachrichten an Objekte. Operatoren sind dann Spezialfälle von Nachrichten, und die Polymorphie überladener Operatoren ist nichts Anderes als die einfache Tatsache, daß es erlaubt sein muß, Objekten verschiedener Klassen gleichlautende Nachrichten zu schicken, so, wie das in der realen Welt ganz natürlich ist. Syntax ist doof ...

JustAnotherNoob

auf fricky weiter einzugehen erscheint mir hier grad sinnlos, wenn er nicht liest was geschrieben wird soll er halt bei Java bleiben(tut er eh, zumindest steht hier genug, dass eventuelle Mitleser ihn nicht mehr ernst nehmen).

Anderes als die einfache Tatsache, daß es erlaubt sein muß, Objekten verschiedener Klassen gleichlautende Nachrichten zu schicken, so, wie das in der realen Welt ganz natürlich ist. Syntax ist doof ...

Syntax sorgt nur dafür, dass man sich präziser ausdrücken kann, sprich alles kürzer und exakter beschreiben kann. Umschreibungen sind allgemeiner, keine Frage, beides hat Vorteile und Nachteile.
Scala fällt mir grad als Beispiel einer Sprache mit sehr viel Syntax ein, so viele Syntaxregeln erlauben einem auch schon wieder sehr viele Freiheiten.
Wie allgemein eine Syntax sein soll ist aber auch wieder eine andere Frage.

Ich finde eher, Syntax schränkt die Ausdrucksfähigkeiten ein, anstatt sie zu erweitern. Nicht zufällig sind es gerade die Sprachen mit minimaler Syntax, die außergewöhnliche Freiheiten im Ausdruck zulassen (Tcl, Smalltalk, Forth, LISP und wie sie alle heißen).

Scala kenne ich nicht, aber es scheint auf den ersten Blick keine Minimal-Syntax-Sprache zu sein.

JustAnotherNoob

Scala kenne ich nicht, aber es scheint auf den ersten Blick keine Minimal-Syntax-Sprache zu sein.

Im Gegenteil

Ich finde eher, Syntax schränkt die Ausdrucksfähigkeiten ein, anstatt sie zu erweitern.

Sag ich ja.
Ich würde sagen eine Sprache mit viel Syntaxregeln ist in den von dem von der Syntax abgedecktem Spektrum kürzer und einfacher zu lesen. Allerdings eben nicht so mächtig. Allerdings: desto mehr zusätzliche Syntaxregeln, desto größer das Spektrum.

JustAnotherNoob schrieb:

Allerdings: desto mehr zusätzliche Syntaxregeln, desto größer das Spektrum.

nichtsdestotrotz, eine sättigung ist schnell erreicht. es bringt ja nicht viel, wenn du 10 möglichkeiten hat, das gleiche zu tun, aber 8 davon zusätzliche probleme aufwerfen.

JustAnotherNoob schrieb:

Ich würde sagen eine Sprache mit viel Syntaxregeln ist in den von dem von der Syntax abgedecktem Spektrum kürzer und einfacher zu lesen.

Minimalsyntax-Sprachen erlauben es aber ihrerseits, 'domain-specific languages' zu implementieren, die man paßgenau an die Notation der zu lösenden Aufgabe anpassen kann. Z.B. sind in Tcl arithmetische Ausdrücke als Untersprache 'expr' definiert, ohne, daß man dazu den Sprachkern von Tcl mit Syntaxregeln für arithmetische Ausdrücke hätte zukleistern müssen. Genial.

Selbst Objektmodelle lassen sich in Tcl implementieren, ohne die Sprache zu verlassen. Klassenbasierte OO ist zu restriktiv? Kein Problem, man kann ein prototypenbasiertes Objektmodell in Tcl implementieren, ohne zusätzliche Syntaxregeln.

*john 0

+fricky schrieb:

wer redet hier von vererbung (ausser dir)?

Interfaces sind Mehrfachvererbung ohne Implementation. Wenigstens soviel sollte man wissen.

*john 0

tfa schrieb:

Ist ja alles richtig, aber als du dann das erste mal was gesehen hast wie 1<<30, was hast du dann gedacht?

1 sehr viel kleiner als 30.

*john 0

DEvent schrieb:

Was passiert wenn es schief geht? Eine Art "Fehler-Matrix" zurueck zugeben? Oder eine exception zu werfen? Eine add() Funktion koennte einfach boolean zurueck geben.

Fehlercodes sind sch***!
Wenn gegen Kontrakte verstoßen wird, wirft man eine Exception. Das it ganz einfach, nur wird das von zu vielen nicht verstanden.

~john schrieb:

+fricky schrieb:

wer redet hier von vererbung (ausser dir)?

Interfaces sind Mehrfachvererbung ohne Implementation. Wenigstens soviel sollte man wissen.

mehrfachvererbung ist eigentlich der falsche begriff dafür, obwohl man es hin und wieder mal im zusammenhang mit interfaces liest. mehrfachvererbung ist das: http://en.wikipedia.org/wiki/Diamond_problem

*john 0

u_ser-l schrieb:

In anderen OO-Sprachen wie z.B. smalltalk ist "+" nichts Anderes als eine Nachricht (mit einer zweiten Zahl als Parameter), die an Zahlen gesendet wird: 4 + 5 im Sinne von "4.add(5)"

Ja, das ist einer der bekannten Nachteile von Smalltalk, da es nur einfaches dynamisches Dispatching kennt, und das in diesem Kontext ziemlich schnell sinnlos ist.

Beispiel:
Skalare Multiplikation von Matrizen.
int i = 2;
Matrix A;

mul (A, 2); // A2 das geht auch in Smalltalk
mul (2, A); // 2A das nicht mehr 2.mul(A) ergibt da keinen Sinn

Kann in Smalltalk niemals umgesetzt werden, denn die int Klasse versteht die Message nun einmal nicht. In C++ gibt es daher Operator-Funktionen und so kann man leicht die korrekte Funktionalität bereitstellen.
Alternativ kann man natürlich eine Sprache mit "mutiple dispatch" entwerfen, da wird dann dynamisch an Hand aller Parameter die richtige Methode ermittelt.

*john 0

+fricky schrieb:

~john schrieb:

+fricky schrieb:

wer redet hier von vererbung (ausser dir)?

Interfaces sind Mehrfachvererbung ohne Implementation. Wenigstens soviel sollte man wissen.

mehrfachvererbung ist eigentlich der falsche begriff dafür,

Nein, es ist der einzig richtige Begriff!
Mehrfachvererbung heißt erstmal nur, daß eine Klasse von mehreren Klassen abgeleitet ist, Diamonds müssen gar nicht vorkommen. Sprachen mit Interfaces lösen das Problem des Diamonds mittels der Einschränkung, daß jede Interfaces Klasse eine Superklasse sein muß. Dazu kommen üblicherweise noch Einschränkungen, daß die verschiedenen Mutterklassen einer konkreten Klasse niemals die gleichen Methodennamen verwenden dürfen. Aus diesen beiden Gründen braucht man auch kein Mittel Nameskonflikte lösen zu können. C++ hat diese Mittel, aber man braucht sie wirklich sehr selten. Sollte man Mehrfachverbung im Sinne von Interface Klassen benutzen braucht man sie gar nicht.

Um es zu konkretisieren:
Interface Klassen sind abstrakte Superklassen ohne Implementation, und beim Ableiten dürfen keine Methodennamenskollisionen auftreten.

~john schrieb:

+fricky schrieb:

~john schrieb:

+fricky schrieb:

wer redet hier von vererbung (ausser dir)?

Interfaces sind Mehrfachvererbung ohne Implementation. Wenigstens soviel sollte man wissen.

mehrfachvererbung ist eigentlich der falsche begriff dafür,

Nein, es ist der einzig richtige Begriff!

völlig falsch klingt er, allein schon wegen des 'mehrfach' da drin. ich würde es vielleicht als 'schnittstellenbeerbung' bezeichnen. aber egal...

JustAnotherNoob

völlig falsch klingt er, allein schon wegen des 'mehrfach' da drin. ich würde es vielleicht als 'schnittstellenbeerbung' bezeichnen. aber egal...

hä?
Schau dir doch einfach an was Interfaces sind.. von der Funktionalität gekürzte Klassen, von denen man unbeschränkt erben kann.
Der letztere Fakt ist Mehrfachvererbung, nur eben ohne die Probleme dieser zuzulassen(du kannst es auch gerne anders nennen, aber durch Nomenklatur ändert sich die Semantik nicht).
Dass du in C++ auch problemlos auf Mehrfachvererbung verzichten kannst oder Klassen wie Interfaces verwenden kannst ignorierst du gekonnt. Genau wie die Tatsache, dass Mehrfachvererbung nicht nur Probleme hervorruft, sondern auch nützlich ist. Du kannst auch nicht sagen, dass die Probleme die Nützlichkeit aufwiegen, weil du es nunmal nur dann verwendest, wenn es auch wirklich nützlich ist.
Auch hier: Du verwendest es nicht aus Versehen, Fehler treten zusätzlich noch zur Compiletime auf => sinnlose Beschränkung.