Convert object to integer and back

[Josh]

Here's the proper way to convert to an integer and hex string, and back:

			int pointer = (int)(int*)o;
		std::string hex;
		stringstream ss;
		ss << hex << pointer;		
		hex = ss.str();
		int l=hex.length();
		for (int h=0; h<8-l; h++)
		{
			hex = "0"+hex;
		}
		o = (Object*)pointer;
		return "0x"+hex;

[TylerH]

As long as you are only using the pointer for it's numerical/textual representation of the memory it is pointing to, and not storing the value and trying to cast it back to the type for which it points to, you won't have any problems. Regardless of the length, the actual pointer value (memory address) can be saved and used as a lookup ID, just not a direct weak reference to the original variable.

[Josh]

I actually could cast it back, since I am using pointers and they'll be fine as long as they aren't deleted, but I don't think I will be doing that.

 

Anyways, it works. See my blog for details about the Lua debugger.

[Rick]

I always found it weird how C++ programmers are so scared of this idea.

 

Because it's not promised to work on every platform. You'll love it until you try to support a platform that gives some strange behavior, then you'll curse C++ for allowing you to do it Of course this the assumption that you are trying to convert it back, which was in your original specs. If you just want to display the memory address then go ahead.

 

Also why do int pointer = (int)(int*)o; when you can just do int pointer = (int)o; I get the same result with either so not sure why the extra (int)(int*).

 

A strong typed language isn't supposed to be used like that, and I find using reflection rather a bad practice

 

Reflection is sweet when using it with LE editor properties and being able to extend your game without having to change anything in the core. Much easier and more extendable than messing with a switch statement. You get the benefit of a scripting language in a strong typed language. Having the flexibility is very nice.

[TheoLogic]

Reflection is sweet when using it with LE editor properties and being able to extend your game without having to change anything in the core. Much easier and more extendable than messing with a switch statement. You get the benefit of a scripting language in a strong typed language. Having the flexibility is very nice.

 

I should personally use WCF for this. Every entity has a data contract which states the parameters, e message is send on change. Nice and easy!

[Rick]

I should personally use WCF for this. Every entity has a data contract which states the parameters, e message is send on change. Nice and easy!

 

Could you elaborate on this. I'm not sure if we are talking about the same usability, and just curious of what you mean above in more detail. I'm using WCF to create a service at work so I'm not following how that would play into dynamically creating game objects without recompiling the main program.

[Mumbles]

Here's the proper way to convert to an integer and hex string, and back:

			int pointer = (int)(int*)o;
		std::string hex;
		stringstream ss;
		ss << hex << pointer;		
		hex = ss.str();
		int l=hex.length();
		for (int h=0; h<8-l; h++)
		{
			hex = "0"+hex;
		}
		o = (Object*)pointer;
		return "0x"+hex;

 

What is "o" in this example? Because if it's not an int, then why would you use the "pointer to an int" typecast? (Line 1)

 

Also, by converting your pointer to an int, 'pointer' will not be a hex value, every digit will be 0-9. Print it out to the console if you want but I'm almost certain that by casting it out of a "pointer to a" type, that the A-F values will be lost.

 

Essentially, what's happening is:

 

• o is a pointer to an object. The value is (for example) 0x20 (of course in reality, you would never get such a low number)
  
• pointer is declared as an int, but we are not ready to assign its value just yet because we have to do some casting first , in the order of right to left
  
• a temporary pointer is created, it has the same value as pointer (0x20) but this pointer instead declares that the target memory contains an int, not an object.
  
• a temporary int is created, it has the value value 0x20 which has a binary representation of 00100000, which is 32.
  
• pointer is initialised to this temporary int value: 32
  
• because you are putting the int into the stringstream, and not the pointer, "32" will be added to the string stream, not "20"
  

 

Object *ObjectPointer = &o; //If o is an object, do this one, otherwise do the one below
Object *ObjectPointer = o; //If o is a pointer to an object, do this one, otherwise do the one above
std::string hex;
stringstream ss;
ss << hex << ObjectPointer;

 

should keep it in hex... Either that or I've gone a bit cuckoo...

[TheoLogic]

Could you elaborate on this. I'm not sure if we are talking about the same usability, and just curious of what you mean above in more detail. I'm using WCF to create a service at work so I'm not following how that would play into dynamically creating game objects without recompiling the main program.

 

Let's say you have an entity (take model for example) which has 6 parameters. You specify a datacontract and the needed operations to communicate with your WCF service. The client would be the editor, the service a windows service for example. You can only provide 3 parameters, and the other 3 are optional. Thiw way you could extend your application. I agree that reflection gives you more power to do this, but in a reflective way. Things can get terribly wrong, because reflection is just string based...

[VeTaL]

[offtopic]

Used my own personal touch there. Sorry about that.

roland, i also prefer using "_name" for private members.

[/offtopic]

[Paul]

If you have any plans to compile for x64, you shouldn't be using int to hold a pointer. stdint.h has a portable intptr_t type.