Soll die neue Funktionsdeklaration in C++0x die Alte vollständig ersetzen?

.filmor

Naja, das ... ist ja gerade das relevante. Die Parameter werden normalerweise nach dem Rückgabetyp deklariert und sind deshalb für diesen noch nicht bekannt. Deshalb wird bei der neuen Variante der Rückgabetyp nach den Parametern deklariert, was Konstrukte wie

template <typename A, typename B>
auto add (const A& a, const B& b) -> decltype(a + b);

ermöglicht. Wie camper schon sagte war das ursprüngliche Beispiel etwas irreführend.

hustbaer

@.filmor:
OK, das ist mir schon klar.
Ich verstehe bloss trotzdem noch nicht warum das ein Problem macht.
In deinem Beispiel:

template <typename A, typename B>
auto add (const A& a, const B& b) -> decltype(a + b);

Umgeschrieben auf die alte Variante:

template <typename A, typename B>
decltype(a + b) add (const A& a, const B& b);

Wo ist das Problem?
Klar, a und b sind "noch nicht bekannt". Nur... müssen die an der Stelle bekannt sein, damit der Parser wissen kann "das decltype(a + b) steht für einen Typen".

Der Parser kann ja trotzdem schonmal sagen "da steht decltype(...), das muss ein Typ sein", und weitermachen.
Wo das decltype endet sollte sich IMO auch bestimmen lassen ohne dass man schon wissen muss was a und b jeweils sind -- die Klammern müssen ja balanced sein, das sollte doch ausreichen.

Ich meine C++ kann ja auch solche Dinge:

class X
{
public:
    void foo()
    {
        std::vector<Y> v;
    }

    typedef int Y;
};

Klar, ich habe genau 0 Erfahrung und nur wenig theoretisches Wissen über Compilerbau oder allgemein Parser, aber ich kann mir einfach nicht vorstellen dass das so kompliziert zu parsen wäre.

Deswegen meine Frage: gibt es da etwas woran ich nicht gedacht habe? Oder gibt es vielleicht mit diversen Dingen wie Funktionszeiger-Deklarationen oder templates oder nested types dann mögliche Konstrukte die sich wirklich nichtmehr parsen lassen?

Ich hoffe du verstehst worauf ich hinaus will

Ich brauch' auch keine Erklärung hier wenn mir jmd. stattdessen ein Paper verlinken kann wo diese Problematik erklärt wird, also erklärt in welchen Fällen sich hier ein Problem ergeben würde und warum.

.filmor

Davon Kapitel 3, da wird's erklärt. Die Namensauflösung wäre mit der „alten“ Syntax wohl nicht so dolle eindeutig und der Parser muss hüpfen.

asc schrieb:

Ich seh das mit dem "auto" als zweischneidiges Schwert. Sicher hilft es bei komplexen Ausdrücken ungemein (Und dafür würde ich es auch verwenden), aber bei einfachen Ausdrücken (Sprich sowas wie std::string, int...) ist mir es lieber wenn ich den Typ auf einen Blick erfassen kann.

Den wie heiß es so schön:

Man liest Code häufiger, als man ihn schreibt.

Andererseits: je leichter sich der Code ändern lässt, desto eher wirst du dies auch tun.

Und so wirklich kann ich dein Argument auch nicht nachvollziehen, bzw. sehe nicht dass das so dramatisch ist wie du dir ausmalst. Der Typ ist doch zumeist entweder relativ irrelevant (ggf. ist es sogar hinderlich einen konkreten Typ angeben zu müssen), oder er geht mehr oder weniger eindeutig aus der Initialisierung und/oder dem Bezeichner hervor.

hustbaer

Ok, danke. Geht also wirklich hauptsächlich darum dass es kompliziert (aber nicht unmöglich) zu implementieren wäre. Und halt dass die "neue" Syntax für andere Dinge wie Funktionszeiger etc. auch ganz schick (und leichter lesbar) ist.
Soll mir auch Recht sein

Simon2

'f schrieb:

...

Man liest Code häufiger, als man ihn schreibt.

Andererseits: je leichter sich der Code ändern lässt, desto eher wirst du dies auch tun....

Naja, aber Probleme beim Ändern des Codes sind üblicherweise Folge von Problemen beim Lesen des Codes (sprich: schlecht strukturierter Code - sei es nun Syntax oder Design).
Mir geht es jedenfalls so: Wenn ich schnell verstanden habe, was ein Programm tut, habe ich fast nie Probleme bei Codeänderungen (Ausnahme: Da, wo mit der Änderung das ursprüngliche Design gebrochen werden soll).

Gruß,

Simon2.