Where to start learning

[flameboy]

Come on mate, haven't we talked about this?

You're a little harsh for someone writing such awful code.

Bug 1:
I cite section 17.4.3.2.1 of the C++ (03) Standard:

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165

Bug 2:
You're casting a char* to a TCHAR* then calling a wchar_t* API. Good luck getting that to work with Unicode. Even trying to use that code on a target as common as Battlefield 3 will fail because the window for BF3 contains a Unicode character afaik (U+2122 I believe).

Bug 3:
You're casting a 'long' to a 'void*'. A 'long' is 32-bits even under x64 on Windows. Stop using integer types to hold pointers, unless they're explicitly memsize types (e.g. ULONG_PTR). <-- Maybe you should learn math? sizeof(void*) != sizeof(long) (It may be on some platforms but that's not something you can rely on. We have memsize types for a reason).

Bug 4:
Make sure that your template is being called with arguments that make sense (i.e. a POD type). Consider what happens if someone calls your function with a type like:
std::vector<int>. Surely that's a mistake (and one that can be trivially detected at compile time through TMP or static_assert).

Bug 5:
I'm assuming now that you haven't actually tried to compile this code, as you're returning a non-existent variable 'Value'.

Defensive Programming 1:
Check your damn API return values. You currently check none of them.
Btw, your call to CloseHandle could raise an exception in debug mode because you don't check whether the handle returned from OpenProcess is valid, so even if the other functions will fail semi-gracefully, CloseHandle will not.

Defensive Programming 2:
You don't need PROCESS_ALL_ACCESS just to read memory. Request only what you need. This not only helps you obtain a handle to processes where you might be limited in access (and requesting unnecessary privileges will result in a denial), but it also improves the safety of your code in the event of a vulnerability by limiting the attack surface area (not really relevant in this particular case, but it's a good habit to get into).

Style 1:
WHY_ARE_YOU_NAMING_VARIABLES_LIKE_THIS? Pretty much all C++ coding style 'guidelines' (for all the major libraries, companies, etc) reserve such identifiers for macros (and often also enumerations).

Style 2:
Stop declaring your variables at the top of the function. You don't even have to do that in C any more.
Don't do this:
int i;
i = foo();
Do this:
int i = foo();
Also limit the scope of your variables to where they actually need to be visible, this is especially important when dealing with more complex types which hold resources or have other non-trivial operations in their destructor.

Misc 1:
Not sure whether this should be considered a 'bug' or a 'style' issue or something else..
Anyway, if you're working under Windows you should be working with wide strings at API boundaries. If you wish to maintain a narrow string interface for your APIs that's fine, but they should be UTF-8 encoded to avoid data-loss, and you should convert to UTF-16 at points where you call into the Windows API.
Furthermore, why are you taking a char[]? First off, if you're taking a char[] that you do not wish to mutate, you should be taking it as char const[], but I digress... I think you mean: 'char const* const' (the last 'const' is optional, but again, good habit). As I've already said though, that's wrong, and you want to use a wchar_t.
Personally I'd use the C++ string types (std::string/std::wstring), then if you're super-worried about efficiency then implement the code in terms of your ptr-to-char and provide a C++ string overload that forwards to it. Makes your API less cumbersome to use, while retaining the efficiency.

Maybe you should read a C++ book too. (Or maybe you can just calm down a bit until you're in a position to actually give constructive advice.)

P.S. Some of the above can be excused given it's obviously just for exposition, but the really nasty bugs can not. Come on, it's all obvious just from looking at. Heck, I probably even missed one (or more), but I'm over it.

Trolololol.

This was truly epic. I was laughing the entire time. Poor BitHacker :-p

[who knows]

For me, declaring variables as close to their point of use increases clarity, not decreases it. But that's a quality of life issue really. What's more important how it affects the software.
For PoD types it's fine to do the declare/assign in separate statements (although I still agree with limiting the scope of them), but think about what happens with classes and structs.

std::string str;
str = "string";
...
std::string str("string");

Those two code snippets are equal right? Actually they aren't. The end result is the same, but how you get there is different(*). The first one first constructs an empty string by calling the default constructor and then calls the assignment operator for char*. A totally unnecessary operation compared to the 2nd one which directly calls the char* constructor.
The extra overhead might be trivial in the case of an std::string object, but for more complex ones it could be quite large.

*) An optimizing compiler might be able to "fix" the first one, but it's not something you should depend on.


Edit/Update:

And to add to this, the conversion would be sign extended..

That was an excellent and very elegant explanation of the declaration and assignment question. Almost too elegant. Skynet maybe?
I totally get what you're saying, though. I've always been fascinated about optimization. Reading through the different textbooks always barely touch up on the topic, and they usually use the scapegoat of "modern computers are fast enough in modern times that its usually unnecessary" paraphrasing, of course.

I recently ran into an issue with recursion that I had the bad oversight of running out of memory allocation (not from an infinite loop, mind you - simply from too many recursive calls) and had no Idea what was the cause. Then I had to go digging and found that recursion has a large overhead...I was like oh really?! Thanks modern textbooks for simply breezing right by that little detail.

[Cypher]

Cypher,

Nice information very informative. I already know by your libraries and code you are will over my years ... I always appreciate nice references like this:

I cite section 17.4.3.2.1 of the C++ (03) Standard:
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165

Can you supply me a link?

-Bit_Hacker

I supplied you with the exact line in the standard where you can find that particular piece of information.

You will have to obtain a copy of the standard yourself though. It is unfortunate that the final standards are not free, however there is usually a draft that is quite accurate and which contains only minor editorial changes, so you can always get that.

For me, declaring variables as close to their point of use increases clarity, not decreases it. But that's a quality of life issue really. What's more important how it affects the software.
For PoD types it's fine to do the declare/assign in separate statements (although I still agree with limiting the scope of them), but think about what happens with classes and structs.

std::string str;
str = "string";
...
std::string str("string");

Those two code snippets are equal right? Actually they aren't. The end result is the same, but how you get there is different(*). The first one first constructs an empty string by calling the default constructor and then calls the assignment operator for char*. A totally unnecessary operation compared to the 2nd one which directly calls the char* constructor.
The extra overhead might be trivial in the case of an std::string object, but for more complex ones it could be quite large.

*) An optimizing compiler might be able to "fix" the first one, but it's not something you should depend on.

One other important difference between the two is that the former requires you to declare the variable as non-const, even in cases where it would otherwise be unnecessary. Not a huge deal, but it does help readers to reason about and understand your code.

Edit/Update:

And to add to this, the conversion would be sign extended..

Ooh, nice catch!

[BitHacker]

I supplied you with the exact line in the standard where you can find that particular piece of information.

You will have to obtain a copy of the standard yourself though. It is unfortunate that the final standards are not free, however there is usually a draft that is quite accurate and which contains only minor editorial changes, so you can always get that.

I would like to obtain a copy, where do I get it? This is why I asked you for a link?

[_Mike]

Search c++11 on wikipedia

[Cypher]

I would like to obtain a copy, where do I get it? This is why I asked you for a link?

Official ISO Standard (Not Free):
ISO/IEC 14882:2011 - Information technology -- Programming languages -- C++

Working Committee Draft (Free):
http://www.open-std.org/jtc1/sc22/wg...2011/n3242.pdf

Unless you're writing a compiler or you're really on the bleeding edge of the language then the draft should serve you just fine.

Next time just Google it. Sigh.

[Kikipaz]

Cheat engine combined with some youtube vids should get you going

Never give up