tpounds / mockitopp Goto Github PK

What steps will reproduce the problem?
1. CXX=/path/to/gcc-4.7 scons
2.
3.

What is the expected output? What do you see instead?
I see:
Checking for ::std::regex... no
Checking for ::std::tr1::regex... no
Checking for ::boost::regex... no

in the config.log, I see that it is using flat g++ to run the tests intead of 
my overridden compiler. Additionally, I can't figure out how to get 
-std=gnu++11 into the flags during those tests.

the first example from the "Stubbing" page does not work with current mockitopp 
versions. I repeat it here:

<code>
#include <gtest/gtest.h>
#include <mockitopp/mockitopp.hpp>
struct Foo
{
   virtual void bar() = 0;
};
TEST(MyTestCase, Foo)
{
   mockitopp::mock_object<Foo> mock;
   mock(&Foo::bar).thenReturn(); // <-- here a when() is required!
   Foo& fooImpl = mock.getInstance();

   ASSERT_NO_THROW(fooImpl.bar());
}
</code>

The line "mock(&Foo::bar).thenReturn()" currently requires a "when()", 
otherwise at runtime a segmentation fault is generated.

The easy fix is to change the example on the Wiki.
The better fix would be to not require a when() for functions without 
parameters.

What steps will reproduce the problem?
1. call a mocked function one too many times on a line with multiple mocked 
calls

mock_object<interface> mock;
mock_object<other> other_mock;
if (mock.getInstance().f() && other_mock.getInstance().g()) {}

2. a missing_implementation_exception() is thrown with no details about which 
class/member is involved

this is presenting a major usability problem, requiring disassembly-level 
debugging on some platforms.


What is the expected output? What do you see instead?
the exception ideally would have the member name in the what() of the 
exception. while there's no platform-agnostic way to do this, glibc offers 
dladdr() that returns a struct containing the symbol name in the dli_sname 
field.

non-ideally, the typeinfo() or method signature ((bool)interface::*) being in 
the what() would provide enough of a clue in most cases.

I have some ideas for ways to modify dynamic_object to do some of this, but 
want to get other ideas as well.

What steps will reproduce the problem?
1. try to compile the attached program


What is the expected output? What do you see instead?
I would expect it to compile, at least.


Please use labels and text to provide additional information.

Note that if you change the signature of f(B&) to f(int&) (and the any<B&> to 
any<int&>), the compile magically works. weird.

What steps will reproduce the problem?
1. compile an existing suite (not sure why mockito's suite doesn't fail to 
compile...)



What is the expected output? What do you see instead?

/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp: In function \u2018void 
HttpCfeBlade_does_not_create_appblade_when_request_parsing_not_done()\u2019:
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp:65:15: error: \u2018bool 
mockitopp::detail::dynamic_vfunction_base::never() const\u2019 is inaccessible
protocol/http/appblade/http_cfe_blade_test.cc:71:5: error: within this context
protocol/http/appblade/http_cfe_blade_test.cc:71:5: error: 
\u2018mockitopp::detail::dynamic_vfunction_base\u2019 is not an accessible base 
of \u2018mockitopp::detail::dynamic_vfunction<http::AppBlade* 
(http::CfeAppBladeManager::*)(const Request&)>\u2019
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_object.hpp:5:0,
                 from /work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/mock_object.hpp:4,
                 from protocol/http/appblade/http_cfe_blade_test.cc:4:
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp: In function \u2018void 
HttpCfeBlade_gives_parsed_request_to_appblade_returned_by_manager()\u2019:
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp:59:15: error: \u2018bool 
mockitopp::detail::dynamic_vfunction_base::exactly(int) const\u2019 is 
inaccessible
protocol/http/appblade/http_cfe_blade_test.cc:90:5: error: within this context
protocol/http/appblade/http_cfe_blade_test.cc:90:5: error: 
\u2018mockitopp::detail::dynamic_vfunction_base\u2019 is not an accessible base 
of \u2018mockitopp::detail::dynamic_vfunction<http::AppBlade* 
(http::CfeAppBladeManager::*)(const Request&)>\u2019



If I change the dynamic_vfunction<> templates to *publicly* inherit from 
dynamic_vfunction_progress<R> in 
include/mockitopp/detail/stubbing/dynamic_vfunction.hpp, the compile problem is 
fixed. 

This is with g++ 4.7 in gnu++11 mode on a RHEL6.2 variant.

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.

What steps will reproduce the problem?
1. get clang 3.2 on linux
2. use it to run mockitopp's own tests


What is the expected output? What do you see instead?
should compile/link with few/no warnings. instead I get errors:

In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/mock_object.
hpp:4:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_object.hpp:5:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp:10:
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:30:15: error: field has incomplete type 
'mockitopp::detail::tr1::tuple<mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type>'
            T tail_;
              ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:53:15: note: in instantiation of template class 
'mockitopp::detail::tr1::tuple_cons<mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple<mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type> >' requested here
            : tuple_cons<T0, tuple<> >
              ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:57:24: note: in instantiation of template class 
'mockitopp::detail::tr1::tuple<mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type>' requested here
                  (t0, tuple<>
                       ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:41:17: note: definition of 
'mockitopp::detail::tr1::tuple<mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type>' is not complete until the closing '}'
         struct tuple : tuple_cons<T0, tuple<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, tuple_null_type> >
                ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:282:17: error: explicit specialization of 
'mockitopp::detail::tr1::tuple<mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type, 
mockitopp::detail::tr1::tuple_null_type>' after instantiation
         struct tuple< tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type ,  tuple_null_type >
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:57:24: note: implicit instantiation first required here
                  (t0, tuple<>
                       ^
In file included from protocol/http/appblade/http_cfe_blade_test.cc:4:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/mock_object.
hpp:4:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_object.hpp:5:
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp:197:43: error: no matching constructor for 
initialization of 'exact_tuple_type' (aka 'tuple<>')
            const exact_tuple_type args = exact_tuple_type();
                                          ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:55:13: note: candidate constructor not viable: requires single 
argument 't0', but no arguments were provided
            tuple(typename add_reference<typename add_const<T0 >::type>::type t0)
            ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:52:17: note: candidate constructor (the implicit copy 
constructor) not viable: requires 1 argument, but 0 were provided
         struct tuple<T0 , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type>
                ^
In file included from protocol/http/appblade/http_cfe_blade_test.cc:4:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/mock_object.
hpp:4:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_object.hpp:5:
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp:212:43: error: no matching constructor for 
initialization of 'exact_tuple_type' (aka 'tuple<>')
            const exact_tuple_type args = exact_tuple_type();
                                          ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:55:13: note: candidate constructor not viable: requires single 
argument 't0', but no arguments were provided
            tuple(typename add_reference<typename add_const<T0 >::type>::type t0)
            ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:52:17: note: candidate constructor (the implicit copy 
constructor) not viable: requires 1 argument, but 0 were provided
         struct tuple<T0 , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type>
                ^
In file included from protocol/http/appblade/http_cfe_blade_test.cc:1:
In file included from protocol/http/appblade/http_cfe_blade.h:9:
In file included from ./cifs-auth/authlibs/src/common/data_holder.h:4:
In file included from 
/work/mhargett/sport-trunk/rbtcore_install/include/misc/databuf.h:24:
In file included from 
/work/mhargett/sport-trunk/rbtcore_install/include/misc/lock.h:13:
In file included from 
/usr/home/nfs-readonly/common/boost/linux_sl/6/x86_64/4.4.5/1_49//include/boost/
utility.hpp:16:
/usr/home/nfs-readonly/common/boost/linux_sl/6/x86_64/4.4.5/1_49//include/boost/
checked_delete.hpp:34:5: warning: delete called on 'TransactionFactory' that is 
abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
    delete x;
    ^
/usr/home/nfs-readonly/common/boost/linux_sl/6/x86_64/4.4.5/1_49//include/boost/
smart_ptr/detail/shared_count.hpp:95:13: note: in instantiation of function 
template specialization 'boost::checked_delete<TransactionFactory>' requested 
here
            boost::checked_delete( p );
            ^
/usr/home/nfs-readonly/common/boost/linux_sl/6/x86_64/4.4.5/1_49//include/boost/
smart_ptr/shared_ptr.hpp:183:44: note: in instantiation of function template 
specialization 'boost::detail::shared_count::shared_count<TransactionFactory>' 
requested here
    explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be complete
                                           ^
protocol/http/appblade/http_cfe_blade_test.cc:43:67: note: in instantiation of 
function template specialization 
'boost::shared_ptr<TransactionFactory>::shared_ptr<TransactionFactory>' 
requested here
    shared_ptr<TransactionFactory> *shared_mock_txn_factory = new shared_ptr<TransactionFactory>(&mock_txn_factory->getInstance());
                                                                  ^
In file included from protocol/http/appblade/http_cfe_blade_test.cc:4:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/mock_object.
hpp:4:
In file included from 
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_object.hpp:5:
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_vfunction.hpp:212:36: error: no matching constructor for 
initialization of 'const exact_tuple_type' (aka 'const tuple<>')
            const exact_tuple_type args = exact_tuple_type();
                                   ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/proxy_vfunction.hpp:22:51: note: in instantiation of member function 
'mockitopp::detail::dynamic_vfunction<unsigned int 
(SpliceInterface::*)()>::invoke' requested here
            { return __PAD_FOR_MOCK_spys[OFFSET]->invoke(); }
                                                  ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/proxy_vfunction.hpp:255:138: note: in instantiation of member function 
'mockitopp::detail::proxy_vfunction<0, unsigned int 
(SpliceInterface::*)()>::invoke' requested here
         virtual void* offset0() { return horrible_cast<void*>(&proxy_vfunction<0, typename remove_member_function_pointer_cv<M>::type>::invoke); }
                                                                                                                                         ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/proxy_vfunction.hpp:251:37: note: in instantiation of member function 
'mockitopp::detail::proxy_vfunction_factory<unsigned int (SpliceInterface::*)() 
const>::offset0' requested here
            proxy_vfunction_factory s;
                                    ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/stubb
ing/dynamic_object.hpp:226:83: note: in instantiation of member function 
'mockitopp::detail::proxy_vfunction_factory<unsigned int (SpliceInterface::*)() 
const>::get' requested here
               vtable_actual_ptr->functions[offset] = proxy_vfunction_factory<M>::get(ptr2member);
                                                                                  ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/mock_object.
hpp:39:19: note: in instantiation of function template specialization 
'mockitopp::detail::dynamic_object::define_function<unsigned int 
(SpliceInterface::*)() const>' requested here
         { return define_function(ptr2member); }
                  ^
protocol/http/appblade/http_cfe_blade_test.cc:46:17: note: in instantiation of 
function template specialization 
'mockitopp::mock_object<SpliceInterface>::expect<unsigned int 
(SpliceInterface::*)() const>' requested here
    mock_splice.expect(&SpliceInterface::get_id).when().thenReturn(1);
                ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:55:13: note: candidate constructor not viable: requires single 
argument 't0', but no arguments were provided
            tuple(typename add_reference<typename add_const<T0 >::type>::type t0)
            ^
/work/mhargett/sport-trunk/protocol/lib/mockitopp/include/mockitopp/detail/util/
tr1_tuple.hpp:52:17: note: candidate constructor (the implicit copy 
constructor) not viable: requires 1 argument, but 0 were provided
         struct tuple<T0 , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type , tuple_null_type>

What steps will reproduce the problem?
1. Create a mock_object<> for a class that inherits virtually from another 
class.
2. Set up expectation on the mock_object<> that a function from the virtual 
base class is called.
3. Call the function on the mock_object<>'s underlying instance

The code in the attached file shows an example.

What is the expected output? What do you see instead?
I expected that this would work the same as if the parent class was inherited 
from non-virtually. Instead a segfault is raised.

What version of the product are you using? On what operating system?
mockitopp built off of trunk at rev140
OS is Scientific Linux 6:
$ uname -a
Linux xxx 2.6.32-279.1.1.el6.x86_64 #1 SMP Tue Jul 10 11:24:23 CDT 2012 x86_64 
x86_64 x86_64 GNU/Linux

Please provide any additional information below.
In the testing context where I found this issue I was using Google's tcmalloc 
and I found that mocking a class with a virtual parent sometimes caused this 
crash, but other times worked exactly as expected. The odd thing was that 
whether or not it crashed was influenced by unrelated code around it, 
specifically the ordering and placement of declarations and memory allocations 
for mock_object<> instances. I'm still trying to distill this down into an 
easily digestible example if that would be useful.

What steps will reproduce the problem?

---
When using a matcher for a namespaced type, global equality operators for that 
type are not found which causes a compile error. The workaround is to move the 
equality operator inside the namespace as well.

I've attached mockitopp_test.cc, which contains code that demonstrates the 
problem. This code is expected to compile, but it does not compile unless the 
equality operator is put inside namespace foo.


What is the expected output? What do you see instead?

---
Expected output is that the code compiles. I've attached compile.out, which 
shows the actual output of compiling with g++ 4.4.5.


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

---
mockitopp built off of trunk at rev140
OS is Scientific Linux 6:
$ uname -a
Linux xxx 2.6.32-279.1.1.el6.x86_64 #1 SMP Tue Jul 10 11:24:23 CDT 2012 x86_64 
x86_64 x86_64 GNU/Linux

Currently MockitoPP only supports mocking classes that have a single
virtual table.  Determining a classes layout pseudo-dynamically is
nontrivial since there is no way at compile time to determine the adjusted
this and vtable offset.  This information can be deduced at runtime given a
member function pointer and its compiler dependent layout (see:
http://www.codeproject.com/KB/cpp/FastDelegate.aspx). The tricky part is
taking a decoded MFP implementation and mapping it to a compile time
generated thunk that dispatches to the correct dynamic function.

What steps will reproduce the problem?
1. Write a test with a line like 
"mock_object.expect(&Foo::bar).when(some_param).exactly(1)".
2. Compile against mockitopp rev145. Note that the test compiles and runs 
correctly.
3. Update to mockitopp rev147. Note that you now get the following compile 
error: "error: ‘struct mockitopp::detail::dynamic_vfunction_action<void>’ 
has no member named ‘exactly’"

What is the expected output? What do you see instead?
Expected tests that compiled on rev145 to still compile on rev147. Am I using 
.exactly() incorrectly in my example above?

What version of the product are you using? On what operating system?
mockitopp rev147
OS is Scientific Linux 6:
$ uname -a
Linux xxx 2.6.32-279.1.1.el6.x86_64 #1 SMP Tue Jul 10 11:24:23 CDT 2012 x86_64 
x86_64 x86_64 GNU/Linux

Please provide any additional information below.

What is the expected output? What do you see instead?

We have a mixed C/C++ codebase, with lots of C-style global functions. 
Currently, we have to use cgreen's link-time mocking style for those and 
mockitopp's mocking style for class-based mocking.

We want to be able to use mockitopp for both global-function mocks and 
class-based mocking.

it seems that they changed the member function pointer internals

compiler error:
C:\dev\st_trunk\OpenAgent\BuildUtilities\Cpp\include\mockitopp/detail/stubbing/p
roxy_vfunction.hpp(142): error C2440: 'reinterpret_cast' : cannot convert from 
'void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)' to 'void *(__thiscall 
mockitopp::detail::proxy_vfunction_factory<M>::* )(void)'
1>          with
1>          [
1>              M=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)
1>          ]
1>          Pointers to members have different representations; cannot cast 
between them
1>          
C:\dev\st_trunk\OpenAgent\BuildUtilities\Cpp\include\mockitopp/detail/stubbing/p
roxy_vfunction.hpp(140) : while compiling class template member function 'void 
*mockitopp::detail::proxy_vfunction_factory<M>::get(M)'
1>          with
1>          [
1>              M=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)
1>          ]
1>          
C:\dev\st_trunk\OpenAgent\BuildUtilities\Cpp\include\mockitopp/detail/stubbing/d
ynamic_object.hpp(127) : see reference to class template instantiation 
'mockitopp::detail::proxy_vfunction_factory<M>' being compiled
1>          with
1>          [
1>              M=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)
1>          ]
1>          
c:\dev\st_trunk\openagent\buildutilities\cpp\include\mockitopp\mock_object.hpp(3
6) : see reference to function template instantiation 
'mockitopp::detail::dynamic_vfunction<T> 
&mockitopp::detail::dynamic_object::define_function<M>(M)' being compiled
1>          with
1>          [
1>              T=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &),
1>              M=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)
1>          ]
1>          
c:\dev\st_trunk\openagent\buildutilities\cpp\include\mockitopp\mock_object.hpp(4
0) : see reference to function template instantiation 
'mockitopp::detail::dynamic_vfunction<T> 
&mockitopp::mock_object<Communicator::CRequestHandler>::expect<M>(M)' being 
compiled
1>          with
1>          [
1>              T=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &),
1>              M=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)
1>          ]
1>          mockArgumentFactory.cpp(26) : see reference to function template 
instantiation 'mockitopp::detail::dynamic_vfunction<T> 
&mockitopp::mock_object<Communicator::CRequestHandler>::operator 
()<void(__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)>(M)' being compiled
1>          with
1>          [
1>              T=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &),
1>              M=void (__thiscall Communicator::CRequestHandler::* 
)(Communicator::CCommunicatorImpl &)
1>          ]

This is an enhancement request.

I've had some use cases where I need to set a block of expectations on a 
mock_object for a set of unit tests where each unit test wants to use a default 
set of values while specializing on only one. Currently, mock_object provides 
no mechanism to override or clear previously-set expectations, so it's not 
possible to set the default expectations in the setup() function of the unit 
test framework and then cleanly override the default for any single function in 
the unit test body itself. There are some workarounds, but they clutter the 
code and make the flow and intent less clear.

I've thought of a few expressions that would be useful to support:
  1) Reset all expectations for a given function
  2) Reset all expectations for a given function with specific matching args (i.e. args to when())
  3) Reset all expectations for a given function with specific matching args and chain new expectations (thenReturn(), thenThrow()) in the same call iteratively

The semantics for one possible solution:

   // Reset all previously set expectations for ptr2member.
   // Alternative names: disregard(), cancel(), reject()
   mock_object::reset(M ptr2member);

   // Reset all previously set expectations for ptr2member calls
   // where args match those defined in when().
   mock_object::reset(M ptr2member).when(...);

   // Reset previously set expectations and set new expectations in the same call iteratively
   mock_object::reset(M ptr2member).when(...).thenReturn(...).thenThrow(...).thenReturn(...);

Any comments on these semantics or the general solution?

Hi,

I am using "exactly" behavior as seen in this page:
https://code.google.com/p/mockitopp/source/browse/trunk/test/src/test_verify.cpp
?r=138

My code: ASSERT_TRUE(mock_splice(&TestInterface::kill).atLeast(1);

Following error occurs:

 error: 'mockitopp::detail::dynamic_vfunction_base' is not an accessible base of 'mockitopp::detail::dynamic_vfunction<void (TestInterface::*)()>'
/usr/include/mockitopp/detail/stubbing/dynamic_vfunction.hpp:43:15: error: 
'bool mockitopp::detail::dynamic_vfunction_base::atLeast(int) const' is 
inaccessible

Pls share your inputs.

Thanks

What steps will reproduce the problem?
1. Using Mockitopp r132 with Boost.Test and VC2005

What is the expected output? What do you see instead?
Boost.Test report memory leaks when finished runing Mockitopp code

What version of the product are you using? On what operating system?
r132, windows 7 32bit

Please provide any additional information below.

What is the expected output? What do you see instead?

mock.verify() should throw a std::exception-derived exception, with what() 
being populated with information about exactly what missing. that way, it is 
likely they can see the failure message output by the test framework's 
high-level exception handler and immediately know what's going on.


right now, mock.verify() returns a bool. what an assertion against that bool 
fails, most test frameworks output something like "expected true, but got 
false". This leads the developer to have to add printfs or fire up the 
debugger, which greatly reduced productivity/flow.

Steps to reproduce the problem:
1. Get to the main page of project
2. Try to understand what to do to start working with mockitopp

On the main page there should be "Installation" section, or link to this 
section in wiki. Preferrably installation should use some common tools (git + 
configure + make + make install?).

I've tried to use mockitopp and was unable to do it. It took me some time to 
understand that I should use `scons` to compile mockitopp and run tests. It was 
first `scons` project I've dealt with, so it is a bit unclear at first what to 
do with cloned repo.

Even after I run `scons` and all tests passed I didn't know what to do next. 
What should I do to use `mockitopp` in my unittests? With Boost or gtest or 
something else?

Maybe I overlooked something, in this case I apologise for newbish questions. 
But anyway I believe that installation section should be easily accessible to 
newcomers.