Trompeloeil is a C++14-first library and looks forward to the future where C++17-and-beyond language features and standard library further improve its utility and performance.
Sometimes though, a project comes along where instead of looking forward
one has to look backward. How far backward? All the way back to
g++-4.8.4 with a vintage libstdc++-v3 library and requirements for
compliance with the features available in the C++11 standard without
compiler extensions. (Indeed, it might be much worse: you might have
a project forced to use g++-4.8.3 with further constraints.)
To allow you to consider Trompeloeil as your mock object framework
for a project with these constraints, we have back ported Trompeloeil to
g++-4.8.4 (C++11, libstdc++-v3) with an API that may be used with
a C++11 dialect selected. The C++11 API remains supported when a C++14
(or later) dialect is selected.
Two major changes to functionality occur when compiling with the C++11 dialect.
First, the API for defining expectations is different from the API used in C++14 and later dialects.
Second, the argument to a RETURN modifier
undergoes an implicit conversion before semantic analysis. This results in
a different error message when the expression cannot be implicitly converted
to the return type of the function for which the expectation is being defined.
A minor change is that the expansion of the ANY
matcher in arguments to expectations is stringized differently in the
C++11 API when compared to the C++14 API.
It has not been possible to replicate the macro syntax that is used in the C++14 API. The cause is an inability to find a mechanism to communicate sufficient type information between expectation macros and modifier macros.
Our approach has been to redefine expectation macros as taking the modifiers, if any, as an argument to the expectation macro.
The C++11 API has a similar name to the corresponding C++14 API
C++14 API C++11 API
------------------------------ --------------------------------
TROMPELOEIL_REQUIRE_CALL TROMPELOEIL_REQUIRE_CALL_V
TROMPELOEIL_NAMED_REQUIRE_CALL TROMPELOEIL_NAMED_REQUIRE_CALL_V
TROMPELOEIL_ALLOW_CALL TROMPELOEIL_ALLOW_CALL_V
TROMPELOEIL_NAMED_ALLOW_CALL TROMPELOEIL_NAMED_ALLOW_CALL_V
TROMPELOEIL_FORBID_CALL TROMPELOEIL_FORBID_CALL_V
TROMPELOEIL_NAMED_FORBID_CALL TROMPELOEIL_NAMED_FORBID_CALL_V
Short names for these macros have also been defined.
Short macro name Long macro name
-------------------- --------------------------------
REQUIRE_CALL_V TROMPELOEIL_REQUIRE_CALL_V
NAMED_REQUIRE_CALL_V TROMPELOEIL_NAMED_REQUIRE_CALL_V
ALLOW_CALL_V TROMPELOEIL_ALLOW_CALL_V
NAMED_ALLOW_CALL_V TROMPELOEIL_NAMED_ALLOW_CALL_V
FORBID_CALL_V TROMPELOEIL_FORBID_CALL_V
NAMED_FORBID_CALL_V TROMPELOEIL_NAMED_FORBID_CALL_V
In the C++11 API, the expectation macros accept two or more
arguments, the first two being object and function and the remainder
being the modifiers, if any. Therefore the _V suffix
may be read as an abbreviation of the word "variadic".
All documentation in Trompeloeil outside of this note uses the C++14 API. The examples below show how to translate from the C++14 API to the C++11 API.
Given mock class mock_c with mock function int getter(int),
struct mock_c
{
MAKE_MOCK1(getter, int(int));
};and this expectation defined using the C++14 API,
mock_c obj;
// Two macros adjacent to each other in the program text.
REQUIRE_CALL(obj, getter(ANY(int)))
.RETURN(_1);the corresponding expectation implemented using the C++11 API is
mock_c obj;
// One macro with three arguments.
REQUIRE_CALL_V(obj, getter(ANY(int)),
.RETURN(_1));See also: REQUIRE_CALL(...).
Given mock class mock_c with mock function int getter(int),
struct mock_c
{
MAKE_MOCK1(getter, int(int));
};and this expectation defined using the C++14 API,
mock_c obj;
// Two macros adjacent to each other in the program text.
auto e = NAMED_REQUIRE_CALL(obj, getter(ANY(int)))
.RETURN(0);the corresponding expectation implemented using the C++11 API is
mock_c obj;
// One macro with three arguments.
auto e = NAMED_REQUIRE_CALL_V(obj, getter(ANY(int)),
.RETURN(0));See also: NAMED_REQUIRE_CALL(...).
Given mock class mock_c with mock function int count(),
struct mock_c
{
MAKE_MOCK0(count, int());
};and this expectation defined using the C++14 API,
mock_c obj;
// Two macros adjacent to each other in the program text.
ALLOW_CALL(obj, count())
.RETURN(1);the corresponding expectation implemented using the C++11 API is,
mock_c obj;
// One macro with three arguments.
ALLOW_CALL_V(obj, count(),
.RETURN(1));See also: ALLOW_CALL(...).
Given mock class mock_c with mock function int count(),
struct mock_c
{
MAKE_MOCK0(count, int());
};and this expectation defined using the C++14 API,
mock_c obj;
// Two macros adjacent to each other in the program text.
auto e = NAMED_ALLOW_CALL(obj, count())
.RETURN(1);the corresponding expectation implemented using the C++11 API is,
mock_c obj;
// One macro with three arguments.
auto e = NAMED_ALLOW_CALL_V(obj, count(),
.RETURN(1));See also: NAMED_ALLOW_CALL(...).
Given mock class mock_c with mock function int count(),
struct mock_c
{
MAKE_MOCK0(count, int());
};and this expectation defined using the C++14 API,
mock_c obj;
FORBID_CALL(obj, count());the corresponding expectation implemented using the C++11 API is,
mock_c obj;
FORBID_CALL_V(obj, count());See also: FORBID_CALL(...).
Given mock class mock_c with mock function int count(),
struct mock_c
{
MAKE_MOCK0(count, int());
};and this expectation defined using the C++14 API,
mock_c obj;
auto e = NAMED_FORBID_CALL(obj, count());the corresponding expectation implemented using the C++11 API is,
mock_c obj;
auto e = NAMED_FORBID_CALL_V(obj, count());See also: NAMED_FORBID_CALL(...).
The C++11 API remains available when changing your C++ dialect to C++14 or later. Therefore existing test cases may be migrated incrementally to the C++14 API while using the C++14 API for new test cases.
Steps:
- Remove the
_Vsuffix from the expectation macro. - Move the modifiers, if any, outside the argument list of the expectation macro.
- Remove workarounds such as
- Changes to regular expressions that may be testing messages generated
with the
ANYmatcher. - Any of the workarounds required to use Trompeloeil with
g++ 4.8.3.
- Changes to regular expressions that may be testing messages generated
with the
For example, given this expectation using the C++11 API,
trompeloeil::sequence seq;
auto thrown = false;
REQUIRE_CALL_V(obj, getter(ANY(int)),
.IN_SEQUENCE(seq)
.LR_SIDE_EFFECT(thrown = true)
.THROW(_1));the corresponding C++14 API implementation is,
trompeloeil::sequence seq;
auto thrown = false;
REQUIRE_CALL(obj, getter(ANY(int)))
.IN_SEQUENCE(seq)
.LR_SIDE_EFFECT(thrown = true)
.THROW(_1);In the C++14 API, the RETURN(...)
modifier stores the expression passed as an argument to the
modifier and forwards it to the Trompeloeil implementation
for semantic analysis.
In the C++11 API, not only is the expression stored but also an implicit conversion to the return type of the mocked function is performed. This implicit conversion may fail before semantic checks are performed.
The result is that instead of a helpful message generated by
a static_assert, a less helpful error message is generated
by the compiler.
For example,
struct MS
{
MAKE_MOCK0(f, char&());
};
int main()
{
MS obj;
REQUIRE_CALL_V(obj, f(),
.RETURN('a'));
}The C++11 error message is,
error: invalid initialization of non-const reference of type
‘MS::trompeloeil_l_tag_type_trompeloeil_20::return_of_t {aka char&}’
from an rvalue of type ‘char’
The C++14 error message is,
error: static assertion failed:
RETURN non-reference from function returning reference
Other error messages that may not be generated while compiling using a C++11 dialect include:
RETURN const* from function returning pointer to non-const
RETURN const& from function returning non-const reference
RETURN value is not convertible to the return type of the function
This is a quality of implementation issue that wasn't resolved before the C++11 API became available.
Macro expansion differences between C++11 and C++14 expectation macros
mean macros like the ANY(...) matcher
used in the parameter list of the function to match are expanded in
C++11 before they are stringized.
For example, a regular expression written in a C++14 dialect, or later,
auto re = R":(Sequence expectations not met at destruction of sequence object "s":
missing obj\.getter\(ANY\(int\)\) at [A-Za-z0-9_ ./:\]*:[0-9]*.*
missing obj\.foo\(_\) at [A-Za-z0-9_ ./:\]*:[0-9]*.*
):";won't match the string generated when running in a C++11 dialect.
The ANY(int) matcher is actually expanded to some Trompeloeil-internal data.
A helper macro, such as CXX11_AS_STRING(), may be defined to give a
stringized form correct for C++11:
#define CXX11_AS_STRING_IMPL(x) #x
#define CXX11_AS_STRING(x) CXX11_AS_STRING_IMPL(x)It may be used in constructing larger strings. Rewriting the example above illustrates its use:
auto re = R":(Sequence expectations not met at destruction of sequence object "s":
missing obj\.getter\():" +
escape_parens(CXX11_AS_STRING(ANY(int))) +
R":(\) at [A-Za-z0-9_ ./:\]*:[0-9]*.*
missing obj\.foo\(_\) at [A-Za-z0-9_ ./:\]*:[0-9]*.*
):";where escape_parens() performs escaping of parentheses in the input string,
std::string escape_parens(const std::string& s)
{
constexpr auto backslash = '\\';
std::string tmp;
for (auto& c : s)
{
if (c == '(' || c == ')')
{
tmp += backslash;
}
tmp += c;
}
return tmp;
}This is a quality of implementation issue that wasn't resolved before the C++11 API became available.
Trompeloeil's support for g++ 4.8.x is limited by compiler and standard
library defects.
g++-4.8.3 and older suffers from bug 58714 which causes the
wrong overload to be selected when overloads for mock functions exists
for both T&& and const T& parameters.
Example:
struct S
{
MAKE_MOCK1(func, void(const int&));
MAKE_MOCK1(func, void(int&&));
};
void test()
{
S s;
REQUIRE_CALL_V(s, func(ANY(const int&)));
const int i = 0;
s.func(i);
}With g++-4.8.3 and older, this is reported as:
No match for call of func with signature void(const int&) with.
param _1 == 1
because the expectation is wrongly placed on the int&& overload.
Consider moving to a more modern compiler.
g++ 4.8.x lacks support for regular expressions in libstdc++-v3.
As Jonathan Wakely said,
sigh <regex> is not implemented prior to GCC 4.9.0, I thought the whole world was aware of that by now.
See: GCC Bugzilla, "Bug 61582 - C++11 regex memory corruption,"
23 June 2014.
Available: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Accessed: 9 November 2017
As a consequence, avoid the re(...) matcher
in test cases when compiling with a C++11 dialect.
g++-4.8.3 has a defect in <tuple> in libstdc++-v3.
See: GCC Bugzilla, "Bug 61947 - [4.8/4.9 Regression] Ambiguous calls when constructing std::tuple,"
29 July 2014.
Available: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947
Accessed: 8 November 2017
This is fixed in g++-4.8.4, g++-4.9.3 and later releases.
One workaround for this defect is to copy a version of <tuple> from a
release of g++-4.8.4 or g++-4.8.5 and arrange to include it
ahead of the buggy version. Then work hard to move forward to a more recent
compiler release.