C Code in C# Code konvertieren

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

1

typedef struct

2

{

3

    Header_t tHeader;

4

    uint8_t            au8Data[ 100 ];

5

}Tele_t;

einfach folgendes machst:

1

class Tele_t

2

{

3

    Header_t tHeader;

4

    uint8_t            au8Data[ 100 ];

5

};

Das muss dann sowas in der Art werden:

1

using Microsoft.Win32.SafeHandles;

2

using System;

3

using System.Runtime.InteropServices;

4

5

 [StructLayout(LayoutKind.Sequential, CharSet = CharSet.None)]

6

        [BestFitMapping(false)]

7

        internal unsafe struct Tele_t

8

{

9

        Header_t tHeader;

10

        [MarshalAs(UnmanagedType.U1, SizeConst = 100)]

11

        string au8Data;

12

};

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

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.

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.

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.