bekannt ist ja z.B. der folgende ADL-Trick mit swap :

template<typename T>
void Swap(T& Lhs, T& Rhs)
{
	using std::swap;
	swap(Lhs, Rhs);
}

Natürlich gibt ein swap eigentlich nichts zurück, das soll nun aber nur stellvertretend stehen für jede beliebige Funktion, die etwas zurückgibt und diesen ADL-Trick benutzt.
Die Frage ist nun jedoch, wie dasselbe Lookup-Verhalten beim Rückgabetypen in C++03 erreicht werden kann. In C++11 habe ich es (quick 'n' dirty) hinbekommen (ich frage mich jedoch was geschieht / geschehen sollte, wenn jemand std::swap in den globalen Namensraum holt):

template<typename T>
struct HasCustomSwap
{
	template<typename U>
	static al::TrueType Check(decltype(swap(std::declval<T>(), std::declval<T>()))*);

	template<typename U>
	static al::FalseType Check(...);

	static const bool Value = sizeof(Check<T>(0)) == sizeof(al::TrueType);
};

template<typename T, bool Custom = HasCustomSwap<T>::Value>
struct SwapRet;

template<typename T>
struct SwapRet<T, true>
{
	typedef decltype(swap(std::declval<T>(), std::declval<T>())) Type;
};

template<typename T>
struct SwapRet<T, false>
{
	typedef void Type; // Der Rückgabetyp von std::swap
};

template<typename T>
typename SwapRet<T>::Type SwapClone(T& Lhs, T& Rhs)
{
	using std::swap;
	return swap(Lhs, Rhs);
}

Und wenn ich schon einen Thread aufgemacht habe, dann noch gleich was anderes:
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;
};

Ich habe daran rumgebastelt aber bin leider nicht vom Fleck gekommen.

Gruss

? :p

template<typename ContainerT>
struct BeginT
{
    typedef typename ContainerT::iterator Type;
};
template<typename ContainerT>
struct BeginT<const ContainerT>
{
    typedef typename ContainerT::const_iterator Type;
};

Das Problem ist jedoch, dass ich bei gewissen Container die Methode begin definiere (damit Range-Based-For-Loops funktionieren), der Rest (und somit auch die Iteratortypen) jedoch mein gewohntes PascalCase ist, womit diese Lösung dann leider nicht funktioniert.
Wenn es nicht geht, so könnte ich alternativ noch sowas wie ContainerTraits basteln, dann funktionieren aber z.B. Container aus Boost nicht ohne Weiteres.

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.

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.

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

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.

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 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.

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?

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

auto x = []{};

schreiben?

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?

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.

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?

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.

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...

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.

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.

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?

Boost.Lambda ist auch nett.

Im Prinzip hast du aber recht.

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...

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!

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!

Ja, schon

Aber dann ist der Begriff Syntax Sugar halt auch völlig sinnentleert und sagt letztendlich gar nichts aus.

• Der Ausdruck ist ein konstanter Ausdruck (Irgendein Zeiger, Integral oder Enumerator) und wird an ein Template als non-type-Argument übergeben.
• Es wird sizeof auf den Ausdruck angewandt - und dann Schritt 1.

Durch den zweiten Punkt wird BOOST_TYPEOF realisiert.

Es ist also leider unmöglich so etwas einfach und portabel in C++03 umzusetzen.

* Damit ist eine expression gemeint wie sie in der Standardgrammatik definiert ist.