NG Programmiersprache?

[cpp]

void testBurn(Boot &b){
if(foo(b->getMass() || bar(b)){
b->burn();
}//if
}//testBurn

std::vector<Boot*> boote;

for_each(boote->begin(),boote->end(),testBurn);

[cpp]

Nochmal mit boote

Und mit Lambda wird das mal nen Einzeiler

std::for_each(boote->begin(), boote->end(), [](Boot &b) -> void { if (foo(b->getMass() || bar(b)) b->burn(); }); [/cpp]

SideWinder

Gefällt euch hier die Lambda-Syntax (in diesem Fall) wirklich besser als die foreach-Schleife?

MfG SideWinder

std::for_each(boote->begin(), boote->end(), [&boote](Boot &b) { if (foo(b->getMass() || bar(b)) b->burn(); });

Vielleicht so (Korrektur). Keine Ahnung, kanns ja nicht testen.

SideWinder schrieb:

Gefällt euch hier die Lambda-Syntax (in diesem Fall) wirklich besser als die foreach-Schleife?

MfG SideWinder

Nein, aber zumindest reduziert man im Prinzip überflüssige Funktionen

Mit entsprechend schönen Syntax Highlighting (einfacher zu lesen), würde ich aber evtl. auf den Geschmack kommen.

Sollte es das nicht geben, so empfinde ich die Foreach als sinniger und natürlich lesbarer.

Habs mal ausprobiert, aber ist trotz Highlighting net sooo viel besser:
http://pastehtml.com/view/1a6ht3y.html

Eventuell hab ich auch einfach keine guten Farben ausgesucht usw.

Lambda schaut ja genial aus^^ .

Mhh eigentlich macht alles 3 Sinn.

Lambda Version für die Einzeiler.
foreach für den einmalgebrauch wenn Lambda zu lang wird.
for_each für Templates oder wenn aus verschiedenen Bereiche des Code ein Funktor gebraucht wird.

Frage zu Lambda:

....[&boote]  //für was steht das ? 
(Boot &) //Das ja der Parameter, Rückgabewert gibt es nicht

Das in den Klammern ist der Wert der als Parameter übergeben werden soll. Und das in den Klammern ist dann der eigentliche Parameter und der Typ.

aaaaaaaaa schrieb:

Das in den Klammern ist der Wert der als Parameter übergeben werden soll. Und das in den Klammern ist dann der eigentliche Parameter und der Typ.

Ohhh, na ja... Ich bezog mich erst auf die eckigen [] und danach auf die runden () Klammern.

thx

SideWinder schrieb:

Gefällt euch hier die Lambda-Syntax (in diesem Fall) wirklich besser als die foreach-Schleife?

Das ist doch toll, wenn man im Code so eine "Schleife" findet und erst ne Weile diesen Einzeiler anschauen muss, bis man es versteht, statt ner drei zeiligen For-Schleife die man praktisch überfliegen kann.

Nexus

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.

Natürlich sind viele Beispiele von Mehrfachvererbung reiner Schwachsinn. Das liegt aber nicht primär an der Mehrfachvererbung, sondern an der Vererbung. Viele Vererbungsbeispiele sind nämlich komplett unangebracht.

Ich nehme im Weiteren an, du meinst mit Mehrfachvererbung statusbehaftete ("echte") Klassen und nicht abstrakte Interfaces (in C++ Klassen mit rein virtuellen Methoden, in Java interface ). Da gibt es schon Anwendungsbereiche. Und zwar nicht nur um weniger Code zu schreiben.

Ein GUI-Beispiel, bei dem Component die Basisklasse für irgendwelche GUI-Komponenten ist und Panel eine Gliederungsbox in einem Fenster Window . Sowohl Panel als auch Window können andere GUI-Komponenten enthalten, deshalb erben sie von Container .

class Component;
class Container;

class Panel : public Container, public Component { ... };
class Window : public Container { ... };

Das erlaubt es nämlich, komponenten-beinhaltende Komponenten einheitlich anzusprechen und jeweils nur eine Funktion zu haben.

void ListAllComponents(const Container& c);

Michael E. schrieb:

Vererbung wird viel zu oft missbraucht an Stellen, wo andere Mittel besser wären. Wenn man dann keine Vererbung benutzen willst, wird einem direkt vorgeworfen, man würde nicht objektorientiert programmieren

Oder wenn man globale Funktionen verwendet, wenn diese sinnvoller als Memberfunktionen sind. Traurig, aber ich höre ab und zu Sprüche wie "wir sind doch in C++, da nimmt man Klassen" oder " obj.Func() ist viel objektorientierter als Func(obj) ".

rage_quit

also statt eine neue sprache mit featues vollzupumpen würde ich eher einen minimalistischen aber doch vollständigen oop ansatz bevorzugen also keine 10000 verschiedenen schleifen typen keine nested functions usw.

@edit also ohne jetzt nen flamewar loszutreten, ansi c ist doch viel schneller gelernt als c++ und das liegt nicht nur an oop... wenn man sich nun vorstellt das jemand schnell zum ziel will (eine kleine veränderung an bestehender software vornehmen) so hat er idr. keine lust erstmal ein halbes jahr ne neue sprache zu lernen...

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.

Natürlich sind viele Beispiele von Mehrfachvererbung reiner Schwachsinn. Das liegt aber nicht primär an der Mehrfachvererbung, sondern an der Vererbung. Viele Vererbungsbeispiele sind nämlich komplett unangebracht.

Ich nehme im Weiteren an, du meinst mit Mehrfachvererbung statusbehaftete ("echte") Klassen und nicht abstrakte Interfaces (in C++ Klassen mit rein virtuellen Methoden, in Java interface ). Da gibt es schon Anwendungsbereiche. Und zwar nicht nur um weniger Code zu schreiben.

Ein GUI-Beispiel, bei dem Component die Basisklasse für irgendwelche GUI-Komponenten ist und Panel eine Gliederungsbox in einem Fenster Window . Sowohl Panel als auch Window können andere GUI-Komponenten enthalten, deshalb erben sie von Container .
class Component;
class Container;

class Panel : public Container, public Component { ... };
class Window : public Container { ... };
Das erlaubt es nämlich, komponenten-beinhaltende Komponenten einheitlich anzusprechen und jeweils nur eine Funktion zu haben.
void ListAllComponents(const Container& c);

Oder nicht doch besser Has-A Container? Oder willst du bei panel.size die größe des Containers? Kennst du ein GUI Framework das so ne Mehrfachvererbung hat? Und kein selber gebautes.

Bei Qt:

QWidget
Inherits QObject and QPaintDevice.

In Scott Meyers Effecitve C++ ist auch ein Beispiel drin, das zeigt, wo man MI verwenden _kann_. Man braucht es nicht häufig, aber es gibt Einsatzgebiete.

thatway schrieb:

Oder nicht doch besser Has-A Container?

Welchen Vorteil hätte das hier?

Nachfrager schrieb:

thatway schrieb:

Oder nicht doch besser Has-A Container?

Welchen Vorteil hätte das hier?

Keine Konflikte mit anderen Methoden. Einige Methoden von Container sind für Panel relativ sinnlos (Zugriff auf Index oder Iterator).

Cute schrieb:

Bei Qt:

QWidget
Inherits QObject and QPaintDevice.

Bei Qt ist das aber wohl auch so aufgrund der tatsache, dass QPaintdevice nicht von QObject erbt. Und QObjects kann man nicht kopieren, was bei einem paintdevice natürlich ungünstig wäre.
Das ganze ist bei Qt dann wohl also eher aufgrund des designs der klassen so entstanden, bzw aufgrund der einschränkungen von QObject.

Ich denke, man kann durchaus sagen, dass bis auf weniger spezialfälle hauptsächlich in frameworks "echte" mehrfachvererbung eher nicht nötig ist. Und die wenigen spezialfälle hängen idR doch an irgendwelchen einschränkungen im klassendesign (bei Qt eben QObject).
Bei Qt ist die mehrfachvererbung eben auch eher die ausnahme.

knivil

Next Generation Programmiersprache? Und alle labern von C++, Qt und ueber Vergangenheit.

aber komm jetzt nicht mit Funktionalen Programmiersprachen. Die sind ja auch schon uralt.