I have a class whose constructor accepts const string &.
When I use auto to define a object with string as parameter. The type deduction result is a string, instead of my custom class.
Which rule does apply here?
class AB{
public:
AB(const string& a){
}
};
int main()
{
string a {"a"};
auto b("b"s);
cout<<a<<endl<<b<<endl;
return 0;
}
According to Placeholder type deduction:
Placeholder type deduction is the process by which a type containing a placeholder type is replaced by a deduced type.
A type T containing a placeholder type, and a corresponding initializer-clause E, are determined as follows:
[...]
For a variable declared with a type that contains a placeholder type, T is the declared type of the variable.
[...]
If the initializer is a parenthesized expression-list, the expression-list shall be a single assignment-expression and E is the assignment-expression.
[...]
If the placeholder-type-specifier is of the form type-constraintopt auto, the deduced type T′ replacing T is determined using the rules for template argument deduction. [...] Obtain P from T by replacing the occurrences of type-constraintopt auto either with a new invented type template parameter U[...]. Deduce a value for U using the rules of template argument deduction from a function call, where P is a function template parameter type and the corresponding argument is E. If the deduction fails, the declaration is ill-formed. Otherwise, T′ is obtained by substituting the deduced U into P.
So according to the rule, when you have the statement auto b("b"s);, "b"s is considered the initializer-clause E, and the deducting type of b is T. The deduction would work as passing E to a templated function:
template <class U> void f(U u);
with a call like f(E), and the deducted T will be obtained from U. Since your E is "b"s, and passing that to the templated function will result U to be an std::string, hence b is deducted to be a std::string.
If you want to force b to be of AB type, you can rewrite you code to something like:
auto b = AB("b"s);
or:
auto b(AB("b"s));
or for C++17 or later you can also do:
auto b{AB("b"s)};
Related
I implemented a list with similar API to std::list but it fails to compile
struct A { my_list<A> v; };
The list has a base class that has a member a base_node which has the prev and next fields and node (which is derived from base_node) holds the T value (which is the template parameter for the list). The compilation error is
error: ‘node<T>::val’ has incomplete type
T val;
^~~
note: forward declaration of ‘struct A’
I looked in GCC code and it seems like they hold a buffer of bytes of size T so not sure how it works for them. How std::list manages to store A in its nodes?
[UPDATE]
struct A { };
template <typename T>
struct B : public A
{
using B_T = B<T>;
T t;
};
template <typename T>
class C
{
using B_T = typename B<T>::B_T; // this fails to compile
//using B_T = B<T>; // this compiles fine
};
struct D { C<D> d; };
In your simplified example
struct A { };
template <typename T>
struct B : public A
{
using B_T = B<T>;
T t;
};
template <typename T>
class C
{
using B_T = typename B<T>::B_T; // this fails to compile
//using B_T = B<T>; // this compiles fine
};
struct D { C<D> d; };
you're running into the gotchas of class template instantiation.
First, note that a class definition has essentially two parse passes (not necessarily implemented this way):
First determine the types of base classes and class members. During this process, the class is considered incomplete, although previously declared bases and members can be used by later code in the definition.
In some pieces of code within the class definition which does not affect the types of bases or members, the class is considered complete. These places include member function definition bodies, member function default arguments, static member initializers, and non-static member default initializers.
For example:
struct S {
std::size_t n = sizeof(S); // OK, S is complete
std::size_t f() const { return sizeof(S); } // OK, S is complete
using array_type = int[sizeof(S)]; // Error, S incomplete
void f(int (&)[sizeof(S)]); // Error, S incomplete
};
Templates make this trickier because they make it easier to accidentally indirectly use a class which is not yet complete. This particularly comes up in CRTP code, but this example is another simple way it can happen.
The basic way class template instantiation works (a bit simplified) is:
Just naming a class template specialization, like X<Y>, does not by itself cause the class template to be instantiated.
Using a class template specialization in ways valid for an incomplete class type does not cause the template to be instantiated.
Using a class template specialization in any way which requires the type to be complete, like naming a member of the class or defining a variable with the class type (not pointer or reference), causes an implicit instantiation of the template.
Instantiating a class template involves determining the types of the base classes and members, much like the "first pass" of class definition parsing. All those base and member types must be valid at that time. Instantiating member definitions is for the most part delayed until each member is needed, but there is no selective instantiation of member types in this step: it's all or error.
The process can be recursive when a base class or member declaration involves another template specialization. But during that other instantiation, the class type for the original instantiation context is considered incomplete.
Looking at the example, struct D defines a member C<D> d; which requires C<D> to be complete, so we attempt to instantiate the specialization C<D>. So far, D is incomplete.
There's just one member of C<D>, which is
using B_T = typename B<D>::B_T;
Since this names a member of another class template specialization B<D>, now we have to attempt to instantiate that B<D> specialization. So far, D and C<D> are still incomplete.
B<D> has one base class, which is just A. It has two members:
using B_T = B<D>;
D t;
The member type B<D>::B_T is fine since just naming B<D> doesn't require a complete type. But instantiating B<D> requires both members to be well-formed. A class member can't have an incomplete class as its type, but type D is still incomplete right now.
As you noticed, you can work around this by avoiding naming the member B<T>::B_T and directly using the type B<T> instead. Or you could move the original B_T definition to some other base class or traits struct, and make sure its new location is one that can be instantiated with an incomplete type as argument.
Many templates just assume their arguments must always be complete types. But they can be useful in more situations if they're carefully written with considerations about how the code uses template arguments and other indirectly used dependent types, which might be incomplete at the point of instantiation.
This is part of an assignment, I am stuck at this instruction:
Sort your randomly generated pool of schedules.
Use std::stable_sort,
passing in an object of type schedule_compare as the custom comparison
operator.
UPDATE: I was checking cppreference stable_srot(), see method definition below:
void stable_sort ( RandomAccessIterator first, RandomAccessIterator
last,Compare comp );
, and it seems from what I understood is that you can only pass functions to the last argument (Compare comp) of the stable_sort() i.e:
However, in the instructions, it says that you need to pass an object of type schedule_compare. How is this possible ?
This is my code below:
struct schedule_compare
{
explicit schedule_compare(runtime_matrix const& m)
: matrix_{m} { }
bool operator()(schedule const& obj1, schedule const& obj2) {
if (obj1.score > obj2.score)
return true;
else
return false;
}
private:
runtime_matrix const& matrix_;
};
auto populate_gene_pool(runtime_matrix const& matrix,
size_t const pool_size, random_generator& gen)
{
std::vector<schedule> v_schedule;
v_schedule.reserve(pool_size);
std::uniform_int_distribution<size_t> dis(0, matrix.machines() - 1);
// 4. Sort your randomly generated pool of schedules. Use
// std::stable_sort, passing in an object of type
// schedule_compare as the custom comparison operator.
std::stable_sort(begin(v_schedule), end(v_schedule), ???)
return; v_schedule;
}
For algorithm functions that accepts a "function" (like std::stable_sort) you can pass anything that can be called as a function.
For example a pointer to a global, namespace or static member function. Or you can pass a function-like object instance (i.e. an instance of a class that has a function call operator), also known as a functor object.
This is simply done by creating a temporary object, and passing it to the std::stable_sort (in your case):
std::stable_sort(begin(v_schedule), end(v_schedule), schedule_compare(matrix));
Since the schedule_compare structure have a function call operator (the operator() member function) it can generally be treated like any other function, including being "called".
The following code will not compile on gcc 4.8.2.
The problem is that this code will attempt to copy construct an std::pair<int, A> which can't happen due to struct A missing copy and move constructors.
Is gcc failing here or am I missing something?
#include <map>
struct A
{
int bla;
A(int blub):bla(blub){}
A(A&&) = delete;
A(const A&) = delete;
A& operator=(A&&) = delete;
A& operator=(const A&) = delete;
};
int main()
{
std::map<int, A> map;
map.emplace(1, 2); // doesn't work
map.emplace(std::piecewise_construct,
std::forward_as_tuple(1),
std::forward_as_tuple(2)
); // works like a charm
return 0;
}
As far as I can tell, the issue isn't caused by map::emplace, but by pair's constructors:
#include <map>
struct A
{
A(int) {}
A(A&&) = delete;
A(A const&) = delete;
};
int main()
{
std::pair<int, A> x(1, 4); // error
}
This code example doesn't compile, neither with coliru's g++4.8.1 nor with clang++3.5, which are both using libstdc++, as far as I can tell.
The issue is rooted in the fact that although we can construct
A t(4);
that is, std::is_constructible<A, int>::value == true, we cannot implicitly convert an int to an A [conv]/3
An expression e can be implicitly converted to a type T if and only if the declaration T t=e; is well-formed,
for some invented temporary variable t.
Note the copy-initialization (the =). This creates a temporary A and initializes t from this temporary, [dcl.init]/17. This initialization from a temporary tries to call the deleted move ctor of A, which makes the conversion ill-formed.
As we cannot convert from an int to an A, the constructor of pair that one would expect to be called is rejected by SFINAE. This behaviour is surprising, N4387 - Improving pair and tuple analyses and tries to improve the situation, by making the constructor explicit instead of rejecting it. N4387 has been voted into C++1z at the Lenexa meeting.
The following describes the C++11 rules.
The constructor I had expected to be called is described in [pairs.pair]/7-9
template<class U, class V> constexpr pair(U&& x, V&& y);
7 Requires: is_constructible<first_type, U&&>::value is true and
is_constructible<second_type, V&&>::value is true.
8 Effects: The
constructor initializes first with std::forward<U>(x) and second with
std::forward<V>(y).
9 Remarks: If U is not implicitly convertible to
first_type or V is not implicitly convertible to second_type this
constructor shall not participate in overload resolution.
Note the difference between is_constructible in the Requires section, and "is not implicitly convertible" in the Remarks section. The requirements are fulfilled to call this constructor, but it may not participate in overload resolution (= has to be rejected via SFINAE).
Therefore, overload resolution needs to select a "worse match", namely one whose second parameter is a A const&. A temporary is created from the int argument and bound to this reference, and the reference is used to initialize the pair data member (.second). The initialization tries to call the deleted copy ctor of A, and the construction of the pair is ill-formed.
libstdc++ has (as an extension) some nonstandard ctors. In the latest doxygen (and in 4.8.2), the constructor of pair that I had expected to be called (being surprised by the rules required by the Standard) is:
template<class _U1, class _U2,
class = typename enable_if<__and_<is_convertible<_U1, _T1>,
is_convertible<_U2, _T2>
>::value
>::type>
constexpr pair(_U1&& __x, _U2&& __y)
: first(std::forward<_U1>(__x)), second(std::forward<_U2>(__y)) { }
and the one that is actually called is the non-standard:
// DR 811.
template<class _U1,
class = typename enable_if<is_convertible<_U1, _T1>::value>::type>
constexpr pair(_U1&& __x, const _T2& __y)
: first(std::forward<_U1>(__x)), second(__y) { }
The program is ill-formed according to the Standard, it is not merely rejected by this non-standard ctor.
As a final remark, here's the specification of is_constructible and is_convertible.
is_constructible [meta.rel]/4
Given the following function prototype:
template <class T>
typename add_rvalue_reference<T>::type create();
the predicate condition for a template specialization is_constructible<T, Args...> shall be satisfied if and only if the following variable definition would be well-formed for some invented variable t:
T t(create<Args>()...);
[Note: These tokens are never interpreted as a function declaration. — end note] Access checking is performed as if in a context unrelated to T and any of the Args. Only the validity of the immediate context of the variable initialization is considered.
is_convertible [meta.unary.prop]/6:
Given the following function prototype:
template <class T>
typename add_rvalue_reference<T>::type create();
the predicate condition for a template specialization is_convertible<From, To> shall be satisfied if and
only if the return expression in the following code would be well-formed, including any implicit conversions
to the return type of the function:
To test() {
return create<From>();
}
[Note: This requirement gives well defined results for reference types, void types, array types, and function types. — end note] Access checking is performed as if in a context unrelated to To and From. Only
the validity of the immediate context of the expression of the return-statement (including conversions to
the return type) is considered.
For your type A,
A t(create<int>());
is well-formed; however
A test() {
return create<int>();
}
creates a temporary of type A and tries to move that into the return-value (copy-initialization). That selects the deleted ctor A(A&&) and is therefore ill-formed.
"Theory" question if you will.
In order to execute/make use of the move constructor in a class, do I always have to use std::move(...) to tell the compiler that I wish to 'move' an object rather than copy it?
Are there any cases where the compiler will invoke the move constructor for me without the use of std::move? (My guess would be in function return values?)
According to cppreference.com (http://en.cppreference.com/w/cpp/language/move_constructor):
The move constructor is called whenever an object is initialized from xvalue of the same type, which includes
initialization, T a = std::move(b); or T a(std::move(b));, where b is of type T;
function argument passing: f(std::move(a));, where a is of type T and f is void f(T t);
function return: return a; inside a function such as T f(), where a is of type T which has a move constructor.
In most cases, yes std::move is needed.
The compiler will invoke the move constructor without std::move when:
returning a local variable by value
when constructing an object from an rvalue of the same type
In all other cases, use std::move. E.g.:
struct S {
std::string name;
S(std::string name) : name(std::move(name)) {}
};
and
std::unique_ptr<Base> func() {
auto p = std::make_unique<Derived>();
return std::move(p); // doesn't work without std::move
}
std::move is just a cast.
unique_ptr<int> global;
auto v = unique_ptr<int>(global); // global is a lvalue, therefore the
unique_ptr(unique_ptr<T>&v) constructor that accepts lvalue references is called.
auto v = unique_ptr<int>(std::move(global)); // move returns a &&rvalue reference, therefore the
unique_ptr(unique_ptr<T>&&v) constructor that accepts &&rvalue references is used.
When the criteria for elision of a copy operation are met and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue.
therefore,
unique_ptr<int> hello()
{
unique_ptr<int> local;
return local;
// local is an lvalue, but since the critera for elision is met,
// the returned object is created using local as if it was an rvalue
}
Also,
unique_ptr<int> hello = std::unique_ptr<int>();
// we have a pure rvalue in the right, therefore no std::move() cast is needed.
I am trying to get more familiar with the C++11 standard by implementing the std::iterator on my own doubly linked list collection and also trying to make my own sort function to sort it.
I would like the sort function to accept a lamba as a way of sorting by making the sort accept a std::function, but it does not compile (I do not know how to implement the move_iterator, hence returning a copy of the collection instead of modifying the passed one).
template <typename _Ty, typename _By>
LinkedList<_Ty> sort(const LinkedList<_Ty>& source, std::function<bool(_By, _By)> pred)
{
LinkedList<_Ty> tmp;
while (tmp.size() != source.size())
{
_Ty suitable;
for (auto& i : source) {
if (pred(suitable, i) == true) {
suitable = i;
}
}
tmp.push_back(suitable);
}
return tmp;
}
Is my definition of the function wrong? If I try to call the function, I recieve a compilation error.
LinkedList<std::string> strings{
"one",
"two",
"long string",
"the longest of them all"
};
auto sortedByLength = sort(strings, [](const std::string& a, const std::string& b){
return a.length() < b.length();
});
Error: no instance of function template "sort" matches the argument
list argument types are: (LinkedList, lambda []bool
(const std::string &a, const std::string &)->bool)
Additional info, the compilation also gives the following error:
Error 1 error C2784: 'LinkedList<_Ty> sort(const
LinkedList<_Ty> &,std::function)' : could not
deduce template argument for 'std::function<bool(_By,_By)>'
Update: I know the sorting algorithm is incorrect and would not do what is wanted, I have no intention in leaving it as is and do not have a problem fixing that, once the declaration is correct.
The problem is that _By used inside std::function like this cannot be deduced from a lambda closure. You'd need to pass in an actual std::function object, and not a lambda. Remember that the type of a lambda expression is an unnamed class type (called the closure type), and not std::function.
What you're doing is a bit like this:
template <class T>
void foo(std::unique_ptr<T> p);
foo(nullptr);
Here, too, there's no way to deduce T from the argument.
How the standard library normally solves this: it does not restrict itself to std::function in any way, and simply makes the type of the predicate its template parameter:
template <typename _Ty, typename _Pred>
LinkedList<_Ty> sort(const LinkedList<_Ty>& source, _Pred pred)
This way, the closure type will be deduced and all is well.
Notice that you don't need std::function at all—that's pretty much only needed if you need to store a functor, or pass it through a runtime interface (not a compiletime one like templates).
Side note: your code is using identifiers which are reserved for the compiler and standard library (identifiers starting with an underscore followed by an uppercase letter). This is not legal in C++, you should avoid such reserved identifiers in your code.