Also abgesehen von abwärtskompatibelität, aber hat die Alte dann noch irgendwelche Vorteile?

sie ist einfacher, solang du die "spielereien" nicht brauchst. aber sonst...

Also abgesehen von abwärtskompatibelität, aber hat die Alte dann noch irgendwelche Vorteile?

Ich würde mal behaupten: nie für lokale Variablen. Ich weiß gerade nicht, inwiefern Klassenattribute auch per 'auto' deklariert werden können, dies fände ich aber weniger prickelnd, wenn es ginge.

Wie sieht die neue denn aus?

z.B.:

auto x = 1;
auto str = string("Hallo") + "Welt";

auto scheint auf den ersten Blick die Typsicherheit zu gefärden.

Scheint aber nur so.

int a = 5;

viel besser als irgendwie

auto x = 5;

sieht man auf einen blick wozu das dingen da ist und wie man damit umgeht

das ist in php meines wissens auch so und ich fidne es eifnach nur unübersichtlich...

int a = 5;

Das auto wurde ja eher für das folgende eingeführt:

auto first_function() -> int;
auto second_function() -> double;
// usw.

template<typename T>
void template_function(T Function)
{
    auto Value = Function();

    // Mache was mit Value.
}

// irgendwo:
template_function(&first_function);
template_function(&second_function);

Grüssli

also ich finde die alte
also

int a = 5;

viel besser als irgendwie

auto x = 5;

sieht man auf einen blick wozu das dingen da ist und wie man damit umgeht

Ach, und bei 5 siehst Du nicht auf den ersten Blick, dass das ein int ist? Dann liegt das Problem aber woanders …

das ist in php meines wissens auch so und ich fidne es eifnach nur unübersichtlich...

Das hat hier nichts mit PHP zu tun … PHP ist dynamisch typisiert. C++ weiterhin statisch.

@OP: Ach so, Funktions~. Was meinst Du dann damit? Was hat sich dort geändert?

@OP: Ach so, Funktions~. Was meinst Du dann damit? Was hat sich dort geändert?

[] foo(int) -> int

und nochmal kurz zu auto:
was wir brauchen ist mehr auto - type inference wie zB aus ocaml ist einfach nur enorm praktisch. also ich werde auto lieben

Konrad Rudolph schrieb:

@OP: Ach so, Funktions~. Was meinst Du dann damit? Was hat sich dort geändert?

[] foo(int) -> int

Sorry wenn ich das jetzt nicht ganz verstehe, aber was wird sich nun konkret an der Funktionsdeklaration verändern? Kann das jemand an einem guten Beispiel erläutern?

Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.

auto fun () -> int
{
  return 42;
}

ich glaube nicht, dass das jemand so verwenden wird, denn int fun () ist um einiges kürzer zu schreiben.

bei manchen rückgabetypen wird es jedoch sicher einfacher sein, die neue funktionsdeklaration zu verwenden, z.b. bei komplexen rückgabetypen (tuples, funktionszeiger) - und mit der neuen funktionsdeklaration ist überaus einfacher, funktionszeiger zu deklarieren (und sehr viel schöner, funktionszeiger auf funktionen, die funktionen zurückgeben zu deklarieren).

dann gibt es noch ein einsatzgebiet, wo du die neue funktionsdeklaration verwenden *musst*:

template <Arithmetic A>
auto twice (A&& a) -> decltype(A + A)
{
  return a + a;
}

dieses beispiel ist aber auch im artikel erwähnt.

/edit: wenn user-defined literals noch in den standard reinkommen (ich zweifle), dann würde wahrscheinlich auto noch besser genutzt werden können:

auto str = "foo"s;

//decltype(str) == decltype(std::string)

Es wird sich nichts verändern, es wird aber was dazukommen. Dazu liest du am besten diesen Artikel:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-204654.html
(Abschnitt 1.5)

Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.

was mich nur wundert, und was wahrscheinlich auch der grund war weshalb shade diese syntax gepostet hat ist, dass die englische wikipedia die auto syntax nichtmehr enthält:

http://en.wikipedia.org/wiki/C%2B%2B0x#Unified_function_syntax

aus dem Artikel:

struct SomeStruct
{
  []FuncName(int x, int y) -> int;
}

[]SomeStruct::FuncName(int x, int y) -> int
{
  return x + y;
}

Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.

ah, ja sorry.
auto war es hier ja.

hab mich lediglich auf das -> type
am ende konzentriert

bei manchen rückgabetypen wird es jedoch sicher einfacher sein, die neue funktionsdeklaration zu verwenden, z.b. bei komplexen rückgabetypen (tuples, funktionszeiger)

*g* davon kann ich ein Lied singen:

template <typename TChar, typename TSpec, typename TPos>
inline typename Iterator<typename Host<StringSet<TChar, Packed<TSpec> > >::Type>::Type
hostIter(StringSet<TChar, Packed<TSpec> > const& strs, TPos pos) {
    return begin(host(strs[pos]));
}

Da ist 'auto' natürlich praktisch.

dann gibt es noch ein einsatzgebiet, wo du die neue funktionsdeklaration verwenden *musst*:

template <Arithmetic A>
auto twice (A&& a) -> decltype(A + A)
{
  return a + a;
}

Müsste es hier nicht 'decltype(a + a)' heißen?

queer_boy schrieb:

bei manchen rückgabetypen wird es jedoch sicher einfacher sein, die neue funktionsdeklaration zu verwenden, z.b. bei komplexen rückgabetypen (tuples, funktionszeiger)

*g* davon kann ich ein Lied singen:

template <typename TChar, typename TSpec, typename TPos>
inline typename Iterator<typename Host<StringSet<TChar, Packed<TSpec> > >::Type>::Type
hostIter(StringSet<TChar, Packed<TSpec> > const& strs, TPos pos) {
    return begin(host(strs[pos]));
}

...

Allerdings habe ich mir derzeit schon einen "Skip-Blick" angewöhnt:

• Erstmal die '(' suchen,
• dann den Bezeichner davor - dann weiß man schonmal, wie die Funktion heißt und vermutlich machen soll (oder ob der A*** einen FunkPtr zurückgeben will )
• und von da aus nach rechts die Parameter ...
• und nach links den Rückgabetypen.

Das Vorgehen werde ich nun ein wenig modifizieren müssen.
Ich bin auf jeden Fall schon gespannt, wie/wo sich die "->-Schreibweise" durchsetzen wird ... nur da, wo das andere zu kompliziert ist ... oder evtl. auf breiterer Basis.

Gruß,

Simon2.

Bashar schrieb:

Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.

ah, ja sorry.
auto war es hier ja.

Naja, wenn die Wiki-Seite stimmt und ich sie auf die Schnelle richtig verstanden habe, wird man wohl Funktionen auch als benannte Lambda-Ausdrücke (ist das nicht irgendwo ein Widerspruch? ) definieren können.