3. std::numeric_limits bei Initialisierung globaler Variable benutzen

std::numeric_limits bei Initialisierung globaler Variable benutzen

  • ?

    Sorry, war zu schnell. max() ist nicht static const. Sieht so aus, als wäre das in C++03 nicht erlaubt, erst in C++11 (dann ist max constexpr).

    0
  • S

    Oder seit C++11 auch damit erklärbar, dass die Funktionen constexpr sind. Das spricht für sich.

    Edit: Zu langsam...

    0
  • P

    Ok, da ich hier noch mit C++03 arbeite, scheint es also keine Garantie zu geben, dass das funktioniert. Vielen Dank.

    0
  • K

    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.

    0
  • S

    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.

    0
  • P

    knivil schrieb:

    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.

    0
  • D

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

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

    0
  • K

    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.

    0
  • M

    dd++ schrieb:

    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.

    0
  • ?

    Marthog schrieb:

    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.

    0
  • M

    das limit schrieb:

    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.

    0
  • S

    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.

    0
  • N

    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 .

    Sone schrieb:

    Ist auch beim Makro INT_MIN klar.

    Es geht um unsigned int .

    0
  • S

    Nexus schrieb:

    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.

    0
  • C
    Mod

    Sone schrieb:

    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

    0
  • S

    camper schrieb:

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

    0
Anmelden zum Antworten