//"Bit gefrickel"
unsigned long long get_size() const
{
    return (static_cast<unsigned long long>(wfd.nFileSizeLow) & (static_cast<unsigned long long>(wfd.nFileSizeHigh)<<32u));
}

//Das Selbe mit Addition
unsigned long long get_size() const
{
    return (static_cast<unsigned long long>(wfd.nFileSizeLow) + (static_cast<unsigned long long>(wfd.nFileSizeHigh)<<32u));
}

//über pointer
unsigned long long get_size() const
{
    return *(reinterpret_cast<const unsigned long long*>(&wfd.nFileSizeLow);
}

//über memcpy
unsigned long long get_size() const
{
    unsigned long long tmp;
    memcpy(tmp, wfd.nFileSizeLow, sizeof(unsigned long long);
    return tmp;
}

Ich würde aber ein typedef benutzen, ala typedef unsigned long long size64_t;

UInt64 filesize=(UInt64(wfd.nFileSizeHigh)<<32)|wfd.nFileSizeLow;

UInt64 filesize=((UInt64)nFileSizeHigh * ((UInt64)MAXDWORD+1)) + (UInt64)nFileSizeLow.

Was haltet ihr davon?

In der MSDN wird diese Methode vorgeschlagen

UInt64 filesize=((UInt64)nFileSizeHigh * ((UInt64)MAXDWORD+1)) + (UInt64)nFileSizeLow.

Was haltet ihr davon?

Das mag ich auch. Der Compiler wird schon bistshift und bitwise or draus machen. Allerdings ziehe ich die functional stype casts den c-cats vor, da hab ich irgendwie schneller Übersicht, was genau gecastst wird.

UInt64 filesize=(UInt64(nFileSizeHigh) * (UInt64(MAXDWORD)+1)) + UInt64(nFileSizeLow).

Warum nicht gleich static_cast?

@Stily:
Die MSDN Variante ist IMO die beste, weil am besten/einfachsten verständlich. Und wie volkard schon sagte, wird jeder vernünftige Compiler im Release-Build nen Shift aus der Multiplikation machen, womit die MSDN Variante auch gleich schnell wie alles andere sein dürfte.

@volkard: die Function-Style-Casts sind gleichbedeutend mit C-Style Casts. D.h. die können auch reinterpretieren (und const casten) - was ich nicht so toll finde.

Ist in diesem Fall (und vielen anderen) völlig irrelevant, fürchte ich.

hustbaer schrieb:

Noch schlimmer: da sie wie ein Ctor aussehen, wissen das viele Leute nicht, und vermuten, fälschlicherweise dass die Function-Style-Casts "sicher" sind (wie static_cast es wäre).

Naja, Du wirst einsehen, daß ich aus rein praktischen Erwägungen diesen cast nicht so oft mit Zeigern und Referenzen machen.

i=int*(p);//comiler lacht

Dieser Cast aber allein mit Objekten (nicht Zeigern/Referenzen) ausgeführt, verliert schon die Gefährlichkeit. Auch passiert er nicht bei Zuweisungszielen

char(i)=3;//compiler lacht

hustbaer schrieb:

Warum nicht gleich static_cast?

Weil die Angst völlig übertrieben ist und weil ich mir ungefährlichen Code ungern mit Gefahrenschildern vollspamme.

int i = 2;
	int* p = &i;
	size_t j = size_t(p); // compiler schweigt, programmierer weint.

genauso wirst du vermutlich wissen, dass es in C++ sowas wie typedefs gibt.

PULONG p2 = PULONG(123); // compiler schweigt weiterhin, nichtmal ne warning...

Weil die Angst völlig übertrieben ist und weil ich mir ungefährlichen Code ungern mit Gefahrenschildern vollspamme.

es geht ja gerade darum, sich garnicht erst anzugewöhnen, bestimmte dinge zu schreiben, auch wenn man denkt es sei ungefährlich.
gerüchteweise soll es nämlich vorkommen, dass menschen fehler machen. und dann denken die - gerüchteweise - auch mal etwas sei ungefährlich, was es garnicht ist.
-> der compiler schweigt, der programmierer weint

vollkommen unnötigerweise.

daher schreibe ich grundsätzlich nirgends mehr c-style casts, und auch keine function-style casts. die 13 zeichen mehr platz für einen static_cast sind doch wirklich kein problem.