ist es vom C++-Standard her safe, bei der Initialisierung einer globalen Variable die Klasse std::numeric_limits zu benutzen, d.h. zB

int global_val = std::numeric_limits<int>::max();

so im Code zu schreiben (als globale Variable). Meine GCC-Implementierung gibt hier einfach das Makro __DBL_MAX__ zurück, was ja zur Compile-Zeit ersetzt wird und daher safe ist. Nun frage ich mich, ob das implementierungsunabhängig immer korrekt ist. Schließlich kann ich mich im Allgemeinen ja nicht darauf verlassen, dass statische Funktionen einer Klasse schon sinnvolle Werte zurückgeben, wenn meine globale Variable initialisiert wird (weil sie zB auf andere globale Variablen zugreifen könnten, die noch nicht initialisiert sind). Kann man im speziellen Fall von numeric_limits doch davon ausgehen (aus irgendeinem Grund) oder ist obiger Code nicht standard-konform?

MfG plizz

For all members declared static const in the numeric_limits template, specializations shall define these values in such a way that they are usable as integral constant expressions.

Edit: Zu langsam...

dass statische Funktionen einer Klasse schon sinnvolle Werte zurückgeben, wenn meine globale Variable initialisiert wird

Warum nicht, es sind Funktionen. Wenn du hier auf das Problem der Initialisierungsreihenfolge bei globalen Variablen ansprichst ... das ist der Grund, warum es Funktionen sind und nicht etwa nur Konstanten.

Wenn du hier auf das Problem der Initialisierungsreihenfolge bei globalen Variablen ansprichst ... das ist der Grund, warum es Funktionen sind und nicht etwa nur Konstanten.

Es gibt mit Konstanten (die mit bspw. Literalen initialisiert werden) hier kein Problem bei constant initialization.

dass statische Funktionen einer Klasse schon sinnvolle Werte zurückgeben, wenn meine globale Variable initialisiert wird

Warum nicht, es sind Funktionen. Wenn du hier auf das Problem der Initialisierungsreihenfolge bei globalen Variablen ansprichst ... das ist der Grund, warum es Funktionen sind und nicht etwa nur Konstanten.

Ich grabe das hier nochmal aus. Natürlich sind es Funktionen und die werden wohl auch richtig aufgerufen. Aber ich kann im Allgemeinen ja nicht davon ausgehen, dass diese Funktionen nicht auf irgendwelche anderen globalen Variablen zurückgreifen, die vielleicht zum Zeitpunkt des Funktionsaufruf noch nicht initialisiert sind. Falls hier irgendwelche Konstanten, die schon zur Compile-Zeit ersetzt werden, zurückgegeben werden, habe ich natürlich kein Problem. Aber das kann ich ja nicht wissen, ohne in die konkrete Implementierung der Funktion zu schauen, die ich aufrufe.

http://en.cppreference.com/w/cpp/header/climits

Aber ich kann im Allgemeinen ja nicht davon ausgehen, dass diese Funktionen nicht auf irgendwelche anderen globalen Variablen zurückgreifen

Doch, kannst du, weil es sonst keinen Sinn mancht sie in Funktionen zu verpacken. Wenn andere globale Variablen benoetigt warden, dann sind sie auch in einem Funktionsaufruf verpackt.

sowohl in C++03 als auch in in C++11 gibt es alternativ <climits>

http://en.cppreference.com/w/cpp/header/climits

Wobei man sich schon in C++03 mit den Konstanten zurückhalten und sie in C++11 gar nicht mehr verwenden sollte.

Wobei man sich schon in C++03 mit den Konstanten zurückhalten und sie in C++11 gar nicht mehr verwenden sollte.

Wieso? Die "C++-Variante" ist viel schreibaufwändiger und hat in Nicht-template-Code keinerlei Vorteile, sondern lenkt im Gegenteil vom Wesentlichen ab.

Die "C++-Variante" ist viel schreibaufwändiger und hat in Nicht-template-Code keinerlei Vorteile, sondern lenkt im Gegenteil vom Wesentlichen ab.

Das sehe ich nicht so. Sie ist zwar länger, das heißt aber nicht dass sie schlechter ist.

Vorteile:
- Verwendbar bei templates oder mit decltype -> einheitlich
- Es ist übersichtlich, welchen Sinn der Wert hat, so ist z.B. bei

std::numeric_limits<unsigned int>::min()

klar, dass man den kleinsten Wert von unsigned int will, würde man nur 0 hinschreiben, wäre das nicht so klar.

Verwendbar bei templates oder mit decltype -> einheitlich

Beides keine Vorteile. Makros sind Text-Wergzeuge. Am Ende steht da nur ein Literal des entsprechenden Typs, das funktioniert auch wunderbar mit decltype & co.

dass man den kleinsten Wert von unsigned int will

Ist auch beim Makro INT_MIN klar.

Sie ist zwar länger, das heißt aber nicht dass sie schlechter ist.

Vorteil ist auch, dass die Typen 1:1 geschrieben werden. Also nicht etwa SHRT für short .

Sone schrieb:

Ist auch beim Makro INT_MIN klar.

Es geht um unsigned int .

Marthog schrieb:

Sie ist zwar länger, das heißt aber nicht dass sie schlechter ist.

Vorteil ist auch, dass die Typen 1:1 geschrieben werden. Also nicht etwa SHRT für short .

Ich finde die Schreibweise von numeric_limits natürlich auch besser. Weil der Typ da so schön steht, als Template-Argument.

Nexus schrieb:

Sone schrieb:

Ist auch beim Makro INT_MIN klar.

Es geht um unsigned int .

Dann schreibt man eben 0 hin und macht ein Kommentar.

Weil der Typ da so schön steht, als Template-Argument.

Der ist allerdings redundant, wenn er schon bei der Deklaration der Variablen angebene wurde.

Also

int foo = std::numeric_limits<decltype(foo)>::max(); // oder
auto bar = std::numeric_limits<int>::max();

Ganz nebenbei erfordert das die Verwendung einer vernünftigen Initialisierungssyntax :p

:p

Seit wann benutzt du solch' vulgäre Smileys?

Der ist allerdings redundant, wenn er schon bei der Deklaration der Variablen angebene wurde.

Darum geht es mir gar nicht, nur die Schreibweise an sich finde ich schön.

Und natürlich hast du Recht - man sollte versuchen, eine entsprechende, möglichst wenig redundante Initialisierungssyntax zu verwenden.