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

Konrad Rudolph

Ein echter n00b schrieb:

Wie sieht die neue denn aus?

z.B.:

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

JustAnotherNoob

Funktionsdeklaration
keine Variablendeklaration

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

.filmor

c++ gets php schrieb:

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

Scheint aber nur so.

Skym0sh0

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

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

Dravere

@Skym0sh0,
Darum geht es ja auch nicht, ich denke man wird dort weiterhin folgendes schreiben:

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

Konrad Rudolph

Skym0sh0 schrieb:

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?

Shade Of Mine

Konrad Rudolph schrieb:

@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

Krux

hat auto nicht die entgegengesetzte bedeutung zu static? Wird jetzt das alte auto einfach so rausgeworfen? OK es war sowiso überflüssing, weil es sowiso immer glat wenn man nicht static dran geschrieben hat.

Krux

hat auto nicht die entgegengesetzte bedeutung zu static? Wird jetzt das alte auto einfach so rausgeworfen? OK es war sowiso überflüssing, weil es sowiso immer glat wenn man nicht static dran geschrieben hat. Aber irgendwie erinnert es mich ein wenig an B

JustAnotherNoob

Ist ja schön und gut wenn sich hier eine Diskussion über Sinn und Unsinn von auto entwickelt, aber meine Frage hätte ich trotzdem gerne beantwortet.

Bashar

Die Frage lässt sich ganz eindeutig mit "Nein" beantworten. HTH

Nexus

Shade Of Mine schrieb:

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?

Bashar

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.

JustAnotherNoob

Ich habe den Artikel bereits gelesen, allerdings habe ich mit der Frage auch mehr die Absicht gemeint, es ist klar, dass die alte Funktionsdeklaration erhalten bleibt, aber gibt es irgend einen Grund diese noch zu verwenden, oder ist es ein weiteres veraltetes Ding wie C-Style Casts u.s.w.?

queer_boy

auto in seiner alten form wird es nicht mehr geben, aber ich habe es tatsächlich auch nie verwendet oder in verwendung gesehen.
und es wurde tatsächlich (auch) aus dem grund eingeführt, die neue funktionsdeklaration zu ermöglichen:

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)

otze

Bashar schrieb:

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;
}

Shade Of Mine

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.

hab mich lediglich auf das -> type
am ende konzentriert

Konrad Rudolph

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]));
}

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?

Simon2

Konrad Rudolph schrieb:

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.