Let's have this code using gmock 1.8:
#include "gtest/gtest.h"
#include "gmock/gmock.h"
#include <variant>
class Obj {
public:
MOCK_METHOD0( mock, void() );//<-!!!
};
using Variant = std::variant<Obj>;
TEST(Test, Test) {
Obj obj;
Variant variant = obj;
}
When trying to compile this with clang++ there is this compile error:
error: no viable conversion from 'Obj' to 'Variant' (aka 'variant<Obj>')
Variant variant = obj;
^ ~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/variant:1081:7: note: candidate constructor not viable: no known conversion from 'Obj' to 'const std::variant<Obj> &' for 1st argument
variant(const variant& __rhs) = default;
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/variant:1093:2: note: candidate template ignored: substitution failure [with _Tp = Obj &, $1 = void, $2 = void]: implicit instantiation of undefined template 'std::variant<Obj>::__to_type_impl<18446744073709551615, false>'
variant(_Tp&& __t)
^
(g++'s error only says
error: conversion from ‘Obj’ to non-scalar type ‘Variant’ {aka ‘std::variant<Obj>’} requested
Variant variant = obj;
^~~
)
When the line with MOCK_METHOD0 macro is commented out, the code compiles all right. I'm convinced it's the copy constructor (the one from line 1081) that gets invoked in that case.
Why is that? Will the problem disappear if I move to gmock 1.10? Or is it impossible to use variants of gmock mocks? Thanks for any explanation or a hint on how to find it myself.
If you expand the MOCK_METHOD0 macro, you will see that it inserts the following data member to your class definition:
class Obj
{
public:
// ...
mutable ::testing::FunctionMocker<void()> gmock0_mock_12;
};
Since you do not provide your own copy-constructor, one will be implicitly generated by the compiler. Its default implementation will try to perform a member-wise copy. However, checking the definition of FunctionMocker, one can see the following notice:
// There is no generally useful and implementable semantics of
// copying a mock object, so copying a mock is usually a user error.
// Thus we disallow copying function mockers. If the user really
// wants to copy a mock object, they should implement their own copy
// operation, for example:
//
// class MockFoo : public Foo {
// public:
// // Defines a copy constructor explicitly.
// MockFoo(const MockFoo& src) {}
// ...
// };
FunctionMocker(const FunctionMocker&) = delete;
FunctionMocker& operator=(const FunctionMocker&) = delete;
That is, FunctionMocker objects are non-copyable, and so are mock objects (their implicitly generated copy-constructors are also deleted).
That's reasonable. Should a copy of a mock have the same expectations? Should it double-check the expectations on destruction?
If you want to put the mock in a variant, you can build it in-place, either:
std::variant<Obj> variant(std::in_place_type_t<Obj>{});
or:
std::variant<Obj> variant;
variant.emplace<Obj>();
Related
I have a class MyClass as follows:
class MyClass {
public:
MyClass(vector<vector<float>> arg) {
// some code here
}
MyClass(std::initializer_list<std::initializer_list<float>> arg)
: MyClass(vector<vector<float>>(arg)) {
}
// other class members
};
I'm trying to use a delegating constructor above, as I want an instance of MyClass to be constructed from both std::initializer_list<std::initializer_list<float>> and vector<vector<float>> types, and the constructor code blocks are identical. So I'm trying to delegate the construction of the nested initializer lists by initializing a multidimensional vector and using its constructor.
However, the above code gives me a compiler error:
no instance of constructor "std::__1::vector<_Tp, _Allocator>::vector [with _Tp=std::__1::vector<float, std::__1::allocator<float>>, _Allocator=std::__1::allocator<std::__1::vector<float, std::__1::allocator<float>>>]" matches the argument list -- argument types are: (std::initializer_list<std::initializer_list<float>>)
In file included from /opt/wandbox/gcc-9.3.0/include/c++/9.3.0/vector:67,
from prog.cc:11:
/opt/wandbox/gcc-9.3.0/include/c++/9.3.0/bits/stl_vector.h:622:7: note: candidate: 'std::vector<_Tp, _Alloc>::vector(std::initializer_list<_Tp>, const allocator_type&) [with _Tp = std::vector<float>; _Alloc = std::allocator<std::vector<float> >; std::vector<_Tp, _Alloc>::allocator_type = std::allocator<std::vector<float> >]'
622 | vector(initializer_list<value_type> __l,
| ^~~~~~
/opt/wandbox/gcc-9.3.0/include/c++/9.3.0/bits/stl_vector.h:622:43: note: no known conversion for argument 1 from 'initializer_list<std::initializer_list<float>>' to 'initializer_list<std::vector<float>>'
622 | vector(initializer_list<value_type> __l,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
What am I doing wrong here?
The initializer_list constructor for std::vector looks like:
vector(std::initializer_list<value_type>)
Where value_type is the first template argument to std::vector. In this case, std::vector<std::vector<float>> has value_type = std::vector<float> -- which means that it can only be constructed from a std::initializer_list<std::vector<float>> directly.
In order for this to work, you will need to update in one of the following ways:
update your std::initializer_list to be std::initializer_list<std::vector<float>>,
just use the std::vector<std::vector<float>> constructor and ignore using the initializer_list entirely1, or
Range construct from the initializer_list<initializer_list<float>> in the constructor`:
MyClass(std::initializer_list<std::initializer_list<float>> arg)
: vec{arg.begin(), arg.end()}
{
// each iterator points to an initializer_list, which implicitly
// constructs each vector
}
Edit: Since this question is asking with respect to delegating constructors, you would be stuck explicitly constructing a temporary vector-of-vectors first:
MyClass(std::initializer_list<std::initializer_list<float>> arg)
: MyClass{std::vector<std::vector<float>>{arg.begin(), arg.end()}}
This is a case where delegating constructors probably aren't the best solution to your problem. See below.
1 Since std::vector already works properly with initializer lists, even when nested in other types, it would probably be easiest to just ignore adding an explicit std::initializer_list constructor entirely -- and just use move semantics properly in the implementation.
If you're using std::move properly, this constructor should be relatively cheap anyway -- which could make the initializer list functionality come for free.
You need vector of floats in std::initializer_list;
I believe this is what you are looking for
class MyClass{
public:
MyClass(vector<vector<float>> arg ): vec( arg) {
// some code here
}
MyClass(std::initializer_list<std::vector<float>> arg)
: vec( arg ) {};
// other class members
private:
std::vector<vector<float>> vec;
};
When attempting to delete the default constructor and provide a new one with a default parameter (and therefore still be able to default construct the object), I receive an ambiguity error from g++.
class Thing
{
public:
Thing() = delete;
Thing(int arg = 0) : arg(arg) {}
private:
int arg;
};
int main(int, char**)
{
Thing thing;
return 0;
}
Compilation error below:
$ g++ deletedConstructorTest.C -std=c++11
deletedConstructorTest.C: In function "int main(int, char**)":
deletedConstructorTest.C:12:9: error: call of overloaded "Thing()" is ambiguous
Thing thing;
^
deletedConstructorTest.C:12:9: note: candidates are:
deletedConstructorTest.C:5:5: note: Thing::Thing(int)
Thing(int arg = 0) :arg(arg) {}
^
deletedConstructorTest.C:4:5: note: Thing::Thing() <deleted>
Thing() = delete;
^
If I modify the example above by removing the "Thing() = delete;" line then it compiles fine. I understand that the compiler won't generate a default constructor since I provided my own so that line is unnecessary but I was surprised at the compilation error.
Thanks in advance!
All declared overloads are considered during overload resolution, even if they are deleted or inaccessible. So you've declared two default constructors, both of which are an equally good match for default-initialisation, hence the ambiguity.
In this case, simply don't declare the zero-argument default constructor at all. The one-argument constructor is usable as a default constructor, and declaring any constructor inhibits the generation of an implicit default constructor.
Compiling this code snippet with clang-425.0.27 ( based on LLVM3.2svn) :
class CStorage
{};
typedef boost::shared_ptr< CStorage > AccessorPtr;
class CTest
{
public:
CTest( const CStorage &rAccessor )
: m_Accessor( rAccessor ){}
private:
AccessorPtr m_Accessor;
};
Getting compilation error:
**error**: no matching constructor for initialization of 'AccessorPtr' (aka 'shared_ptr<CStorage>')
: m_Accessor( rAccessor ){}
**note**: candidate constructor (the implicit copy constructor) not viable: no known conversion from
'const FNPNS::TSM::CDirectBlockAccessor' to 'const boost::shared_ptr<FNPNS::TSM::CDirectBlockAccessor>' for 1st argument
template<class T> class shared_ptr
The boost::shared_ptr constructor wants a pointer, you're passing it a reference. You might want to change your own constructor to take a pointer as well, or create a new CStorage object on the heap using the reference.
As #Joachim suggested your ctor expects a pointer.
It might be better to pass a shared pointer (or a weak pointer, depending on your use case) which will keep the pointer in memory.
I get compilation errors on g++ (GCC) 4.7.2 but not on MSVC-2012 when trying to std::vector::push_back a non-copyable (private copy constructor) but moveable object. To me my example looks identical to many other examples on SO and elsewhere. The error message makes it looks like a problem with the struct not being 'direct constructible' - I don't know what this means so am doubly unsure about why an object needs to be 'direct constructible' to be pushed back.
#include <vector>
#include <memory>
struct MyStruct
{
MyStruct(std::unique_ptr<int> p);
MyStruct(MyStruct&& other);
MyStruct& operator=(MyStruct&& other);
std::unique_ptr<int> mP;
private:
// Non-copyable
MyStruct(const MyStruct&);
MyStruct& operator=(const MyStruct& other);
};
int main()
{
MyStruct s(std::unique_ptr<int>(new int(5)));
std::vector<MyStruct> v;
auto other = std::move(s); // Test it is moveable
v.push_back(std::move(other)); // Fails to compile
return 0;
}
Gives errors
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/type_traits: In instantiation of ‘struct std::__is_direct_constructible_impl<MyStruct, const MyStruct&>’:
... snip ...
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:900:9: required from ‘void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = MyStruct; _Alloc = std::allocator<MyStruct>; std::vector<_Tp, _Alloc>::value_type = MyStruct]’
main.cpp:27:33: required from here
main.cpp:16:5: error: ‘MyStruct::MyStruct(const MyStruct&)’ is private
Simple workaround from various answers:
Use MyStruct(const MyStruct&) = delete; instead of private ctor hack
Inherit boost::noncopyable (or another class with private ctor)
The failure is due to a limitation of G++ 4.7, which doesn't implement DR 1170, which was changed very late in the C++11 standardisation process to say that access checking should be done as part of template argument deduction.
The underlying cause is that libstdc++'s vector will move elements if the move operation is guaranteed not to throw (i.e. it's declared noexcept or throw()), otherwise if the type is copyable the elements will be copied, otherwise if the type is not copyable but does have a possibly-throwing move operation then it will be moved (and if an exception is thrown the results are undefined unspecified.) This is implemented with checks to the is_nothrow_move_constructible and is_copy_constructible type traits. In your case, the type is not nothrow move constructible, so the is_copy_constructible trait is checked. Your type has a copy constructor but it's not accessible, so the is_copy_constructible trait produces a compiler error with G++ 4.7 because access checking is not done during template argument deduction.
If you make your move constructor and move assignment operator noexcept then the type will be moved and doesn't need to be copyable, so the is_copy_constructible trait that fails is not used, and the code compiles OK.
Alternatively, (as also stated in the comments) if you make the copy constructor deleted then the is_copy_constructible trait gets the right result.
Another alternative is to use something like boost::noncopyable which implicitly makes the copy constructor deleted so the is_copy_constructible trait works properly (and also works with older compilers like MSVC that don't support deleted functions properly). I don't know what you mean about making it impossible to find the error, does MSVC not show you the full context of a compiler error?
Conclusion: use unique_ptr where appropriate but don't make classes explicitly movable
I disagree with this conclusion, it is too extreme. Instead make your classes nothrow movable whenever possible. Also, when possible, use deleted functions to make a type non-copyable instead of private+unimplemented functions, maybe using a macro for portability to older compilers e.g.
#if __cplusplus >= 201103L
#define NONCOPYABLE(TYPE) \
TYPE(const TYPE&) = delete; TYPE& operator=(const TYPE&) = delete
#else
// must be used in private access region
#define NONCOPYABLE(TYPE) \
TYPE(const TYPE&); TYPE& operator=(const TYPE&)
#endif
struct MyStruct
{
...
private:
NONCOPYABLE(MyStruct);
};
I'm currently trying to use Howard Hinnant's unique_ptr implementation, and am running into a compile error. Here is some sample code:
struct Base {};
struct Derived : public Base {};
void testfun(boost::unique_ptr<Base>);
void test()
{
unique_ptr<Derived> testDerived;
unique_ptr<Base> testBase(move(testDerived)); // ok, construct base explicitly from derived
testfun(move(testBase)); // ok, pass base to testfun which expects base
testfun(unique_ptr<Base>(move(testDerived))); // ok, explicitly converts to unique_ptr<Base>
testfun(move(testDerived)); // error on this line
}
The error I get is
In function 'void test()':
error: no matching function for call to 'boost::unique_ptr<Base, boost::default_delete<Base> >::unique_ptr(boost::unique_ptr<Base, boost::default_delete<Base> >)'
note: candidates are: boost::unique_ptr<T, D>::unique_ptr(boost::detail_unique_ptr::rv<boost::unique_ptr<T, D> >) [with T = Base, D = boost::default_delete<Base>]
note: boost::unique_ptr<T, D>::unique_ptr(boost::unique_ptr<T, D>&) [with T = Base, D = boost::default_delete<Base>]
error: initializing argument 1 of 'void testfun(boost::unique_ptr<Base, boost::default_delete<Base> >)' from result of 'boost::unique_ptr<T, D>::unique_ptr(boost::unique_ptr<U, E>, typename boost::enable_if_c<((((! boost::is_array<U>::value) && boost::detail_unique_ptr::is_convertible<typename boost::unique_ptr<U, boost::default_delete<U> >::pointer,typename boost::detail_unique_ptr::pointer_type<T, D>::type>::value) && boost::detail_unique_ptr::is_convertible<E,D>::value) && ((! boost::is_reference<D>::value) || boost::is_same<D,E>::value)), void>::type*) [with U = Derived, E = boost::default_delete<Derived>, T = Base, D = boost::default_delete<Base>]'
It seems like the offending line should not fail. Is this a bug in the implementation, a limitation of the implementation due to the lack of C++0x language features, or a misunderstanding of the rules of unique_ptrs?
(Note, I know this won't work at run-time because I'm moving the same thing more than once; I'm just trying to figure out the compile-time error.)
For a similar example, see this which should fail too
unique_ptr<Base> testBase = move(testDerived);
The problem here is how the move semantic is implemented: The "copy constructor" takes a non-const reference, thus not being able to bind to temporaries. To still "move" from temporaries, the class has a conversion function (following are really just conceptual - they may be differently implemented in detail):
operator rv<T>() { return rv<T>(*this); }
And a constructor will take that object:
unique_ptr(rv<T> r):ptr_(r.release()) { }
Here is an example that fails for the same reason:
// move helper. rv<> in unique_ptr
struct E { };
// simulates a unique_ptr<D>
struct D { };
// simulates the unique_ptr<B>
struct A {
A() { }
// accepts "derived" classes. Note that for unique_ptr, this will need that
// the argument needs to be copied (we have a by-value parameter). Thus we
// automatically ensure only rvalue derived-class pointers are accepted.
A(D) { }
// these will accept rvalues
A(E) { }
operator E() { return E(); }
private:
A(A&); // private, error if passed lvalue
};
Now, consider this code:
// allowed: goes: D -> A(D)
A a((D()));
// compile failure. Goes:
// D -> A(D) -> A(E)
A a = D();
Copy initialization will first convert to A. But then, the temporary A object is tried to be copied again to the final object. This will need the way using operator E. But that's another user defined conversion in the initialization, which the standard forbids:
13.3.3.1/4
When invoked for the copying of the temporary in the second step of a class copy-initialization, [...], only standard conversion sequences and ellipsis conversion sequences are allowed.
This is why your code fails.
Further research has lead me to this note, leading me to believe that this is a known limitation of the implementation:
3 of the tests currently fail for me (fail at compile time,
supposed to compile, run and pass). These are all associated with the
converting constructor specified in [unique.ptr.single.ctor]. When
the source and target are of different type, this emulation demands
that the conversion be explicit, and refuses to compile on implicit
conversions:
unique_ptr<base> b(unique_ptr<derived>()); // ok
unique_ptr<base> b = unique_ptr<derived>(); // causes 3 compile time failures under unique.ptr/unique.ptr.single/unique.ptr.single.ctor .