cast byte[4] to float

hallo!

sollte ja eigentlich ganz einfach sein... bekomms allerdings nicht wirklich hin - nur eine System.NullReferenceException.
float hat ja 4 bytes, also sollte ein simpler cast (unsafe) doch funktionieren:

unsafe
{
byte [] buf  = r.ReadBytes(4); 
float f = *((float *) buf[0]); // das da
}

was ist falsch dran?
weiss schon, man könnte das ganze auch ohne unsafe machen... aber wozu? 😉
(das ganze hat übrigens den sinn, ev. die byte-order zu vertauschen)
also, für hinweise dankbar,
somran

Hallo somran,

aber wozu? 😉

vielleicht um solche Fehler zu vermeiden??

Ich würde es unbedingt im "safe"-code probieren. Auch das verdrehen der Byte-Order ist kein Problem mit managed code.

Das Ganze kannst Du mit Hilfe der beiden Klassen BitConverter und Convert erledigen.

Habe ähnliches auch mal realisiert, das war allerdings zu meinen C#-Anfangszeiten...

Ciao
Norman-Timo

unsafe sollte man vermeiden wenn immer es geht. Wozu? Ggf. ist die CAS restriktiv und erlaubt nur managed Code.

BitConverter.ToSingle() bringt es (float ist C++, nicht C#).

besten dank! 🙂

BitConverter funkt natürlich.
aber da ich eben relativ wenig mit c# mache (komme von c++ seite 😉 ), kenn ich die ganzen hilfsklassen (noch) nicht.

natürlich habt ihr recht damit, dass man möglichst auf unsafe-blöcke verzichten sollte, aber das geht halt auch nicht immer... (v.a. wenns wirklich um performance geht)

abgesehn davon, würde der unten genannte code in c++ funktionieren?

Prinzipiell ist das vom Ansatz möglich, dein Code tuts allerdings nicht. Wenn dann so:

float f = *((float *) &buf[0]); // das da

Hallo somran,

aber das geht halt auch nicht immer... (v.a. wenns wirklich um performance geht)

Wenn es WIRKLICH um Performance geht (und wir reden hier von Millisekunden), dann sollte man sich sowieso überlegen, ob man .NET verwendet.

Prinzipiell lässt sich aber auch mit .NET sehr performant programmieren. Ein anderer Aspekt ist auch die performante Erstellung des Codes, wo 'damals' mit C++ man fast einen Handstand machen musste, da gibt es sehr viele Basisklassen aus dem Framework, die sehr gut umgesetzt sind.

Ciao
Norman-Timo

danke!

@svenson:
natürlich &! ist mir ja fast peinlich... 😉

@norman_timo:
klar, echte echtzeitanwendungen würde ich sowieso nicht mit .NET machen (wenns wirklich um millisekunden geht)
allerdings kommts ja nur drauf an, wie oft eine operation durchgeführt wird, da kann (muss) man sich auch bei verwendung von .NET (hat ja auch seine vorteile 😉 ) manchmal mit unsafe behelfen...
(wenns nicht auf die reaktionsgeschwindigkeit ankommt, sondern "nur" darauf dass ein task deutlich schneller abgearbeitet werden kann)

btw: kennt wer exakte performance-vergleiche zw. c++ und c#? (ev. aus eigener erfahrung?)
soviel ich weiss, gehts da nur so um 10% (mit .NET)...
aber das ist wohl thema für einen anderen thread (gibts wahrscheinlich sogar schon ein paar... mal schauen)

somran

Und wie wär`s mit C++/CLI ?
Das Beste aus beiden Welten. Mischen von managed und native Code
in der selben Assembly.

Ich denke, man sollte schon darauf achten, wenn möglich nur managed Code zu generieren. Wegen ein paar µs Ausführungszeit Probleme mit der CAS zu riskieren macht wohl wenig Sinn. Managed Code mag manchmal notwendig sein, aber als Optimierungsmaßnahme im (höchst seltenen) Fall der Fälle.

Original von svenson
Managed Code mag manchmal notwendig sein, aber als Optimierungsmaßnahme im (höchst seltenen) Fall der Fälle.

Du meinst sicher unmanaged 😉

btw: kennt wer exakte performance-vergleiche zw. c++ und c#? (ev. aus eigener erfahrung?)

Es gibt keine ernst zu nehmenden Tests in dieser Richtung, weil die Un-
genauigkeiten solcher Tests größer sind, als der letzliche Performance-
Unterschied. Zudem ist die Performance sehr abhängig von der Aufgaben-
stellung. D.h. wo kann die Laufzeit-Optimierung ihre Stärken ausspielen
und wo belastet sie eher?

Für normale Anwendungsprogramme ist der Unterschied auf jeden Fall
vollkommen irelevant.

Original von Programmierhans

Original von svenson
Managed Code mag manchmal notwendig sein, aber als Optimierungsmaßnahme im (höchst seltenen) Fall der Fälle.

Du meinst sicher unmanaged 😉

Ähem, sicher! 😉