reference

Discussion in 'C++' started by worlman385@yahoo.com, Apr 9, 2008.

  1. Guest

    The prototype of GetExitCodeThread is like this -

    GetExitCodeThread(
    __in HANDLE hThread,
    __out LPDWORD lpExitCode
    );

    =============================
    why we put &dwExitCod in the parameter? like -

    DWORD dwExitCode;
    GetExitCodeThread( hth2, &dwExitCode );

    =============================
    digging further i found -
    typedef DWORD near *PDWORD;
    typedef DWORD far *LPDWORD;

    =============================
    So DWORD* "equals" LPDWORD ???

    then above
    LPDWORD lpExitCode
    should be taking parameter of
    DWORD* lpExitCode

    (Given DWORD* "equals" LPDWORD) ???

    =============================
    that's why &dwExitCode ? since &dwExitCode "returns" a pointer to
    DWORD.
     
    , Apr 9, 2008
    #1
    1. Advertising

  2. Guest

    On Apr 8, 6:50 pm, Sam <> wrote:
    > writes:
    > > The prototype of GetExitCodeThread is like this -

    >
    > > GetExitCodeThread(
    > > __in HANDLE hThread,
    > > __out LPDWORD lpExitCode
    > > );

    >
    > There's no such function in C++.


    And your point is?

    C++ programmers deal with many functions every day that are not in C+
    +; they are all written in C++. The function signature above is on-
    topic here.

    > > =============================
    > > why we put &dwExitCod in the parameter? like -

    >
    > Who knows.


    C++ programmers know.

    > This is a Microsoft Windows-specific function, so you should ask
    > this question in some other, different newsgroup that's more appropriate for
    > MS C++-specific topics.


    That is no Microsoft Windows-specific function at all. All we are
    seeing is an interesting function signature, with the __in and __out
    in there. Some probably #define'd names added...

    The fact that you are bringing some external knowledge to claim it to
    be doesn't make that signature off-topic here.

    How can a C++ programmer ask a question about a function signature
    without using a function that is not in C++?

    > > =============================
    > > that's why &dwExitCode ? since &dwExitCode "returns" a pointer to
    > > DWORD.

    >
    > You've just beginning to discover why experienced C++ programmers consider
    > MS Windows to be worthless crap. Decades and decades of accumulated cruft
    > and debris, to the point that the whole thing is a tangled, hairy mess.


    Any project that lives that long is likely to become a tangled hairy
    mess. Microsoft's interfaces are designed years before the software
    industry could mature enough to see better ways.

    Ali
     
    , Apr 9, 2008
    #2
    1. Advertising

  3. Guest

    One of the confusion for windows programming is there are so many
    data type.

    some of the type are in here
    http://msdn2.microsoft.com/en-us/library/aa383751.aspx
    http://msdn2.microsoft.com/en-us/library/323b6b3k(VS.80).aspx

    Does any one agree so too - MS programming has so many confusing data
    type that standard C++ only has a few ??!



    >You've just beginning to discover why experienced C++ programmers consider
    >MS Windows to be worthless crap. Decades and decades of accumulated cruft
    >and debris, to the point that the whole thing is a tangled, hairy mess.
    >
     
    , Apr 9, 2008
    #3
  4. James Kanze Guest

    On Apr 9, 6:06 am, wrote:
    > On Apr 8, 6:50 pm, Sam <> wrote:


    > > writes:
    > > > The prototype of GetExitCodeThread is like this -


    > > > GetExitCodeThread(
    > > > __in HANDLE hThread,
    > > > __out LPDWORD lpExitCode
    > > > );


    > > There's no such function in C++.


    > And your point is?


    > C++ programmers deal with many functions every day that are
    > not in C+ +; they are all written in C++. The function
    > signature above is on-topic here.


    The function signature above is not legal C++, so it's difficult
    for most of us to make any judgement. Beyond that, any meaning
    it might have would depend on what actual types are involved,
    and we don't know that either.

    > > > =============================
    > > > why we put &dwExitCod in the parameter? like -


    > > Who knows.


    > C++ programmers know.


    I don't, and I'm a pretty experienced C++ programmer (close to
    twenty years).

    The tone of Sam's posting was overly and unnecessarily
    agressive, but the fact remains that you're talking about some
    other language, and not C++.

    > > This is a Microsoft Windows-specific function, so you should
    > > ask this question in some other, different newsgroup that's
    > > more appropriate for MS C++-specific topics.


    > That is no Microsoft Windows-specific function at all. All we
    > are seeing is an interesting function signature, with the __in
    > and __out in there.


    In a context where they can't occur in legal C++. Given the
    double underscore (which means that the names are reserved to
    the implementation), I would assume some sort of compiler
    extension, but what, I don't know. If I assume that they are
    some sort of attribute notation (like the __attribute__ stuff in
    g++), only really relevant to optimization, and that I can
    ignore them here, then I'm still stuck, because I don't have the
    slightest idea what the types HANDLE and LPDWORD look like.

    All I can say is that in an expression, a unary & operator takes
    the address of the object. So I can guess that the argument
    which receives it has a constructor which takes an address of a
    whatever type dwExitCod is. But that's so basic that it is
    treated in any introductory C++ text; surely there's more to
    your question than that.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 9, 2008
    #4
  5. James Kanze Guest

    On Apr 9, 8:30 am, wrote:
    > One of the confusion for windows programming is there are so many
    > data type.


    > some of the type are in herehttp://msdn2.microsoft.com/en-us/library/aa383751.aspxhttp://msdn2.microsoft.com/en-us/library/323b6b3k(VS.80).aspx


    > Does any one agree so too - MS programming has so many
    > confusing data type that standard C++ only has a few ??!


    The few times I've programmed against the Windows interface,
    I've found just the opposite to be true: MS doesn't seem to have
    enough different data types to keep things straight. It's nice
    to say that everything is a HANDLE, but it's even nicer to get a
    compiler error if I try to lock a mutex using a handle returned
    from CreateFile. (The older parts of Posix aren't much better,
    since open returns an int, which can just as easily be passed to
    a function expecting a process id. In the newer parts, however,
    pthread_t cannot be passed to a function expecting a
    pthread_mutex_t.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 9, 2008
    #5
  6. [OT] Windows types (WAS: reference)

    James Kanze wrote:

    > The few times I've programmed against the Windows interface,
    > I've found just the opposite to be true: MS doesn't seem to have
    > enough different data types to keep things straight. It's nice
    > to say that everything is a HANDLE, but it's even nicer to get a
    > compiler error if I try to lock a mutex using a handle returned
    > from CreateFile.


    I don't really mean to try and defend the Windows intrinsics, but it's a
    little more complex than that. In some contexts, a file handle is
    distinct from a mutex handle, but there are instances where both are
    treated equally, e.g. there are "wait" functions that accept either
    type. With the Windows API being largely defined in terms of C and thus
    limited in support for polymorphism, I don't think you can do much
    better than that.
     
    Eberhard Schefold, Apr 9, 2008
    #6
  7. Guest

    On Apr 9, 3:12 am, James Kanze <> wrote:
    > On Apr 9, 6:06 am, wrote:
    >
    > > On Apr 8, 6:50 pm, Sam <> wrote:
    > > > writes:
    > > > > The prototype of GetExitCodeThread is like this -
    > > > > GetExitCodeThread(
    > > > > __in HANDLE hThread,
    > > > > __out LPDWORD lpExitCode
    > > > > );
    > > > There's no such function in C++.

    > > And your point is?
    > > C++ programmers deal with many functions every day that are
    > > not in C+ +; they are all written in C++. The function
    > > signature above is on-topic here.

    >
    > The function signature above is not legal C++, so it's difficult
    > for most of us to make any judgement.


    This is getting more interesting to me, because you and others apply
    your past experiences to the signature above and see it as not being
    legal C++. My experience tells me otherwise, because I've worked at at
    least one company where parameters were decorated with macros that
    resolved to nothing:

    #define IN
    #define OUT
    #define INOUT

    Those were being used as comments for the programmers. (Me too
    question the usefulness of those macros.)

    That's why I didn't even "see" __in and __out up there.

    I think the name of the newsgroup should be sufficient to make us take
    that signature as being legal C++. This is the main point why I
    objected the objection.

    > Beyond that, any meaning
    > it might have would depend on what actual types are involved,
    > and we don't know that either.


    Obviously. But we can say the same for any piece of code in any other
    post. There are numerous user defined identifiers in code that appear
    in posts to this newsgroup. We just assume what they are as in

    Foo bar; // May be anything

    The OP's question stems from the fact that a typedef (LPDWORD) hides
    some information (that it is a pointer to something).

    > > > > =============================
    > > > > why we put &dwExitCod in the parameter? like -
    > > > Who knows.

    > > C++ programmers know.

    >
    > I don't, and I'm a pretty experienced C++ programmer (close to
    > twenty years).


    Surely you do; :) and you say it later in your post, that it takes the
    address of dwExitCod. I really don't think that there was more to the
    OP's question than that.

    Ali
     
    , Apr 9, 2008
    #7
  8. Triple-DES Guest

    On 9 Apr, 12:56, Sam <> wrote:
    >  application_pgp-signature_part
    > 1KLast ned
    >
    > writes:
    > > One of the confusion for windows programming is there are so many
    > > data type.

    >
    > > some of the type are in here
    > >http://msdn2.microsoft.com/en-us/library/aa383751.aspx
    > >http://msdn2.microsoft.com/en-us/library/323b6b3k(VS.80).aspx

    >
    > > Does any one agree so too - MS programming has so many confusing data
    > > type that standard C++ only has a few ??!

    >
    > There's no need to agree on something that's already an established fact.
    > See below:
    >
    >
    >
    > >>You've just beginning to discover why experienced C++ programmers consider
    > >>MS Windows to be worthless crap. Decades and decades of accumulated cruft
    > >>and debris, to the point that the whole thing is a tangled, hairy mess.


    Established by you less than 24 hours ago?

    DP
     
    Triple-DES, Apr 10, 2008
    #8
  9. James Kanze Guest

    On Apr 9, 7:11 pm, wrote:
    > On Apr 9, 3:12 am, James Kanze <> wrote:
    > > On Apr 9, 6:06 am, wrote:


    > > > On Apr 8, 6:50 pm, Sam <> wrote:
    > > > > writes:
    > > > > > The prototype of GetExitCodeThread is like this -
    > > > > > GetExitCodeThread(
    > > > > > __in HANDLE hThread,
    > > > > > __out LPDWORD lpExitCode
    > > > > > );
    > > > > There's no such function in C++.
    > > > And your point is?
    > > > C++ programmers deal with many functions every day that are
    > > > not in C+ +; they are all written in C++. The function
    > > > signature above is on-topic here.


    > > The function signature above is not legal C++, so it's
    > > difficult for most of us to make any judgement.


    > This is getting more interesting to me, because you and others
    > apply your past experiences to the signature above and see it
    > as not being legal C++. My experience tells me otherwise,
    > because I've worked at at least one company where parameters
    > were decorated with macros that resolved to nothing:


    > #define IN
    > #define OUT
    > #define INOUT


    > Those were being used as comments for the programmers. (Me too
    > question the usefulness of those macros.)


    > That's why I didn't even "see" __in and __out up there.


    Well, a user cannot (legally) define macros with names like
    __in and __out. Nor types or typedef's. As I said, the fact
    that the names start with two underscores is a very strong
    indication that they are compiler extensions. Which means that
    any answer is implementation dependent.

    If there were legal symbols, we'd still be stuck without knowing
    what they meant.

    > I think the name of the newsgroup should be sufficient to make
    > us take that signature as being legal C++.


    But it can't be, unless you allow for some compiler extensions.

    > This is the main point why I objected the objection.


    > > Beyond that, any meaning it might have would depend on what
    > > actual types are involved, and we don't know that either.


    > Obviously. But we can say the same for any piece of code in
    > any other post.


    Which is why a lot of people insist that any posted code be a
    completely compilable example. I don't go that far, since in
    many cases, you can more or less reasonably infer enough anyway.
    In this case, of course, what we can most reasonably infer is
    that the poster is using some compiler extensions, which are
    implementation defined, and not really C++.

    > There are numerous user defined identifiers in code that
    > appear in posts to this newsgroup. We just assume what they
    > are as in


    > Foo bar; // May be anything


    > The OP's question stems from the fact that a typedef (LPDWORD)
    > hides some information (that it is a pointer to something).


    And how could anyone reading here imagine something that stupid.
    When a typedef hides a pointer (e.g. like HANDLE), it's because
    you're not supposed to know it's a pointer. Otherwise, you make
    it clear that what you want is a pointer.

    > > > > > =============================
    > > > > > why we put &dwExitCod in the parameter? like -
    > > > > Who knows.
    > > > C++ programmers know.


    > > I don't, and I'm a pretty experienced C++ programmer (close to
    > > twenty years).


    > Surely you do; :) and you say it later in your post, that it
    > takes the address of dwExitCod.


    That's what the '&' operator does. But the original poster
    surely knows that.

    > I really don't think that there was more to the OP's question
    > than that.


    I don't think so. I think it's more along the lines as to why
    we need an address here. And that, of course, we can only know
    if we know the real type of LPDWORD, and can see its
    constructors.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 10, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Darren
    Replies:
    0
    Views:
    510
    Darren
    Oct 11, 2004
  2. Dude
    Replies:
    0
    Views:
    364
  3. ce
    Replies:
    1
    Views:
    3,005
  4. sam pal
    Replies:
    3
    Views:
    566
    E. Robert Tisdale
    Jul 16, 2003
  5. Craig Nicol
    Replies:
    2
    Views:
    471
    Craig Nicol
    May 10, 2004
Loading...

Share This Page