C / C++ / MFC

Joergen Sigvardsson wrote:

That I don't buy. The only thing that differs between references and pointers in terms of readability are "->" vs "." and "*" vs "&". If anything, references goes against readability, because it's not obvious by seeing the usage of a variable whether it's by value or by reference. With a pointer, it becomes quite obvious.

Joergen Sigvardsson wrote:

References also have a cumbersome feature which is not always possible to overcome. You can't assign a reference later on - it must be initialized. That is not always possible

Joergen Sigvardsson wrote:

Also, you do not have the option to represent "no object" with references (unless you use unsafe methods which aren't portable).

Joergen Sigvardsson wrote:

The only time I use references are when "no object" isn't an option. In the case of the OP, a reference isn't worthwhile as it doesn't cope well with the NULL case - an expected case it turned out later in a clarification by the OP's author. Returning a status value indicating success is not a desired either as it requires an extra copy which may not be doable if the state of the job object is to be visible to all.

class MutexHolder
{
public:
	MutexHolder(HANDLE mutex)
	{
		_Mutex = mutex;
		WaitForSingleObject(_Mutex, INFINITE);
		// I believe this should actually be OpenMutex
		// In which case, you would change the constructor arguement to a string
	}

	~MutexHolder()
	{
		ReleaseMutex(_Mutex);
	}

private:
	HANDLE _Mutex;
};

bool job_not_working(const your_deque_type& t)
{
	if (t.m_JobState != JOB_WORKING)
	{
		return true;
	}
}

bool CThreadPool::CJobQueue::getJob(CThreadPool::t_Job& job)
{
	MutexHolder(m_JobListMutex);

	deque<your_deque_type>::iterator it = find_if(m_JobList.begin(), m_JobList.end(), job_not_working);
	if (it != m_JobList.end())
	{
		job = *it;
		job.m_JobState = JOB_WORKING;
		return true;
	}
	return false;
}