library design problem

[lochnessmonster]

// header moduleinjector - header for class moduleinjector itself
// as well as "core" moduleinjector-related functionality

namespace Injection {
     class moduleinjector {...};
     ...                                                   // ... = core related functionality e.g.  non member functions almost all clients need
     ...


}

when you construct a moduleinjectior object you must pass in a VALID PROCESS ID. Therefor i constructed the following function

BOOL getProcessID( const std::wstring& processName )
{
	HANDLE pSnapList;
	PROCESSENTRY32 p32Info;
    BOOL     p32Status;

    pSnapList = CreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 );   
	if( pSnapList == INVALID_HANDLE_VALUE )
		return 0;// unable to get a handle on the process snapshot
    p32Info.dwSize = sizeof( PROCESSENTRY32 );

	p32Status = Process32First( pSnapList, &p32Info );
	if( p32Status == NULL )
		return 0; // need to recheck what the heck this does

		while( Process32Next( pSnapList, &p32Info ) ) {
			if( processName == p32Info.szExeFile ) {
				return p32Info.th32ProcessID;
		   }

		};
		return -1; // is this needed? not found process name in list?
}

my question is where should i place this function with my library?!
1.) Should it be placed in the moduleinjector.h in core functionality as a nonmember function?
2.) Should i place it in a moduleInjectorConvience.h file so user's can use my premade function?
3.) It seems like this function should be places in a .h called PE_ProcessTools.h or PE_Tools.h...should i place it in that .h and include it in my release?

Any thoughts/reasoning behind the choice that you would choice is greatly appreciated! -thx

[Narue]

I'd create two constructors: one that takes a process ID and validates it, and one that takes a process name and finds the ID. getProcessID could be a private member function that the constructor defers to, but otherwise doesn't need to be exposed to client code.

With the information given, I don't think your library needs to offer this functionality (get a process ID given a process name) directly.

[mike_2000_17]

Narue is right. I would classify the ID data under "implementation details", i.e., stuff that should be encapsulated and hidden from the user (maybe accessible through a get function). I probably would go as far as not even providing a constructor that takes an ID, just ones that take high-level objects (a constructor from process name, a copy-constructor, and possibly some conversion or transfer of ownership kind of constructors between your different classes that handle a process ID, so that they can hand it over to each other while hiding it from the user).