NG Programmiersprache?

Mr. N schrieb:

hehe schrieb:

Da nehme ich dann doch lieber eine for-schleife.

Dann zeig deine Künste.

Jetzt stehts zwar schon da, aber das hatte ich, noch vor meinem ersten Beitrag, nachdem ich mir das http://de.wikipedia.org/wiki/Fibonacci-Folge angeschaut hatte, in 5 Minuten hingeschmiert, um zu prüfen, ob man das nicht mit ner for-schleife hin bekommt.

int fib( int n )
{
	int a = 0;
	int b = 1;
	for(int i = 0;i<n;i++ )
	{
		a=a+b;
		int t=b;
		b=a;
		a=t;
	}
	return a;
}

Zeus schrieb:

http://stackoverflow.com/questions/1518726/recursive-fibonacci
int fib(int n)
{
    int a = 1, b = 1;
    for (int i = 3; i <= n; i++) {
        int c = a + b;
        a = b;
        b = c;
    }           
    return b;
}
Auf die iterative Version bin ich nur darauf gekommen, weil ich es in Tabellenform auf Papier gebracht habe.

Ok, meine Lösung ist doch anders. Meine gibt für fib(0) auch 0 aus. So wie es auf Wikipedia steht.

*john 0

thatway schrieb:

Wer greift da wen persönlich an?

Du solltest dringend lernen zwischen fachlicher und persönlicher Kritik zu unterscheiden. Denn bisher hast Du noch nicht einmal ansatzweise erkennen lassen, daß Du die verschiedene Argumente pro und contra MI kennen würdest, die sich wie ein roter Pfaden durch die OO-Literatur zieht. Kritik in diesem Punkt an Dir ist also vollkommen berechtigt, denn bisher hast Du nur die Empfehlung möglichst keine MI in C++ zu verwenden monoton heruntergebetet. Aus Deinen Äußerungen hier im Forum kann man jedenfalls nicht schließen, daß Du Dich jemals mit dem Thema tiefer auseinandergesetzt hättest.

Das Buch von Stroustrup zeigt sehr deutlich weshalb es sinnvoll ist MI in C++ zu haben, es kostet faktisch nichts, und in wenigen Fällen erleichtert sie einem enorm das Leben. Daher sehe ich MI als notwendig für eine zukünftige Programmiersprache an, es kostet faktisch nichts, aber in bestimmten Fällen vereinfacht MI das Design einer Klassenbibliothek.

Phoemuex

Die schönste Lösung ist doch sowieso das Folgende

#include <cmath>
#include <iostream>

using namespace std;

int main()
{
    double const wurzelFuenf = sqrt(5.0);
    double const phi = (1.0 + wurzelFuenf)/2.0;
    double phiHochN = 1;
    for(int N = 0; N < 20; ++N)
    {
        cout << "f_" << N << ": " << static_cast<int>(phiHochN/wurzelFuenf + 0.5) << endl;
        phiHochN *= phi;
    }
}

volkard

Phoemuex schrieb:

Die schönste Lösung ist doch sowieso das Folgende

#include <cmath>
#include <iostream>

using namespace std;

int main()
{
    double const wurzelFuenf = sqrt(5.0);
    double const phi = (1.0 + wurzelFuenf)/2.0;
    double phiHochN = 1;
    for(int N = 0; N < 20; ++N)
    {
        cout << "f_" << N << ": " << static_cast<int>(phiHochN/wurzelFuenf + 0.5) << endl;
        phiHochN *= phi;
    }
}

wurzelFuenf ist schlechter zu lesen als sqrt(5) und damit eine böse Auslagerung. Achso, wegen Performance, weil Du die zahl zweimal brauchst. Aber die Potenzierschleife statt pow ist böse UND riecht langsam.
Wobei ich mich schon immer frage, ab welchen Zahlen die geschlossene Formel schneller als die paar Integer-Additionen ist.

~john schrieb:

thatway schrieb:

Wer greift da wen persönlich an?

Du solltest dringend lernen zwischen fachlicher und persönlicher Kritik zu unterscheiden. Denn bisher hast Du noch nicht einmal ansatzweise erkennen lassen, daß Du die verschiedene Argumente pro und contra MI kennen würdest, die sich wie ein roter Pfaden durch die OO-Literatur zieht. Kritik in diesem Punkt an Dir ist also vollkommen berechtigt, denn bisher hast Du nur die Empfehlung möglichst keine MI in C++ zu verwenden monoton heruntergebetet. Aus Deinen Äußerungen hier im Forum kann man jedenfalls nicht schließen, daß Du Dich jemals mit dem Thema tiefer auseinandergesetzt hättest.

Das Buch von Stroustrup zeigt sehr deutlich weshalb es sinnvoll ist MI in C++ zu haben, es kostet faktisch nichts, und in wenigen Fällen erleichtert sie einem enorm das Leben. Daher sehe ich MI als notwendig für eine zukünftige Programmiersprache an, es kostet faktisch nichts, aber in bestimmten Fällen vereinfacht MI das Design einer Klassenbibliothek.

Wenn Du dein Wissen aus 15 Jahren alten Büchern beziehst und nicht weißt wie man was richtig entwirft, mach dafür nicht Deine Mitmenschen verantwortlich. Es gibt mittlerweile eine reichhaltige Entwurfsmusterliteratur, die ohne MI auskommt, darin kannst Du solche Grundlagen nachlesen.

So das war jetzt fachliche Kritik (nach deiner Definition).

Nexus

thatway schrieb:

Es gibt mittlerweile eine reichhaltige Entwurfsmusterliteratur, die ohne MI auskommt, darin kannst Du solche Grundlagen nachlesen.

Okay, dann einigen wir uns darauf, dass man Mehrfachvererbung einfach nicht braucht. Templates, Operatorüberladung, Const-Correctness oder freie Funktionen braucht man ja auch nicht, siehe Java.

Nexus schrieb:

Okay, dann einigen wir uns darauf, dass man Mehrfachvererbung einfach nicht braucht. Templates, Operatorüberladung, Const-Correctness oder freie Funktionen braucht man ja auch nicht, siehe Java.

Totschlag
http://de.wikipedia.org/wiki/Strohmann-Argument

volkard

KuhTee schrieb:

Nexus schrieb:

Okay, dann einigen wir uns darauf, dass man Mehrfachvererbung einfach nicht braucht. Templates, Operatorüberladung, Const-Correctness oder freie Funktionen braucht man ja auch nicht, siehe Java.

Totschlag
http://de.wikipedia.org/wiki/Strohmann-Argument

Das mußt Du näher ausführen. Inwiefern wurde ein Argument zum einfacheren widerlegen verbogen? Welches wohin?

Ihr könnt ja mal hier ein paar Entwurfsmuster mit Mehrfachvererbung verlinken, damit ich mal die Vorteile von Mehrfachvererbung kennen lern. (Ein Beispiel in einem alten Buch, das ich mir sicher nicht kaufe, ist kein Link. ) Mal sehen, was da so kommt.

volkard

thatway schrieb:

Ihr könnt ja mal hier ein paar Entwurfsmuster mit Mehrfachvererbung verlinken, damit ich mal die Vorteile von Mehrfachvererbung kennen lern. (Ein Beispiel in einem alten Buch, das ich mir sicher nicht kaufe, ist kein Link. ) Mal sehen, was da so kommt.

Ah, hier wird die Argumentation verbogen.
Statt der Frage, ob MI gelegentlich sinnvoll ist, wird umgebogen auf die Frage, ob MI für mehrere Entwurfsmuster jüngst aufgeschrieben wurde.
Das verkennt aber, daß man gerne Entwurfsmuster einigermaßen Sprachenunabhängig faßt, sodaß sie in Sprachen mit und ohne MI klappen, daß Entwurfsmuster mehr Richtlinien sind als Gesetze, wenn man den Trick kapiert, soll man sie gerne auch ein wenig anders implementieren, und viele Dinge mehr.

Phoemuex

volkard schrieb:

Aber die Potenzierschleife statt pow ist böse UND riecht langsam.

Ich dachte, es geht sowieso darum, alle Fibonacci-Zahlen zu berechnen und nicht nur die n-te. Sonst hätte ich natürlich pow genommen

*john 0

thatway schrieb:

...

Du trollst permanent! Keinerlei eigene Argumente nur verdrehen der Argumente von mir.

Nochmals warum sollte eine Programmiersprache MI nicht enthalten, wenn es die Sprache nicht wesentlich kompliziert und keinerlei Nachteile zur Laufzeit hat? Bei allen Deinen Beiträgen kam dazu KEINERLEI Argument.

Nexus

KuhTee schrieb:

Totschlag

Eigentlich habe ich ja nur meine Aussage von zehn Seiten vorher wiederholt.

Nexus schrieb:

thatway schrieb:

Dravere schrieb:

Gegenfrage: Wieso sollte man [Mehrfachvererbung] verbieten?

Weil man es nicht braucht.

Was für ein Argument. Man braucht recht wenig, um zu programmieren.

thatsway, du hast bisher noch nichts erwähnt, das gegen Mehrfachvererbung spricht. Und nein, "man braucht es nicht" ist kein Argument. Das meinte ich.

knivil

Also das hier sind die Next Generation Programmierer? Da hilft dann auch keine Sprache!

Nexus schrieb:

KuhTee schrieb:

Totschlag

Eigentlich habe ich ja nur meine Aussage von zehn Seiten vorher wiederholt.

Nexus schrieb:

thatway schrieb:

Dravere schrieb:

Gegenfrage: Wieso sollte man [Mehrfachvererbung] verbieten?

Weil man es nicht braucht.

Was für ein Argument. Man braucht recht wenig, um zu programmieren.

thatsway, du hast bisher noch nichts erwähnt, das gegen Mehrfachvererbung spricht. Und nein, "man braucht es nicht" ist kein Argument. Das meinte ich.

Ich hab schon öfters gesagt, dass man doch nur Mosterklassen erzeugt. Oder vielleicht versteht ihr es mit den Worten von Wikipedia:

http://de.wikipedia.org/wiki/Mehrfachvererbung schrieb:

Als Einwand gegen Mehrfach-Klassenvererbung wird häufig genannt, dass sie das Design unnötig kompliziert und undurchsichtig machen können.

Aber ihr seid ja alle so perfekt, dass das nicht zählt, weil ihr ja nie etwas unnötig kompliziert machen würdet. Und das Diamond Problem wird euch auch nie passieren. In meiner Firma wird anscheinend zufälligerweise nur der Code von genau den einzigen paar C++ Programmierern refactort die nicht ganz perfekt waren und Mehrfachvererbung rein gehackt haben um Teile von Klassen auch wo anders verwenden zu können und so kaotische Abhängigkeiten erzeugten.

knivil schrieb:

Also das hier sind die Next Generation Programmierer? Da hilft dann auch keine Sprache!

Mehrfachvererbung For Teh Win.

ipsec

Man kann so ziemlich alles missbrauchen. Genauso könnte man Funktionsüberladung verurteilen (man könnte ja abs(int) derart überladen, dass es bunte Kreise auf den Bildschirm zeichnet und der frühere Code x = abs(5) , der sich auf abs(double) verließ, funktioniert nicht mehr) oder Operatorüberladung (damit kann man das Design unnötig undurchsichtig machen. Was ist, wenn jemand bei seiner Matrix -Klasse plötzlich + und - in der Bedeutung vertauscht?) oder Properties in C# (ein banales x = variable.wert kann intern das System rebooten) oder objektorientierte Programmierung im Allgemeinen (Klassen können das Design sehr komplex und undurchsichtig machen) usw. usw.
Bei der Argumentation landen wir irgendwann bei Brainfuck, dort kann man in der Hinsicht wenigstens nichts falsch machen.
Dass Mehrfachvererbung unter Umständen zu Designfehlern führt, weil der Programmierer sich schnell was zusammengehackt hat, was ohne Mehrfachvererbung gar nicht ginge, ist ja eine ganz andere Frage.
Trotzdem ist das kein Argument dagegen.

volkard schrieb:

thatway schrieb:

Ihr könnt ja mal hier ein paar Entwurfsmuster mit Mehrfachvererbung verlinken, damit ich mal die Vorteile von Mehrfachvererbung kennen lern. (Ein Beispiel in einem alten Buch, das ich mir sicher nicht kaufe, ist kein Link. ) Mal sehen, was da so kommt.

Ah, hier wird die Argumentation verbogen.
Statt der Frage, ob MI gelegentlich sinnvoll ist, wird umgebogen auf die Frage, ob MI für mehrere Entwurfsmuster jüngst aufgeschrieben wurde.
Das verkennt aber, daß man gerne Entwurfsmuster einigermaßen Sprachenunabhängig faßt, sodaß sie in Sprachen mit und ohne MI klappen, daß Entwurfsmuster mehr Richtlinien sind als Gesetze, wenn man den Trick kapiert, soll man sie gerne auch ein wenig anders implementieren, und viele Dinge mehr.

Falsch interpretiert, die Frage drängte sich mir nur wegen so einer fachlichen Grundlagen Kritik auf.

Aber vielleicht kennst du ja ein paar C++ Idioms die Mehrfachvererbung verwenden und die mich von Mehrfachvererbung überzeugen können.

Nexus

thatway schrieb:

http://de.wikipedia.org/wiki/Mehrfachvererbung schrieb:

Als Einwand gegen Mehrfach-Klassenvererbung wird häufig genannt, dass sie das Design unnötig kompliziert und undurchsichtig machen können.

So kann man argumentieren, aber nicht nur gegen Mehrfachfachvererbung. In C++ gibt es sehr viele Sprachmittel, die das Design bei falschem Gebrauch unnötig kompliziert machen (das hört man teilweise auch als Punkt von C++-Kritikern). Im Gegenzug können sie aber auch Zusammenhänge vereinfachen, für Mehrfachvererbung gilt das Gleiche.

thatway schrieb:

Aber vielleicht kennst du ja ein paar C++ Idioms die Mehrfachvererbung verwenden und die mich von Mehrfachvererbung überzeugen können.

Wäre Policy-Based Design so ein Idiom? Dieses wird ab und zu auch eingesetzt, um die Schnittstelle einer Klasse über die Policy zu erweitern. Indem das Template von mehreren Policies erbt, stellt es deren öffentliche Methoden ebenfalls zur Verfügung. Mehrfachvererbung kommt hier ins Spiel, sobald mehrere Policies vorkommen (oder das Template nebenbei von einer hardgecodeten Klasse erbt). Ist zwar eher ein Spezialfall von Mehrfachvererbung, aber vielleicht kannst du damit mehr anfangen.

ipsec schrieb:

Man kann so ziemlich alles missbrauchen. Genauso könnte man Funktionsüberladung verurteilen (man könnte ja abs(int) derart überladen, dass es bunte Kreise auf den Bildschirm zeichnet und der frühere Code x = abs(5) , der sich auf abs(double) verließ, funktioniert nicht mehr) oder Operatorüberladung (damit kann man das Design unnötig undurchsichtig machen. Was ist, wenn jemand bei seiner Matrix -Klasse plötzlich + und - in der Bedeutung vertauscht?) oder Properties in C# (ein banales x = variable.wert kann intern das System rebooten) oder objektorientierte Programmierung im Allgemeinen (Klassen können das Design sehr komplex und undurchsichtig machen) usw. usw.
Bei der Argumentation landen wir irgendwann bei Brainfuck, dort kann man in der Hinsicht wenigstens nichts falsch machen.
Dass Mehrfachvererbung unter Umständen zu Designfehlern führt, weil der Programmierer sich schnell was zusammengehackt hat, was ohne Mehrfachvererbung gar nicht ginge, ist ja eine ganz andere Frage.
Trotzdem ist das kein Argument dagegen.

Diese fehler sind eher klein und lassen sich einfach beheben. Außerdem muss schon böser Wille vorhanden sein um das zu machen.
Ein Fehler im Design durch Mehrfachvererbung ist meist weit schwerer zu beheben als eine Funktion umzubennen, außerdem kann man diese Fehler auch ohne bösartigkeit oder komplette Inkompetenz machen.