C++ Template-Spezialisierung?

Theoretisch so:

1

template<typename T, bool B>

2

static inline T squareXX (const T &x);

3

4

template<typename T>

5

inline T squareXX<T, false> (const T &x)

6

{

7

    return x.square();

8

}

9

10

template<typename T>

11

inline T squareXX<T, true> (const T &x)

12

{

13

    return x * x;

14

}

ABER: Du kannst Funktionen nicht partiell spezialisieren.

So gehts:

1

template<typename T>

2

T squareX (const T &x)

3

{

4

    if constexpr(std::is_floating_point<T>::value) {

5

        return x * x;        

6

    }

7

    else {

8

        return x.square();

9

    }

10

11

}

Noch einfacher gehts mit constraints (ab gcc-6.2):

1

template<typename T>

2

requires std::is_floating_point<T>::value

3

T squareX(const T& x) {

4

    return x * x;

5

}

6

7

A squareX(const A& x) {

8

    return x.square();

9

}

Dr. Sommer schrieb:
> Über SFINAE werden die einzelnen Overloads aktiviert. Hat den Vorteil,
> dass man beliebig weitere Overloads für andere Arten von Typen (z.B.
> Integer, Klassen die kein .square() aber operator* haben, ...)
> hinzufügen kann, solange die Auswahl immer eindeutig ist. Dies wird
> möglich weil die zweite Variante auf die Existenz von .square() prüft,
> anstatt einfach alle nicht-float-Typen zu akzeptieren.

Und man braucht keinen C++17 Compiler, sollte das ein Kriterium sein.
"Schöner" is imho trotzdem die von Willhelm gepostete Variante.

Vincent H. schrieb:
> Dr. Sommer schrieb:
>> Über SFINAE werden die einzelnen Overloads aktiviert. Hat den Vorteil,
>> dass man beliebig weitere Overloads für andere Arten von Typen (z.B.
>> Integer, Klassen die kein .square() aber operator* haben, ...)
>> hinzufügen kann, solange die Auswahl immer eindeutig ist. Dies wird
>> möglich weil die zweite Variante auf die Existenz von .square() prüft,
>> anstatt einfach alle nicht-float-Typen zu akzeptieren.
>
> Und man braucht keinen C++17 Compiler, sollte das ein Kriterium sein.
> "Schöner" is imho trotzdem die von Willhelm gepostete Variante.

Wir haben Ende 2017: welchen Grund sollte es geben, kein C++17 zu 
verwenden?

Dr. Sommer schrieb:
> Noch eine Möglichkeit:
> [c]#include <utility>
> #include <type_traits>
>
> struct X {
>   X square () const { return {}; }
> };
>
> template <typename T>
> constexpr std::enable_if_t<std::is_floating_point<T>::value, T> square
> (const T& a) {
>   return a * a;
> }
>
> template <typename T>
> constexpr decltype (std::declval<const T> ().square ()) square (const T&
> a) {
>   return a.square ();
> }


Statt decltype(...) kann man ainfach auto für den Typ der Funktion 
schreiben.

constexpr nutzt nichts, da oben die Elementfunktion X::square() nicht 
constexpr ist (-> kein constexpr-Kontext).

Dr. Sommer schrieb:
> Vincent H. schrieb:
>> "Schöner" is imho trotzdem die von Willhelm gepostete Variante.
> Wenn sie so ausreichend ist, ja. C++ Programmierer mögen Overloads, weil
> man so für alle möglichen Typen unterschiedliches Verhalten definieren
> kann anhand relativ komplexer Kriterien, und außerdem noch später
> zusätzliche Varianten hinzufügen kann ohne die Original-Funktion zu
> ändern. So passiert das auch z.B. in der Standard-Library mit std::hash
> und std::begin.
>
> Wilhelm M. schrieb:
>> Wir haben Ende 2017: welchen Grund sollte es geben, kein C++17 zu
>> verwenden?
> z.B. der GCC-ARM-Embedded (offizieller GCC von ARM) kann C++17 nur
> teilweise, und eben kein "if constexpr"...

Wir reden in diesem Unter-Forum über not-embedded, oder?

Dr. Sommer schrieb:
> Vincent H. schrieb:
>> "Schöner" is imho trotzdem die von Willhelm gepostete Variante.
> Wenn sie so ausreichend ist, ja. C++ Programmierer mögen Overloads, weil

oder eben template-Spezialisierungen ...

SFINAE, um eine Funktion aus dem Overload-Set zu entfernen, gehört 
eigentlich der Vergangenheit an ... auch wenn concepts noch nicht 
generell verfügbar sind, sollte man sich darauf einstellen. Mit C++20 
haben wir dieses Mega-Feature!

Dr. Sommer schrieb:
> Wilhelm M. schrieb:
>> Statt decltype(...) kann man ainfach auto für den Typ der Funktion
>> schreiben.
> Aber dann trifft der Overload auf alle Typen zu, auch z.B. integer, und
> führt dann beim Aufruf zum Fehler. Somit wird ein zusätzlicher Overload
> für Integer unmöglich gemacht. Das decltype(...) stellt hier sicher,
> dass T eine Klasse ist und .square() kennt.

Ja, das stimmt. Sorry!

> Wilhelm M. schrieb:
>> Wir reden in diesem Unter-Forum über not-embedded, oder?
> Es könnte ja sein dass jemand so etwas auch auf Controllern nutzen will,
> da spricht ja nichts gegen.

Genau, z.B. auch AVR, wo es geht.

lalala schrieb:
> Noch als Anmerkung: Ich denke, dass bald der Stand erreicht ist, das man
> von C++11 als universellen Standard ausgehen kann. C++17 sehe ich so ab
> 2025.

Das sehe ich ganz und gar nicht so! Aber Prognosen sind immer schwierig, 
vor allem, wenn sie die Zukunft betreffen ;-)

Dazu solltest Du einen neuen Thread aufmachen ...

Sjarne Boustrup schrieb:
> Wilhelm M. schrieb:
>> Wir haben Ende 2017: welchen Grund sollte es geben, kein C++17 zu
>> verwenden?
>
> Ähm, C++17 ist erst in der DIS-Stage und stellt noch gar nicht "den"
> aktuellen offiziellen Standard dar (das ist momentan C++14).

Allerdings gab es keine Einwände zum DIS:

https://herbsutter.com/2017/09/06/c17-is-formally-approved/

so dass nur noch redaktionelle Änderungen vor der eigentlichen 
Veröffentlichung als ISO Std. notwendig sind. Also: das was wir momentan 
haben IST schon inhaltlich / technisch der offizielle Standard. Und die 
Arbeit an C++20 hat schon vor einiger Zeit begonnen.