C Code in C# Code konvertieren

[Techniker (Gast)]

Hallo,

eine bestehende Anwendung in C soll in C# konvertiert werden. Wie setzt 
man den folgenden C Code in C# um?

typedef uint16_t Types;

typedef struct TEST
{
    uint16_t u16Variable1;
    uint16_t u16Variable2;
    uint16_t u16Variable3;
}T_TEST;

static const T_TEST TEST_ZERO = { 0,0,0 };

typedef struct Header_TAG
{
    uint16_t      u16Value;
    T_TEST        tTEST;
    Types         u16Frametype;
    uint32_t      u32Count;
}Header_t;

#define HEADER ( sizeof( Header_t ) - 2 )

typedef struct
{
    Header_t tHeader;
    uint8_t            au8Data[ 100 ];
}Tele_t;

[Peter II (Gast)]

Techniker schrieb:
> Wie setzt
> man den folgenden C Code in C# um?

gar nicht.

Es ist überhaupt keine code da den man umsetzen müsste.

Das sind nur ein paar typedef die man so in C# nicht verwendet. Wichtig 
ist der code der die typedef verwendet.

[Der Andere (Gast)]

Indem man aus Structs Klassen macht.
Im Unterricht gepennt und jetzt brauchst du die Hausaufgabe?

[Chris F. (chfreund)]

Wenn Du willst, dass es POD-structs sind, die auch so verarbeitet werden 
reicht es nicht aus wenn Du aus:

typedef struct
{
    Header_t tHeader;
    uint8_t            au8Data[ 100 ];
}Tele_t;

einfach folgendes machst:

class Tele_t
{
    Header_t tHeader;
    uint8_t            au8Data[ 100 ];
};

Das muss dann sowas in der Art werden:

using Microsoft.Win32.SafeHandles;
using System;
using System.Runtime.InteropServices;

 [StructLayout(LayoutKind.Sequential, CharSet = CharSet.None)]
        [BestFitMapping(false)]
        internal unsafe struct Tele_t
{
        Header_t tHeader;
        [MarshalAs(UnmanagedType.U1, SizeConst = 100)]
        string au8Data;
};

[Peter II (Gast)]

Chris F. schrieb:
> Das muss dann sowas in der Art werden:

was aber nicht sehr sinnvoll ist. Man sollte keine 1:1 Umsetzung von dem 
Code machen. In C# Programmiert man etwas anders als in C.

[Chris F. (chfreund)]

Peter II schrieb:
> Chris F. schrieb:
>> Das muss dann sowas in der Art werden:
>
> was aber nicht sehr sinnvoll ist. Man sollte keine 1:1 Umsetzung von dem
> Code machen. In C# Programmiert man etwas anders als in C.

Dann ist ja alles in Ordnung, da der TO nicht gefragt hatte ob meine 
Version der 1:1 Umsetzung sinnvoll ist, sondern wie diese aussieht. Er 
hatte auch nicht gefragt ob Code der Typdefinitionen einsetzt wichtiger 
ist als die Typdefinitionen selber (die auch Programmcode sind):

Danke, dass Du das nochmal bestätigt hast. :-)

[Techniker (Gast)]

Ok vielen Dank für eure Beiträge.

[Horst (Gast)]

Techniker schrieb:
> C Code in C# Code konvertieren

Wie kommt man auf so eine wahnsinnige Idee???

[Der Andere (Gast)]

Chris F. schrieb:
> Dann ist ja alles in Ordnung, da der TO nicht gefragt hatte ob meine
> Version der 1:1 Umsetzung sinnvoll ist, sondern wie diese aussieht.

Nö, er hat gesagt/behauptet daß eine komplette Anwendung portiert werden 
soll.
Sowas macht man NIE 1:1 sondern portiert sinnvoll.
Allenfalls schreibt man einen Konverter der das 1:1 übersetzt, aber der 
entstehende Code ist dann unwartbar.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Horst schrieb:
> Wie kommt man auf so eine wahnsinnige Idee???

Entweder geht man von der völlig irrigen Annahme aus, dass durch die 
rein formale Konvertierung von einer Programmiersprache in eine andere 
aus einer sperrigen textbasierten Anwendung plötzlich eine bunte, schöne 
Klickibunti-App werde. Oder man kennt tatsächlich die möglichen 
Einschränkungen und muss tatsächlich recht isolierten Code, der z.B. 
bestimmte Berechnungen durchführt, übersetzen, was durchaus sinnvoll 
sein kann. In der Praxis stellt man dann aber fast immer sehr schnell 
fest, dass irgendwelche internen Datenstrukturen oder Besonderheiten 
einer Programmiersprache doch nicht so trivial zu übersetzen sind und 
größere Konzeptänderungen bedeuten. Und viel später stellt man dann 
fest, dass die Neuerstellung doch einfacher gewesen wäre.

Ich selbst hatte zu Beginn meines Studiums auch in grenzenloser Naivität 
angenommen, dass sich eine größere Sammlung von Rechenprogrammen, die in 
ALGOL 68 für eine DEC-10 geschrieben waren, mit ein bisschen lex und 
yacc in PASCAL für VAX/VMS und Turbo Pascal konvertieren ließen. Keines 
dieser Programme wurde jemals fertig.

[fpga (Gast)]

Es gibt sehr wohl struct auch in c#:

https://msdn.microsoft.com/de-de/library/ah19swz4.aspx

Gruß J

[Rufus Τ. F. (rufus) (Moderator)]

Sofern diese C-Strukturen Dinge wie z.B. den Inhalt von Dateien* 
beschrieben und mit einfachen Dateioperationen als Block gelesen werden, 
wird eine Umsetzung auf das, was C# anstelle von Strukturen bietet, sehr 
interessante Nebeneffekte mit sich bringen, die mit hoher 
Wahrscheinlichkeit recht gründlich dafür sorgen, daß sich das 
"umgesetzte" Programm zu funktionieren weigert.


*) oder seriell übertragene Daten, oder per Netzwerk übertragene Daten, 
oder Daten, die als Blob aus einer Datenbank kommen, oder welchen, die 
in einem (E)EPROM gespeichert sind ... der Möglichkeiten sind viele.

[Chris F. (chfreund)]

Rufus Τ. F. schrieb:
> was C# anstelle von Strukturen bietet, sehr
> interessante Nebeneffekte

Daher macht es auch Sinn hier die POD-Strukte 1:1 nachzubauen. Es geht 
offensichtlich um statische Protokollstrukturen die zur externen 
Übergabe an andere Prozesse gedacht sind.

struct ist in C++ ein class mit "default public", dort muss man schon 
mit byte-alignment aufpassen, ist aber noch gut dabei, da nativer Code 
generiert wird.

Ein C++-Compiler wird quasi immer Objektcode generieren der die Daten 
einer Instanz einer Klasse in der selben Reihenfolge wie deklariert 
speichert.

In C# kommt die volldynamische Speicherverwaltung der .net-runtime-vm 
dazu.

[Peter II (Gast)]

Chris F. schrieb:
> Daher macht es auch Sinn hier die POD-Strukte 1:1 nachzubauen. Es geht
> offensichtlich um statische Protokollstrukturen die zur externen
> Übergabe an andere Prozesse gedacht sind.

es macht für mich eigentlich NIE sinn, so etwas nachzubauen weder unter 
C noch unter C#. Man macht jeweils Methoden die die interne 
Repräsentation und den Datenstrom konvertieren.

Damit kann man auch optionale Felder im Protokoll abbilden. Und es gibt 
keine Probleme wenn sich das Protokoll ändert.