3. IN, OUT, INOUT

IN, OUT, INOUT

  • R

    das ist im Standard so nicht vorgesehen. Könnte aber sein, dass das eine Erweiterung eines Compilers ist oder Macros um ggf. Compiler Erweiterungen zu nutzen.

    Gib mal mehr Informationen über den Code

    0
  • B

    Das hab ich in C++ noch nicht gesehen, es ergibt auch nicht viel Sinn. In Ada gibts das.

    0
  • S

    Ich schon, ist in den neueren WinAPI-Teilen der Fall. Parameter die von dir an die Funktion übergeben werden sind mit IN, Parameter in der die Funktion Daten speichert mit OUT deklariert.

    Das Ganze wird dann mit:

    #define IN
#define OUT

    herausgeschnitten.

    Also dient wie gesagt nur der Lesbarkeit und hat absolut keinen Einfluss auf die Performance - in der WinAPI zumindest nicht.

    MfG SideWinder

    0
  • B

    OMG, was rauchen die denn da in Redmond 🤡

    0
  • ?

    Also Compiler ist der von VC++ 6.0.

    Es scheint in der windows.h ein define zu geben.

    ... windows.h ...

    #ifndef IN
    #define IN
    #endif

    Ist das alles wirklich nur wegen der Optik ??

    Mit einem simplem Testprogramm ergeben sich da keine Änderungen, falls
    mal mit IN ohne IN mit IN statt OUT...

    wer weiß mehr ????

    0
  • R

    lol, echt krank. Wenn dann bitte so

    #define REFERENZ &
#define POINTER *
#define VARIABLE
#define FUNKTIONSNAME
#define VARIABLENNAME
#define PARAMETER_LISTE_ANFANG (
#define PARAMETER_LISTE_ENDE )
#define NAECHSTER_PARAMETER ,

VARIABLE UINT FUNKTIONSNAME moep PARAMETER_LISTE_ANFANG IN VARIABLE CONST CHAR POINTER VARIABLENNAME foo NAECHSTER_PARAMETER OUT VARIABLE UINT REFERENZ VARIABLENNAME bar PARAMETER_LISTE_ENDE ;

    gleich viel einfacher zu lesen 😉

    0
  • P

    gg naja du machst es dir aber auch Kompliziert, dass geht doch einfacher.

    #define REFERENZ &
#define POINTER *
#define VARIABLE
#define FUNKTIONSNAME
#define VARIABLENNAME
#define PARAMETER_LISTE_ANFANG (
#define PARAMETER_LISTE_ENDE )
#define NAECHSTER_PARAMETER ,

#define R REFERENZ
#define P POINTER
#define V VARIABLE
#define FN FUNKTIONSNAME
#define VN VARIABLENNAME
#define PLA PARAMETER_LISTE_ANFANG
#define PLE PARAMETER_LISTE_ENDE
#define NP  NAECHSTER_PARAMETER

//redundanz ist wichtig !!! ^^

//und schon

V UINT FN moep PLA IN V CONST CHAR P VN foo NP OUT V UINT R VN bar PLE ;

    Achso und @Bashar die Rauchen ganz normalen Rasen da glaub ich.
    🤡

    0
  • S

    Naja ob IN oder OUT finde ich ganz praktisch, imho erkenne ich das ja nicht ohne weiteres.

    Ob Pointer oder Reference sehe ich ja an der Übergabe bereits. Aber ob die Variable verändert wird oder ich etwas an die Funktion übergeben muss steht nirgends.

    Von daher sehe ich das nur halb so schlimm.

    MfG SideWinder

    0
  • O

    im notfall kann man auch auf etwaige consts achten 😉

    0
  • P

    *grins*

    Listen my heroes: The Senior Consultants says... 🕶

    Eines der Probleme bei der Übergabe von Zeigern besteht darin, dass C++ keinen Hinweis darauf liefert, ob eine Funktion tatsächlich die Datei modifiziert, auf die ein Argument der Funktion verweist. Beispielweise könnte ein Zeiger auf bestimmte Daten an eine Funktion übergeben werden, die die Daten nur liest. In anderen Fällen wir ein Zeiger zu einem einzigen Zweck an eine Fkt. übergeben, um neue Daten bei Beendigung des Fkt.aufruf zurückzuhalten. in einer dritten Variation könnte eine Fkt. sowohl lesend als auch schreibend auf die Daten zugreifen, deren Adresse durch einen Zeiger übergeben wird. Die Syntax für C++ bietet keine Möglichkeiten, diese Unterschiede auszudrücken, da sie voraussetzt, dass sowohl die aufzurufende Einheiten als auch die aufgerufene Fkt innerhalb desselben Adessraums ausgeführt werden.

    Bei Aufrufen zwischen verschiedenen Computern ist das Eingehen auf diese Situation sicherlich keine syntaktische Haarspalterei. In diesen Fall ist es erforderlich, dass System alle an den erforderlichen Adressen lokalisierten Daten, auf die Zeitparameter verweisen, beim Aufruf der Fkt. an den Server übermittelt und bei Beendigung der Fkt.ausführung an den Client zurückgibt. Da der Entwurf von IDL auf die Unterstützung der Entwicklung verteilter Systeme zielt, besteht eines der Ziele von IDL darin, den Umfang des durch Remote-Aufrufe verursachten Netzwerksverkehrs zu reduzieren. Aus diesen Grund führt die IDL drei Richtungsattribute in die Syntax ein [IN],[OUT] und [IN,OUT]. Wenn keines der Attribute angegeben ist, werden die Parameter standardmäßig als Teil der Anforderungsnachricht, die für den Aufruf einer Methode verwendet wird, an den Server übergeben.

    Das Att. OUT zeigt an, dass Daten nach Beendigung des Fkt. in der Antwort zum Client zurückgesendet werden mussen. das Att. [IN,OUT] zeigt an, dass die Daten, auf die ein Zeigerparameter verweist, an den Server als Teil einer Anforderungsnachricht übermittelt und anschließend neue Daten in einer Antwort an den Client zurückgegeben werden müssen...

    Inside COM+ | ISBN: 3860634984 S.417-420 Kapitel 16 Richtungsatrribute.

    cu

    P84

    0
  • S

    Hmm, sag ich ja "erweitere Win-API" 😉

    Ist das Buch interessant? Oder stehen da nur Dinge drin, die man nach 3h MSDN auch weiß?

    MfG SideWinder

    0
  • P

    @SideWinder:
    Möglich - wenn Du Senior Developer mit 4-5 Jahren C, C++, win32, MFC, ATL, OLE, COM(+) Erfahrung bist ... oder ein Gott-Talent 😃 .

    Für mich war das Buch 'Hard Stuff in Practise', denn ich mir heute angesichts .NET nicht nochmal antunen würde...

    Aber es vermittelt auch ein rudimentäres Verständis für Komponententechnologien, so dass auch CORBA dir dann nicht schwer fallen dürfte ...

    0
  • S

    Da ich beides bin brauch ich dann das Buch gar nicht mehr 🤡, nein okay, aber dann doch lieber gleich ein Buch über .NET

    Danke für die Info

    MfG SideWinder

    0
Anmelden zum Antworten