ADL und Rückgabewerte

camper

asfdlol schrieb:

Wie kann ich den folgenden trivialen C++11-Code nach C++03 umschreiben?
template<typename ContainerT>
struct BeginT
{
	typedef decltype(std::declval<ContainerT>().begin()) Type;
};

Allgemeingültig wahrscheinlich gar nicht (begin könnte Defaultargumente haben). Praktisch ausreichend dürfte es sein, einfach &ContainerT::begin zu analysieren. Wenn begin pathologisch ist und einen Funktor darstellt, muss dann eben noch &ContainerT::begin::operator() untersucht werden. Hatten wir ja gerade erst.

Fytch

camper schrieb:

Allgemeingültig wahrscheinlich gar nicht (begin könnte Defaultargumente haben). Praktisch ausreichend dürfte es sein, einfach &ContainerT::begin zu analysieren. Wenn begin pathologisch ist und einen Funktor darstellt, muss dann eben noch &ContainerT::begin::operator() untersucht werden. Hatten wir ja gerade erst.

Es geht konkret wirklich nur um ContainerT::begin . Auf &ContainerT::begin bin ich auch schon gekommen, wie ich aber von einer Instanz des Methodenzeigers auf den Rückgabetypen dessen komme, ist mir schleierhaft.

Du spielst vermutlich auf diesen Thread an. Ich habe jetzt auf die Schnelle nichts gesehen zum Auslesen des Rückgabetypen.

Nathan

asfdlol schrieb:

camper schrieb:

Allgemeingültig wahrscheinlich gar nicht (begin könnte Defaultargumente haben). Praktisch ausreichend dürfte es sein, einfach &ContainerT::begin zu analysieren. Wenn begin pathologisch ist und einen Funktor darstellt, muss dann eben noch &ContainerT::begin::operator() untersucht werden. Hatten wir ja gerade erst.

Es geht konkret wirklich nur um ContainerT::begin . Auf &ContainerT::begin bin ich auch schon gekommen, wie ich aber von einer Instanz des Methodenzeigers auf den Rückgabetypen dessen komme, ist mir schleierhaft.

Der alte Spezialisierungstrick... , oh moment, geht ja nicht, wegen fehlden Varargs.
Edit: Fail, decltype gibts ja nicht.
Also nicht ganz allgemein:

template <typename Fnc>
struct get_return;

template <typename R, typename C>
struct get_return<R (C::*)()>
{
  // using... oh, kein using, C++03 ist irgendwie Mist
  typedef R type; // ich glaub so rum... typedef hab ich schon ewig nicht mehr benutzt
};

camper

asfdlol schrieb:

wie ich aber von einer Instanz des Methodenzeigers auf den Rückgabetypen dessen komme, ist mir schleierhaft.

Mir auch. War nicht ganz bei der Sache. decltype ist ja nicht ganz zufällig in die Sprache aufgenommen worden.

Fytch

Nathan schrieb:

template <typename Fnc>
struct get_return;

template <typename R, typename C>
struct get_return<R (C::*)()>
{
  // using... oh, kein using, C++03 ist irgendwie Mist
  typedef R type; // ich glaub so rum... typedef hab ich schon ewig nicht mehr benutzt
};

Und wie kann ich bei Fnc nun den Typen von &ContainerT::begin einsetzen? Braucht leider auch wieder decltype .

Edit:

camper schrieb:

decltype ist ja nicht ganz zufällig in die Sprache aufgenommen worden.

Naja, C++11 hat schon teilweise Sprachelemente eingeführt, die nur Syntax Sugar sind (mir fallen aus dem Stegreif gerade Range-Based-For-Loops und auto ein). Aber ich entnehme daraus, dass decltype nicht dazugehört (dessen war ich mir schon ziemlich sicher) die Möglichkeit das in C++03 zu implementieren nicht besteht, was?

Nathan

asfdlol schrieb:

Nathan schrieb:
template <typename Fnc>
struct get_return;

template <typename R, typename C>
struct get_return<R (C::*)()>
{
  // using... oh, kein using, C++03 ist irgendwie Mist
  typedef R type; // ich glaub so rum... typedef hab ich schon ewig nicht mehr benutzt
};
Und wie kann ich bei Fnc nun den Typen von &ContainerT::begin einsetzen? Braucht leider auch wieder decltype .

Jaja, sieh meinem Edit.

Edit:

camper schrieb:

decltype ist ja nicht ganz zufällig in die Sprache aufgenommen worden.

Naja, C++11 hat schon teilweise Sprachelemente eingeführt, die nur Syntax Sugar sind (mir fallen aus dem Stegreif gerade Range-Based-For-Loops und auto ein). Aber ich entnehme daraus, dass decltype nicht dazugehört (dessen war ich mir schon ziemlich sicher) die Möglichkeit das in C++03 zu implementieren nicht besteht, was?

Nein, aber gcc bspw. bietet ein typeof an.

happystudent

asfdlol schrieb:

Naja, C++11 hat schon teilweise Sprachelemente eingeführt, die nur Syntax Sugar sind (mir fallen aus dem Stegreif gerade Range-Based-For-Loops und auto ein).

Echt? Wie kann man das hier ohne auto implementieren?

template <typename iter>
auto sum(iter begin_, iter end_) -> typename std::remove_reference<decltype(*begin_)>::type
{
	using T = decltype(sum(begin_, end_));
	T tmp(0);
	while (begin_ != end_) {
		tmp += *begin_;
		++begin_;
	}
	return tmp;
}

Glaube zwar mal gelesen zu haben dass man auto immer mit einem passenden decltype ersetzen kann, aber hier wüsste ich nicht wie. Deswegen würde ich schon sagen das auto mehr als Syntax Sugar ist, oder?

Columbo

template <typename iter>
typename std::remove_reference<decltype(*std::declval<iter>())>::type sum(iter begin_, iter end_)

auto ist im Übrigen nicht nur Syntaxzucker. Wie wollt ihr sonst

auto x = []{};

schreiben?

happystudent

Ok, wieder was gelernt

Fytch

Diese auto f() -> decltype() -Geschichte ist AFAIK auch nur Syntaxzucker (Vermeidung von Redundanz), berichtige mich bitte einer wenn ich falsch liege. Das Hauptargument dafür war ja dass man Bereichsauflösungen nicht mehr angeben muss und dass man sich auf die Argumente beziehen kann. Ersteres dürfte mit ausschreiben möglich sein (mir fällt im Moment kein Fall ein bei dem das nicht geht, habe aber irgendetwas mit verschachtelten Klassentemplates dazu im Hinterkopf) und letzteres mit std::declval (was natürlich auch in C++03 implementierbar ist).

Arcoth schrieb:

auto ist im Übrigen nicht nur Syntaxzucker. Wie wollt ihr sonst
auto x = []{};
schreiben?

Hoppla, ja an Lambdas hab ich nicht gedacht, da hast du recht.

An die TMP-Pros hier:
Sind Variadic Templates Syntaxzucker wenn man von beliebig grossen Typlisten ausgeht?

Nathan

asfdlol schrieb:

An die TMP-Pros hier:
Sind Variadic Templates Syntaxzucker wenn man von beliebig grossen Typlisten ausgeht?

Jein.
Wenn man so etwas wie Alexandrescus Typelist hat mit beliebiger Anzahl an Erstellungsmakros kann man afaik alle Algorithmen auf Listen von Typen und so Dinge wie Tuples implementieren.
Was dann aber fehlt sind eine variable Anzahl an Parametern. Man muss dafür Tuple nehmen. Und auch Spezialisierungen für jede beliebige Funktion gehen dann nicht:

template <typename R, typename ... Arg>
struct foo<R(Arg...)> // wie ohne variadic templates?

Man muss das dann wieder für jede Anzahl an Argumenten spezialisieren.
Wenn man das aber außen vorlässt, dann ja, sind sie nur Syntaxzucker, allerdings einer von der Sorte, der sehr viel Redunanz spart.

happystudent

Arcoth schrieb:

auto ist im Übrigen nicht nur Syntaxzucker. Wie wollt ihr sonst
auto x = []{};
schreiben?

Moment, also das hier geht auch ganz ohne auto :

using lambda = void(*)();
lambda x = []{};

Also doch nur (sehr nützlicher) Syntax Sugar?

Nathan

happystudent schrieb:

Arcoth schrieb:
auto ist im Übrigen nicht nur Syntaxzucker. Wie wollt ihr sonst
auto x = []{};
schreiben?
Moment, also das hier geht auch ganz ohne auto :
using lambda = void(*)();
lambda x = []{};
Also doch nur (sehr nützlicher) Syntax Sugar?

Ja, aber sobald du etwas captures (?), gehts nicht mehr.

happystudent

Nathan schrieb:

Ja, aber sobald du etwas captures (?), gehts nicht mehr.

Hm, wie wärs dann mit:

std::function<void(void)> x = [=]{};

?

Das geht bei mir auf jeden Fall...

Columbo

Ja, aber sobald du etwas captures (?), gehts nicht mehr.

Stimmt schon, darauf wollte ich auch hinaus. Wenn du etwas capturest bekommt das closure-Objekt ja einen State.

Ich meine mich zu erinnern dass camper erwähnt hat dass auto ursprünglich für Lambdas eingeführt wurde.

Sind Variadic Templates Syntaxzucker wenn man von beliebig grossen Typlisten ausgeht?

Wie willst du ein Lambda eine variable Anzahl von Argumenten nehmen lassen?

[] (auto&&... a) {return f( std::forward<decltype(a)>(a)... );}

Bei gewöhnlichen Funktionstemplates oder Klassentemplates kann man zwar für jede Länge explizit spezialisieren, ist aber auch verdammt hässlich.

Columbo

Hm, wie wärs dann mit:
[..]

Ist viel langsamer. Wenn du dann noch das Objekt an ein Funktionstemplate übergibst (wie std::copy_if o.ä.), wird es deutlich lahmer, weil ständig der Umweg über function gemacht wird.

happystudent

Arcoth schrieb:

Ist viel langsamer. Wenn du dann noch das Objekt an ein Funktionstemplate übergibst (wie std::copy_if o.ä.), wird es deutlich lahmer, weil ständig der Umweg über function gemacht wird.

Hm, Ok.

Aber eigentlich ist ein Lambda ja auch nur Syntax Sugar weil man sich ja genausogut (und trivial) immer einen Functor mit der selben Funktionalität bauen kann.

Also braucht man auto eigentlich nur dann zwingend (= für nicht-Syntax Sugar) wenn man wiederum Syntax Sugar (nämlich ein Lambda) benutzen will. Somit wäre auto wiederum selbst nur Syntax Sugar.

Oder?

Columbo

Ne, genauso trivial garantiert nicht. Lambdas sind einfach irre sexy.

Boost.Lambda ist auch nett.

Im Prinzip hast du aber recht.

happystudent

Arcoth schrieb:

Ne, genauso trivial garantiert nicht. Lambdas sind einfach irre sexy.

Ja, das auf jeden Fall.

Arcoth schrieb:

Im Prinzip hast du aber recht.

Die eigentliche Frage wäre halt, wo Syntax Sugar anfängt bzw. aufhört.

Weil wenn man so argumentiert könnte man ja auch sagen dass templates auch nur Syntax Sugar sind und das ist dann glaube ich nicht mehr sinnvoll...

Nathan

happystudent schrieb:

Weil wenn man so argumentiert könnte man ja auch sagen dass templates auch nur Syntax Sugar sind und das ist dann glaube ich nicht mehr sinnvoll...

Fast alle C++-Features sind Syntax Sugar. Bis auf RAII, SFINAE, constexpr und decltype kann man alles in C nachimplementieren.
Und alles in C in Assembler. Und alles Assembler direkt als purer Machinencode.
Aller Programmiersprachen sind Syntax Sugar, das ist der Sinn von ihnen!