int pointer address

Started by
11 comments, last by LessBread 17 years, 1 month ago
Quote:Original post by LessBread
That would make the pointer point to the address 0x00000002. Accessing that address would probably throw an exception.


You're absolutely right, but using the method you posted would also cause hard to debug errors if the class/function the value is passed to uses that value later on, after the original "__int32 var1" fell out of scope.

After looking closer at the CreateThread() the OP mentioned, what he should be doing is exactly what you said, except that he should just pass the address of var1 as the parameter, instead of copying that address to var2. I'm sure there's a good reason CreateThread was designed that way, but I have no idea what it is.
I know enough about OpenGL and game programming in general to be good at it, but not enough to always be very helpful, so I apoligize if I suggest something stupid.
Advertisement
Quote:Original post by likeafox
it's going to be on the stack somewhere inside the function code--


No, it isn't. It could, for example, be in a register, which isn't addressable.

Quote:In this case I'm calling CreateThread which takes a void pointer parameter, for which I want to pass in an int, but I'd look a lot tidier to me if I didn't have to break it into multiple lines to start declaring variables. But I guess I'll have to if there's no way of avoiding it.


You could make a wrapper function. The general technique is something like:

int functionWhosInterfaceWeDontLike(int* out_parameter) {  // Evil C code here}std::pair<int, int> prettyFunctionExploitingCppFeatures() {  int out_buffer;  int result = functionWhosInterfaceWeDontLike(&out_buffer);  return std::make_pair(result, out_buffer);}// or, when the input is not supposed to be modified, and the indirection// exists for a sillier reason:int functionWhosInterfaceWeDontLike(int* in_handle) {  // Evil C code here}int usingAConstReferenceLikeOneOughtToInCpp(const int& in) {  int tmp(in);  int result = functionWhosInterfaceWeDontLike(&tmp);  assert(tmp == in); // if this trips, report a bug to the API vendor  return result;}


With interfaces taking void*, though, you'll probably want to be a little more careful. (In some cases, templates are appropriate.)
Quote:Original post by Prgrmr@wrk
Quote:Original post by LessBread
That would make the pointer point to the address 0x00000002. Accessing that address would probably throw an exception.


You're absolutely right, but using the method you posted would also cause hard to debug errors if the class/function the value is passed to uses that value later on, after the original "__int32 var1" fell out of scope.

After looking closer at the CreateThread() the OP mentioned, what he should be doing is exactly what you said, except that he should just pass the address of var1 as the parameter, instead of copying that address to var2. I'm sure there's a good reason CreateThread was designed that way, but I have no idea what it is.


I didn't understand the problem when I posted that snippet. It was when I saw your "left side hack" (for lack of a better description) that I saw what the OP was going after. It seems to me that if he just wants to pass an integer value to CreateThread the solution is to simply cast the integer variable as a void pointer, pass it in and then inside the thread function recast it to a local integer variable. It seems to me that falling out of scope is not an issue if the parameter is treated as an "in" rather than an "in/out". Thinking about this a bit more, it would seem that the argument passed to the thread function resides on that thread's stack so it should be accessible until the thread function returns.

int var = 2;

CreateThread(..., (void*)var, ...);

int ThreadFunk(void *param)
{
int var = (int)param;
...
}

"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man

This topic is closed to new replies.

Advertisement