|
Joergen Sigvardsson wrote: Pointers are an intrinsic concept in C++
Actually, pointers are an intrisic concept in C. C++ has references, and that has a reason. I try to follow that guideline.
|
|
|
|
|
Uhm.. that is a rather dull guideline. Just because some academic has decided that references are better than pointers (which the majority of the C++ community uses), it's counter productive NOT to use them in cases like this, as it would cut your development by at least an hour (seeing that you posted this approximately an hour ago).
But hey, it's your time.
--
Based on a True Story
|
|
|
|
|
Ok, you're right. And i don't do that just because some academic decided it. I use pointers often enough. But i also take my time to explore other solutions, since i think i still have much to learn. That is why i don't just use pointers because everyone else uses them. There may be a better solution. ( and remember : The fast path leads to the dark side
|
|
|
|
|
Joergen Sigvardsson wrote: Uhm.. that is a rather dull guideline. Just because some academic has decided that references are better than pointers (which the majority of the C++ community uses), it's counter productive NOT to use them in cases like this, as it would cut your development by at least an hour (seeing that you posted this approximately an hour ago).
Knowing how to use references increases code readability, maintainability, and decreases the liklihood of bugs being introduced via improper usage of pointers. In general, if you can get away with not using pointers, you should do so.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Knowing how to use references increases code readability, maintainability
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.
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. Also, you do not have the option to represent "no object" with references (unless you use unsafe methods which aren't portable).
Zac Howland wrote: In general, if you can get away with not using pointers, you should do so.
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.
Zac Howland wrote: and decreases the liklihood of bugs being introduced via improper usage of pointers.
I can buy that.
--
Broadcast simultaneously one year in the future
|
|
|
|
|
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.
Most software engineers I know disagree with you on that, but as this area can quickly become a religious topic, I won't go into the discussion.
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
It is not always cumbersome, but rather forces a limitation on the code that is likely desirable. For example, calling delete on a pointer you don't "own" will delete the object, but cause problems at runtime (and may be difficult to debug). However, calling delete on a reference will give you a compile time error with line number pointing to your problem (no pun intended).
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).
That is when exceptions and status values are more valuable. Returning NULL requires that the client code must check to make sure they received a valid pointer (or suffer a bad runtime bug). Throwing an exception will break the execution of the current method so that no harm can be done to memory. Return a status code and passing in a reference to copy data to ensures that (even if the client fails to check the status), the object will be valid (i.e. no memory corruption).
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.
There are ways to handle the NULL case. The question isn't whether it does, but which method works better for a given situation. Pointers will work for any situation, but generally open your code up to lots of potential bugs. Avoiding them (and using alternative methods when possible) makes your code more robust. The point about copying data isn't valid since he is storing his data in a deque anyway (hence, it is copied all over the place as is).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Because pointers are evil. Check
this
FAQ for more on that topic. Also, i couldn't get it to work. Can't cast the iterator to a pointer. No idea how it can be done.
|
|
|
|
|
You should wrap your mutex calls in a class (open it in the constructor and release it in the destructor). This actually allows for the exception option (otherwise, throwing an exception would be bad since the code would not be exception safe).
Given what you are trying to do, I would probably pass in a reference to be returned to as an argument and return a bool or some other status indicator as a return value. It would make your code look something like this:
class MutexHolder
{
public:
MutexHolder(HANDLE mutex)
{
_Mutex = mutex;
WaitForSingleObject(_Mutex, INFINITE);
}
~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;
}
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
The problem with that approach, is that you'd be copying the job object. That may not always be possible. If you're going to return a status value, I'd suggest the COM way of returning the job: pointer to pointer, or reference to pointer (if you're hell bent on using references)
--
From the Makers of Futurama
|
|
|
|
|
The object is stored in a deque, therefore it is already being copied. The only way to avoid that is to have the deque store pointers, in which case the approach still works, you just need to pass in a reference to a pointer instead.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I use boost::optional library for similar problems. But you return a reference and it introduces some limitations to what boost::optional library could do.
Good luck..
Orhun Birsoy
|
|
|
|
|
A bit off topic but you may want to consider using Window's built-in thread pool. Look up the QueueUserWorkItem API.
Steve
|
|
|
|
|
Befor you use SetDialogBkColor(RGB(0, 0, 0), RGB(0, 255, 0)); to set background color and textcolor on a dialog what must I use now?
|
|
|
|
|
MSDN says to handle the WM_CTLCOLOR message.
|
|
|
|
|
|
If you are using MFC add the message to your function map just as you would with any other window messages.
|
|
|
|
|
|
|
Does anybody know the order in which windows are painted? I have an owner drawn STATIC control which is the parent of an owner drawn BUTTON . The I handle all of the region clipping for child controls in my own code rather than using the WS_CLIPCHILDREN style. The trouble is the button does not recieve any WM_PAINT messages preventing it from being displayed. The parent is correctly clipped, though the region is filled with a NULL brush causing a hole in the window. The button recieves all other messages including mouse input and WM_WINDOWPOSCHANGED . With the latter, I call InvalidateRect() hoping to force a redraw, but the WM_PAINT is never recieved. The only way I have managed to paint the button is to send the WM_PAINT message myself, which I know is a bad thing to do.
|
|
|
|
|
I spent hours trying to fix this last night, get up this morning and the answer is staring me in the face. I was calling ValidateRect() from the static control which in turn would validate the chidren. Since WM_PAINT is only sent when there is an invalidated region it was failing. The solution was simply to validate the clipping region in the static control or to call BeginPaint() which does the same.
|
|
|
|
|
My application build using VS2005 now I want run it on the comp. which has only .net Framework 1.1 I put in app. directory
ATL80.dll
gdiplus.dll
mfc80.dll
mfc80ENU.dll
msvcirt.dll
msvcp80.dll
msvcr80.dll
msvcrt.dll
Am I missing somthing? May be I need more modules to avoid installation of .net Framework on that machine?
When I do regisration of my COM componetns I am getting error
somthing like "... Configuration error application could not be loaded reinstall could help to fix problem"
|
|
|
|
|
Do you use the .NET framework in your code? If so you'll need the .NET framework installed on
the machine. None of the dlls in your list have anything to do with .NET.
Mark
|
|
|
|
|
No I don't use .net Framework. I only use MFC80 and ATL30
|
|
|
|
|
Can you post the exact error instead of "somthing like"?
|
|
|
|
|
regsvr32 MyDll.dll
"Load library (MyDll.dll) failed. This application failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
|
|
|
|