_Marshallattribut "wire"
Das [ Wire _ ] Marshal-Attribut gibt einen Datentyp an, der für die Übertragung (wire-type) anstelle eines anwendungsspezifischen Datentyps (userm-type) verwendet wird.
typedef [wire_marshal(wire_type)] type-specifier userm-type;
unsigned long __RPC_USER < userm-type >_UserSize(
unsigned long __RPC_FAR *pFlags,
unsigned long StartingSize,
< userm-type > __RPC_FAR * pUser_typeObject );
unsigned char __RPC_FAR * __RPC_USER < userm-type >_UserMarshal(
unsigned long __RPC_FAR * pFlags,
unsigned char __RPC_FAR * Buffer,
< userm-type > __RPC_FAR * pUser_typeObject);
unsigned char __RPC_FAR * __RPC_USER < userm-type >_UserUnmarshal(
unsigned long __RPC_FAR * pFlags,
unsigned char __RPC_FAR * Buffer,
< userm-type > __RPC_FAR * pUser_typeObject);
void __RPC_USER < userm-type >_UserFree(
unsigned long __RPC_FAR * pFlags,
< userm-type > __RPC_FAR * pUser_typeObject);
Parameter
-
wire-type
-
Gibt den benannten Übertragungsdatentyp an, der tatsächlich zwischen Client und Server übertragen wird. Der Wire-Type muss ein MIDL-Basistyp, ein vordefinierter Typ oder ein Typbezeichner eines Typs sein, der über das Netzwerk übertragen werden kann.
-
Typspezifizierer
-
Der Typ, für den userm-type zu einem Alias wird.
-
userm-type
-
Gibt den Bezeichner des benutzerdatentyps an, der gemarshallt werden soll. Es kann ein beliebiger Typ sein, wie vom Typspezifizierer angegeben, solange er über eine klar definierte Größe verfügt. Der userm-type muss nicht übertragbar sein, muss aber ein Typ sein, der dem MIDL-Compiler bekannt ist.
-
pFlags
-
Gibt einen Zeiger auf ein Flagfeld (unsigned long) an. Das Wort in hoher Reihenfolge gibt NDR-Datendarstellungsflags an, die von DCE für Gleitkomma-, Big- oder Little-Endian- und Zeichendarstellung definiert werden. Das Wort mit niedriger Reihenfolge gibt ein Marshallingkontextflag an. Das genaue Layout der Flags wird unter Der Typ _ UserSize-Funktionbeschrieben.
-
StartingSize
-
Gibt die aktuelle Puffergröße (Offset) an, bevor die Größe des Objekts festgelegt wird.
-
pUser _ typeObject
-
Gibt einen Zeiger auf ein Objekt vom Typ userm _ an.
-
Buffer
-
Gibt den aktuellen Pufferzeiger an.
Bemerkungen
Jeder anwendungsspezifische Datentyp userm-type weist eine 1:1-Entsprechung mit einem Wire-Type auf, der die Wire-Darstellung des Typs definiert. Sie müssen Routinen bereitstellen, um die Größe der Daten für das Marshalling zu vergrößern, um die Daten zu marshallen und deren Speicherung zu aufheben und Arbeitsspeicher freizugeben. Beachten Sie, dass Sie auch die Wartung dieser eingebetteten Typen verwalten müssen, wenn eingebettete Typen in Ihren Daten vorhanden sind, die auch mit [ wire _ marshal ] oder [ user _ marshaldefiniert ] sind. Weitere Informationen zu diesen Routinen finden Sie unter The wire _ marshal Attribute.
Ihre Implementierung muss den Marshallingregeln gemäß der OSF-DCE-Spezifikation folgen. Details zur NDR-Übertragungssyntax finden Sie unter https://www.opengroup.org/onlinepubs/9629399/chap14.htm . Es wird nicht empfohlen, [ wire _ marshal ] zu verwenden, wenn Sie nicht mit dem Wire Protocol vertraut sind.
Der Wire-Type darf kein Schnittstellenzeiger oder ein vollständiger Zeiger sein. Der Wire-Type muss über eine klar definierte Arbeitsspeichergröße verfügen. Ausführliche Informationen zum Marshallen eines bestimmten Kabeltyps finden Sie unter Marshallingregeln für Das _ Marshalling _ von Benutzern und das Marshalling von Kabeln.
Der userm-type sollte kein Schnittstellenzeiger sein, da diese direkt gemarshallt werden können. Wenn der Benutzertyp ein vollständiger Zeiger ist, müssen Sie das Aliasing selbst verwalten.
Sie können das [ Wire _ ] Marshal-Attribut nicht direkt oder indirekt mit dem [ attribut allocate ] verwenden, da die NDR-Engine die Speicherbelegung für den übertragenen Typ nicht steuert.
Beispiele
typedef unsigned long _FOUR_BYTE_DATA;
typedef struct _TWO_X_TWO_BYTE_DATA
{
unsigned short low;
unsigned short high;
} TWO_X_TWO_BYTE_DATA;
typedef [wire_marshal(TWO_X_TWO_BYTE_DATA)]
_FOUR_BYTE_DATA FOUR_BYTE_DATA;
//Marshaling functions:
// Calculate size that converted data will
// require in the buffer
unsigned long __RPC_USER FOUR_BYTE_DATA_UserSize(
ULONG __RPC_FAR * pulFlags,
ULONG __RPC_FAR ulStartingSize,
FOUR_BYTE_DATA __RPC_FAR * pul);
// Copy FOUR_BYTE_DATA into buffer as
// TWO_X_TWO_BYTE_DATA
unsigned long __RPC_USER FOUR_BYTE_DATA_UserMarshal(
ULONG __RPC_FAR *pulFlags,
char __RPC_FAR * pBufferStart,
FOUR_BYTE_DATA __RPC_FAR * pul);
// Recreate FOUR_BYTE_DATA from TWO_X_TWO_BYTE_DATA in buffer
unsigned long __RPC_USER FOUR_BYTE_DATA_UserUnmarshal(
ULONG __RPC_FAR * pulFlags,
char __RPC_FAR * pBufferStart,
FOUR_BYTE_DATA __RPC_FAR * pul);
// Nothing to do here as the engine frees the top
// node and FOUR_BYTE_DATA is a flat data type.
void __RPC_USER FOUR_BYTE_DATA_UserFree(
ULONG __RPC_FAR * pulFlags,
FOUR_BYTE_DATA __RPC_FAR * pul
);