c++ spec bug std::numeric_limits::min

OP #2785698
Lesenswert?
• ▲
▼
So muss jetzt mal Frust ablassen, nachdem ich eine geschlagene halbe 
Stunde diesen Bug gesucht habe.

Ich hab eine Template-Klasse, die über Daten Statistik bilden soll.

Für ordinale Datentypen alles ok, nur für Gleitkomma gehts nicht.

Bis ich auf den Trichter gekommen bin, dass die Minima, 
Maxima-Bestimmung Mist liefert ...

Da Templates-Basis-Typ hab ich natürlich die numeric_limits zur 
Initialiserung der min-max variablen benutzt:
1
    m_min = std::numeric_limits<T>::max();
2
    m_max = std::numeric_limits<T>::min();
Nur ist für std::numeric_limits<float>::min(); ganz anders spezifiziert, 
als man erwarten würde, nämlich als eine Art Epsilon.


Ich frag mich, wer sich das ausgedacht hat.

Nun müsste man abhängig vom T-Parameter std::numeric_limits<T>::min() 
für ordinale Datentypen und  -std::numeric_limits<T>::max(); für 
Gleitkomma-Typen benutzen, was das ganze Konzept der numeric_limits in 
ad absurdum führt.


kennt jemand noch andere derartige Fallen?

Gruß
Vlad
Gast #2785814
Lesenswert?
• ▲
▼
Also bei mir ist std::numeric_limits<float>::min(); als:
1
static _GLIBCXX_CONSTEXPR float 
2
min() throw() { return __FLT_MIN__; }

definert und
1
__FLT_MIN__
 ist:
1
#define __FLT_MIN__ 1.17549435082228750797e-38F

sollte soweit also passen.

Mit:
libstdc++ und gcc = Version: 4.6.3
#2785894
Lesenswert?
• ▲
▼
Templates sind eigentlich nur ein hochentwickelter Makromechanismus, so 
etwas ist inhärent sehr zerbrechlich. Ein Template, das für ordinale 
Datentypen funktioniert, funktioniert noch lange nicht immer für 
Fließkommatypen, Strings oder andere komplexere Datentypen (obwohl es 
erstaunlich oft funktioniert, wenn die Templates und Datentypen 
ausreichend deklariert sind, z. B. letztere mit Vergleichsoperatoren für 
komplexe Datentypen, ...).

Mein "Lieblings-Schönheitsfehler" der STL ist, wie man Strings mit einem 
Char initialisiert, nämlich so:
1
#include <string>
2
using namespace std;
3

4
string falsch('X');      // Erzeugt keine Warning und bestenfalls eine Fehlfunktion, meistens einen Absturz - anscheinend wird der Konstruktor für einen NUL-terminierten C-String aufgerufen...
5
string richtig(1,'X');   // Erzeugt mit 'X' gefüllten String der Länge 1.
OP #2786215
Lesenswert?
• ▲
▼
doch allerdings mit uint
> string ( size_t n, char c );

edit: achso, da ist kein default.

hmm- keine Ahnung, vielleicht irrt sich der experimentator auch.
der MS VSC2010 gibt auch eine Fehlermeldung aus

Ich hatte vor kurzem auf jeden Fall auch einen Fall, wo er statt dem, 
was ich wollte, einen String mit Füllzeichen erzeugt hatte. war aber 
QString
#2787126
Lesenswert?
• ▲
▼
Matthias H. schrieb:
> Ein Template, das für ordinale
> Datentypen funktioniert, funktioniert noch lange nicht...

Das hat aber alles nichts mit den Limits für die Datentypen zu tun.
Da ist das Template nämlich nur das formale Gerüst, und muß für jeden 
Typ sinnvoll durch eine Spezialisierung definiet werden (ähnlich wie 
eine ABC, die überschrieben werden muß).

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren