Soll die neue Funktionsdeklaration in C++0x die Alte vollständig ersetzen?
-
c++ gets php schrieb:
auto scheint auf den ersten Blick die Typsicherheit zu gefärden.
Scheint aber nur so.
-
also ich finde die alte
alsoint 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...
-
@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
-
Skym0sh0 schrieb:
also ich finde die alte
alsoint 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?
-
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
-
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.
-
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
-
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.
-
Die Frage lässt sich ganz eindeutig mit "Nein" beantworten. HTH
-
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?
-
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.
-
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.?
-
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)
-
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; }
-
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
-
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?
-
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.
-
Shade Of Mine schrieb:
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.
-
Nunja, aber wenn die alte leglich kürzer zu schreiben ist, man die neue aber dennoch manchmal braucht, fände ich es wesentlich konsistenter durchgängig die neue zu verwenden, oder etwa nicht?
-
JustAnotherNoob schrieb:
Nunja, aber wenn die alte leglich kürzer zu schreiben ist, man die neue aber dennoch manchmal braucht, fände ich es wesentlich konsistenter durchgängig die neue zu verwenden, oder etwa nicht?
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.
So werde ich wohl auch in Zukunft dann vorgehen: Für einfache Ausdrücke die alte Schreibweise verwenden, für komplexe siegt imho die Kürze über den Informationsgehalt, da man bei solchen Ausdrücken eh letzteres nicht gegeben ist (Komplexe Ausdrücke sind meist sowieso nicht mit einen Blick zu erfassen).
cu André