Hi,

Im Moment siehts so aus, dass ich übers Netzwerk Daten geschickt bekomme. Die Socketklasse von C# (bzw dem .NET Framework) macht das ja alles über Byte-Arrays. Soweit ja in Ordnung. Allerdings will ich jetzt dieses Byte Array in ein struct kopieren, bzw das Array so interpretieren können.

Das ganze ist allerdings scheinbar nicht so einfach -.-
Ich habe keinen Move befehl o.ä. gefunden mit dem ich die Bytes einfach verschieben/kopieren kann und ein Pointer des structtyps auf dieses Array funktioniert auch nicht.

Also mein Quelltext (= Müll) sieht so aus:

markieren

Code:

public struct TPlayerState
{
   public UInt16 id;
   public int x;
   public int y;
   public UInt32 color;
}


// ...
  byte[] buff = new byte[14];
  // Daten in buff lesen
  TPlayerState* x = (TPlayerState*)(byte*)buff[0]; //<---- *
// ...

*)

Zitat:

Zeiger und Puffer mit fester Größe können nur in einem nicht sicheren Kontext verwendet werden.

Ich versteh das nicht. Abgesehn davon, dass ich bei C# Pointer noch nicht so ganz verstanden hab glaub ich.

Also

markieren

Code:

Typ* x;

=

var x: ^Typ;

markieren

Code:

x = *var;

=

x := @var; Stimmt das soweit? Und wie dereferenziert man in C#? Und was soll wie gesagt oben diese Meldung? -.-

In Delphi ist das alles unkomplizierter.....

C# ist managed code. Da gibt es keine Pointer. Dafür gibt es native Sprachen, wie Delphi oder C.

Zitat:

Zeiger und Puffer mit fester Größe können nur in einem nicht sicheren Kontext verwendet werden.

Das heißt, es ist eigentlich schlecht (das gepointere) und deshalb must du (wenn du wirklich willst) einen unsafe-Block drumherum legen

Unsafe Code würde ich in .NET versuchen zu vermeiden. Es geht praktisch immer ohne. Die Frage ist hier, ob du Einfluss auf das sendende Programm hast. Wenn ja, kannst du einfach auf beiden Seiten einen Standard-Serialisierungsmechanismus verwenden (in Java gibt es so etwas, mich würde es wundern, wenn das in .NET fehlte). Andernfalls kannst du die Daten manuell aus dem Byte-Array herausziehen. Ich bin mir ziemlich sicher, dass es noch einen direkten Weg gibt (es gibt schließlich sogar Attribute für die Struct-Ausrichtung), aber er fällt mir gerade nicht ein.

Hi,

Also letztendlich ist es mir egal, wie ich die Bytes in das struct Ding bekomme -.-

Hab Einfluss auf das Sendende Programm. Es ist ein Client, den ich in Delphi schreibe.
Was ist ein Standard-Serialisierungsmechanismus?

Klar könnte ich das ganze manuell ausm Array rausziehn, aber das ist doch viel zu umständlich und wenn mein Server mal viel zu tun hat, dann ist das doch unnötige Arbeit...

Aua!

.NET ist eine managed Runtime. Da hat man nicht mit Pointern zu arbeiten. Punkt. Dadurch, dass der Speicher von der Runtime verwaltet wird, hast Du nahezu gar keine Kontrolle darüber, wie ein Struct im Speicher aussieht. Das kann sich sogar je nach dem von einem Start der Applikation zum nächsten ändern. Anzunehmen, dass ein Struct ein bestimmtes Layout im Speicher hätte, ist in .NET grundlegend falsch (Insbesondere, wenn Du in C# einfach nur 'int' nimmst. Int ist nämlich zur Zeit ein Int32, kann aber ggf. auf 64bit Systemen je nach Optimierung auch auf einen Int64 mappen). Ausnahme: Du forcierst das über Attribute, aber das unterbindet dann zwangsläufig die Optimierung und kann hintenraus ordentlich performance kosten.

Du kannst den Code möglicherweise als unsafe deklarieren, aber damit kommst Du dann spätestens bei der CAS (Code Access Security) Probleme.

Schau Dir mal den Namespace System.Runtime.Serialization bzw. System.Runtime.Serialization.Formatters an. Da hats nen BinaryFormatter. Ich denke, das wäre der bessere Ansatz um Dein Struct aus dem empfangenen Stream zu füllen.

Und falls du doch darauf bestehst:

markieren

Code:

[StructLayout(LayoutKind.Sequential)]
public struct TPlayerState
{
   public UInt16 id;
   public int x;
   public int y;
   public UInt32 color;
}

// unsafe void MeineMethode
// ...
   byte[] buff = new byte[14];
   fixed(byte* xb = &(buff[0])) {
    TPlayerState* x = (TPlayerState*)xb;
   }
// ...

Aber Phoenix hat schon Recht. Wenn du die korrekten Serialization-Interfaces implementierst, kannst du das wunderbar ohne rumgepointere machen. Dazu gibt's im MSDN unter den entsprechenden Topics auch viele Beispiele

Mh...

Ohne Pointer ist doof.

Mal so nebenbei... Oder sollte man einen Server, der auch auf Linux laufen soll vielleicht doch eher mit C++ schreiben?

Wenn ich mir das hier so durchlese zweifel ich langsam daran, dass C# die richtige Sprache ist...

Zitat von Neutral General:

Mal so nebenbei... Oder sollte man einen Server, der auch auf Linux laufen soll vielleicht doch eher mit C++ schreiben?

Wenn ich mir das hier so durchlese zweifel ich langsam daran, dass C# die richtige Sprache ist...

Mono

Die Klassen aus System.Runtime.Serialization sind genau das, was ich mit einem Standard-Serialisierungsmechanismus meinte. Eine nicht-native Sprache benötigt schließlich auch irgendeinen Mechanismus, Objektinstanzen zu speichern, ohne dabei gleich unsafe zu werden. Bezüglich des direkten Wegs habe ich mich übrigens getäuscht. Das war eben jene Geschichte mit dem StructLayout-Attribut, und das verwendet man nur in Zusammenhang mit unsafe oder unmanaged Code.