Cannot overload functions after all previous overloads have been evaluated

[GoogleCodeExporter]

What steps will reproduce the problem?
Stub a function on a mock_object N times with overloaded return values. Call 
the function on the mock_object's instance (getInstance()) N times. Stub the 
function again with another overload. Call the function on the instance and 
observe that the last overload did not take effect; the returned value is that 
which was specified in the Nth overload.

However, if you stub the function with N overloads, then call the function 
(N-1) times, then add the (N+1)th overload, then call the function twice more 
you observe that the (N+1)th function call returns the value specified in the 
(N+1)th overload, which is exactly what you would expect. (Any subsequent call 
also returns this same value, as expected.)

See attached code.

What is the expected output? What do you see instead?
I expect that no matter the state of the mock_object and how many times the 
instance functions have been evaluated, setting a new stub overload will cause 
that overload to take effect as early as possible; in particular, if there are 
other non-evaluated overloads the new overload will be queued at the end, and 
if all overloads have been evaluated the new overload will take effect on the 
next function call.

What version of the product are you using? On what operating system?
mockitopp trunk rev158

$ uname -a
Linux [redacted] 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 09:58:09 CDT 2012 
x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 5 Aug 2013 at 9:49

Attachments:

• test.cc

[GoogleCodeExporter]

I looked into this and found an explanation for the behavior. In my example 
above, the action_type for the Nth overload is stored in the action_queue_type 
list even after it is invoked (since it is the last item in the list). When the 
(N+1)th overload is defined, its action_type is pushed to the back of the list 
while the Nth action_type remains at the front of the list. Thus, the next time 
the function is called the Nth overload will still be used (but the time after 
that the (N+1)th overload will be used).

I've written a patch that addresses this use case (see attached). The test.cc 
file included in the initial report passes with these changes, as do all the 
existing unit tests. Please feel free to use this patch, or I'd be happy to 
join the group and commit the patch (along with new unit tests) myself.

Original comment by [email protected] on 10 Aug 2013 at 4:24

Attachments:

• issue14.patch

[GoogleCodeExporter]

Patch with unit tests to verify the behavior.

Original comment by [email protected] on 10 Aug 2013 at 9:46

Attachments:

• issue14_test.patch