[Tutorial with Source] GetPidsByProcessName

[Cypher]

In regards to references vs pointers:
There are times when pointers are appropriate (for example when 'null' is an appropriate value and not an error). There is no such thing as a null-reference so use of a pointer in the case where the parameter is optional is quite acceptable.

In regards to RAII:
shared_ptr is designed for pointers. Handles and other OS resources are not pointers.

In regards to TCHAR:
TCHAR resolves to wchar_t when compiling for Unicode, and char when compiling for MBCS. Honestly though, I see no reason to use anything other than Unicode when you're doing development of Windows libraries. Windows uses Unicode internally, so by using narrow strings in your application you're slowing it down because for each API call that works with strings it needs to convert the narrow strings to wide strings, call the wide API call, then convert any wide strings back to narrow (if appliciable). If you just use wide strings to begin with you avoid a lot of overhead.

In answer to your actual concern though, you want to use basic_string<TCHAR> so you get a wstring under Unicode and a string under MBCS.

Again though, I don't even bother with that, I just use wide strings everywhere because it's pointless to use narrow ones.

[Ellesar1]

thanks for your clarification about the "call by pointer" use.

as a reason to use a std::basic_string<TCHAR> I see that PROCESSENTRY32.szExeFile has type TCHAR* and therefore is not forced to be unicode


to RAII: I've implemented it with a shared_ptr now which works well and without additional dependencies.
will keep your posted "EnsureCleanup" in mind to use when the project makes more use of these HANDLE's etc.

[Cypher]

Originally Posted by Ellesar1

thanks for your clarification about the "call by pointer" use.

as a reason to use a std::basic_string<TCHAR> I see that PROCESSENTRY32.szExeFile has type TCHAR* and therefore is not forced to be unicode


to RAII: I've implemented it with a shared_ptr now which works well and without additional dependencies.
will keep your posted "EnsureCleanup" in mind to use when the project makes more use of these HANDLE's etc.

Yes, but as I said, I always compile with Unicode, so the fact that it's a TCHAR is irrelevant because it will always end up resolving to a wchar_t. If you wish to support multiple character sets that's fine, but I honestly wouldn't bother. I use all the wide APIs and structures explicitly so I don't get the TCHAR version but instead get the WCHAR version.

I know a shared_ptr will work fine in this specific instance, however the point I was trying to make was that although it will work fine it is still not the 'correct' thing to do as it implies that the resource is a pointer of some sort.

Anyway, doesn't really matter I guess, just being pedantic.