reference

[worlman385]

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.

 

[acehreli]

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.

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++?

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

 

[worlman385]

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 ??!

 

[James Kanze]

There's no such function in C++.

[/QUOTE]

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.

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++.

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]

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

 

[Eberhard Schefold]

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.

 

[acehreli]

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

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

 

[Triple-DES]

 application_pgp-signature_part
1KLast ned





There's no need to agree on something that's already an established fact.
See below:

Established by you less than 24 hours ago?

DP

 

[James Kanze]

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.

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.

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.