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

[Vlad T. (vlad_tepesch)]

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:

    m_min = std::numeric_limits<T>::max();
    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

[ich (Gast)]

Also bei mir ist std::numeric_limits<float>::min(); als:

static _GLIBCXX_CONSTEXPR float 
min() throw() { return __FLT_MIN__; }

definert und

__FLT_MIN__

 ist:

#define __FLT_MIN__ 1.17549435082228750797e-38F

sollte soweit also passen.

Mit:
libstdc++ und gcc = Version: 4.6.3

[ich (Gast)]

Sorry passt natürlich nicht. Es ist der kleinste darstellbare float Wert 
und nicht der kleinste negative Wert.

[ich (Gast)]

Was du suchst heißt bei float und double:

std::numeric_limits<float>::lowest();

Was zugegebenermaßen etwas verwirrend ist.

[Vlad T. (vlad_tepesch)]

hm - ok danke, das lowest war mir neu, stand in der Referenz die ich 
vorhin zu Rate gezogen hatte auch nicht drin.
scheint es erst ab c++11 zu geben, aber das VS2010 unterstützt es 
immerhin.

kann ich meinen hässlichen Workaround also doch wieder rausschmeißen.

[ich (Gast)]

wobei mir gerade aufgefallen ist, dass in meiner Version lowest() noch 
mit

#ifdef GXX_EXPERIMENTAL_CXX0X

 versehen ist. Du scheinst also nicht der Erste zu sein, der dieses 
Problem hatte.

[Matthias H. (experimentator)]

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:

#include <string>
using namespace std;

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...
string richtig(1,'X');   // Erzeugt mit 'X' gefüllten String der Länge 1.

[Peter II (Gast)]

Matthias H. schrieb:
> Mein "Lieblings-Schönheitsfehler" der STL ist, wie man Strings mit einem
> Char initialisiert, nämlich so:
> #include <string>
> using namespace std;
> string falsch('X');
> string richtig(1,'X');

gcc liefert:
error: invalid conversion from 'char' to 'const char*'

[Vlad T. (vlad_tepesch)]

Peter II schrieb:
> error: invalid conversion from 'char' to 'const char*'

da scheint deinem gcc der
string(int, char=0) konstruktor zu fehlen, oder warum kommt bei dir der 
Fehler?

[Peter II (Gast)]

Vlad Tepesch schrieb:
> da scheint deinem gcc der
> string(int, char=0) konstruktor zu fehlen, oder warum kommt bei dir der
> Fehler?

keine ahnung, aber hier ist er auch nicht erwähnt

http://www.cplusplus.com/reference/string/string/string/

[Vlad T. (vlad_tepesch)]

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

[Klaus W. (mfgkw)]

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