NG Programmiersprache?

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.

Mr. N

qwerttzy schrieb:

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

Trotzdem die Zukunft.

Die Tatsache, dass imperative Programmiersprachen für viele moderne Probleme (Concurrency bla blub) an ihre Grenzen stoßen ist da wohl der Stein, der alles ins Rollen bringt. Aber natürlich sind funktionale Programmiersprachen auch ohne das eine Verbesserung, weil sie einfach ein abstrakteres Programmieren erlauben.

Zeus

Dann werf ich mal rein: Haben object-funktionale Programmmiersprache zukunft?
In diese Art gehören Scala(scala-lang.org) und Nemerle(nemerle.org).

Mr. N schrieb:

Aber natürlich sind funktionale Programmiersprachen auch ohne das eine Verbesserung, weil sie einfach ein abstrakteres Programmieren erlauben.

Inwiefern abstrakter?

Nexus

thatway schrieb:

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).

Du hast den von mir beschriebenen Container falsch verstanden. Das ist kein Container im Sinne von std::vector , sondern ein Behälter für andere GUI-Komponenten. Als Schnittstelle und Implementierung hätte ich mir sowas vorgestellt (um es nicht zu kompliziert zu machen):

class Container
{
    public:
        void Attach(const Component& subComponent);
        void Detach(const Component& subComponent);

    private:
        std::vector<Component*> mySubComponents;
};

Ich finde den Namen "Container" auch schlecht, womöglich werde ich sogar einen Thread dazu aufmachen.

Ich gehe schon davon aus, dass zwischen Panel bzw. Window und Container eine IS-A-Beziehung (im Sinne des LSP) besteht. Und wenn es sinnvoll ist, ein Panel oder Window als Container abstrakt anzusprechen, was spricht dagegen? Ich habe ja schon Vorteile genannt, z.B. müsste

void ListAllComponents(const Container& c);

nur einmal implementiert werden. Oder man könnte Variablen

Container* var;

haben.

Man braucht Mehrfachvererbung eher selten, das stimmt. Was man ab und zu sieht, sind jedoch Beziehungen wie

class Derived : public Base, private boost::noncopyable { ... };

Alleine schon deswegen fände ich es unangebracht, Mehrfachvererbung zu verbieten.

Mr. N

Zeus schrieb:

Dann werf ich mal rein: Haben object-funktionale Programmmiersprache zukunft?
In diese Art gehören Scala(scala-lang.org) und Nemerle(nemerle.org).

Ich weiß es nicht, vielleicht. Es ist wichtig, dass man die Abstraktion und Composability nicht verliert. Ich muss mir Scala etc. noch ernsthaft anschauen, aber mein erster Eindruck ist, dass die da 'ne Menge Features haben, die nicht so ganz zusammenpassen, und es ein bisschen so wird wie in C++. Ich habe z.B. eine Übersetzung von Monads in Scala gesehen, und so wirklich elegant sah das nicht aus, aber vielleicht kann ich Scala einfach noch nicht gut genug.

So etwas wie Monads sind wichtig, damit man all diese Dinge auf der gleichen Basis aufbauen kann:

-- Liest Zeilen ein und gibt sie wieder aus.
forever $ do
  x <- getLine
  putStrLn x

do
  x <- [1..]
  y <- [1..x]
  (x, y)
-- das selbe wie [ (x, y) | x <- [1..], y <- [1..x] ] (also eine List comprehension)
-- = [(1,1),(2,1),(2,2),(3,1),(3,2),(3,3),(4,1),(4,2),(4,3),(4,4),...]

do
  n <- digitToInt <$> digit
  replicateM n letter
-- Ein Parser, der eine Ziffer liest, und danach diese Anzahl an Buchstaben.
-- Also "4abcd" ist gültig, ebenso "1a", aber "2a" ist ungültig.

Nexus

Mr. N schrieb:

qwerttzy schrieb:

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

Trotzdem die Zukunft.

Mir gefällt das Konzept funktionaler Programmiersprachen ebenfalls sehr. Ich habe mich vor einiger Zeit ein wenig mit Haskell beschäftig und es bietet wirklich interessante Möglichkeiten, die in anderen, verbreiteteren Sprachen nicht oder weniger elegant möglich sind. Man kann seinen Horizont enorm erweitern.

Jedoch würde ich das Ganze nicht nur euphorisch sehen. Warum hat sich objektorientierte Programmierung als heutiges Programmierparadigma etabliert und ist derart beliebt? Weil sie mit Objekten eine eine für den Menschen intuitive Möglichkeit bietet, das Programm zu beschreiben. Man kann damit viele Probleme aus der Realität verständlich abbilden. Bei rein funktionalen Programmiersprachen, die ihre Ursprünge eher in der Mathematik haben, ist das schon viel schwieriger. Ich denke, der durchschnittliche Programmierer hat viel mehr Mühe, sich ein funktionales Denken anzueignen als ein objektorientiert-prozedurales. Das dürfte auch ein zentraler Grund für die geringe Verbreitung rein funktionaler Programmiersprachen sein.

Allerdings gehen Programmiersprache wie C# oder C++ bereits einen Weg in Richtung funktionale Programmierung, bei C++ kommen mit dem neuen Standard z.B. Lambda-Ausdrücke als Sprachelement dazu. High-Order-Funktionen gibts auch schon länger. Meiner Meinung nach wird sich rein funktionales Programmieren nicht so schnell durchsetzen, vielmehr dürfte es eine Mischung mit momentanen Paradigmen sein.