For example, c++ std::find_if is implemented like:
template <class InputIter, class UnaryPredicate>
InputIter find_if(InputIter begin, InputIter end, UnaryPredicate pred) {
for (; begin != end; begin++) {
if (pred(*begin))
return begin;
}
return end;
}
InputIter should be std::input_iterator_tag type, but in this function, any type which has operator++ operator++(int) can be compiled.
UnaryPredicate should be something like bool function(const T &value), but any function return int double can be compiled.
Is STL template parameter precise enough ? It seems doesn't check all possible error when compiling.
Can we implement it like:
template <T, Iter<? super std::input_iterator<T>>, Pred<? implement bool (const T&)>>
Iter find_if(Iter begin, Iter end, Pred p) {
for (; begin != end; begin++) {
if (p(*begin))
return begin;
}
return end;
}
In this fake code, I want find_if work for type T, it has range in [begin, end), and use bool (const T &) to check if it is statisfied ?
There are two different questions hiding here. I don't know which one you intend to ask.
First one about find_if. The way find_if is defined explicitly allows the parameter types you want to reject, and that is usually considered as a feature. So implementing checks one way or another would not be conformant and would reject valid code.
The second is about the C++ language. It does not currently offer a way to check or even describe constraints on template parameters more explicitly than by checking usage. The name used in C++ circles for such a system is concept. There are libraries aiming to help checking them (in boost for instance), and there is a Technical Specification which has been implemented in GCC describing how the language could be extended to include a language defined notion of concept, but that TS has not yet been incorporated in the standard.
Related
There are a plenty functions in STL of form:
result_type algorithm(ForwardIterator beg, ForwardIterator end);
or
result_type algorithm(BidirectionalIterator beg, BidirectionalIterator end);
Is there portable and convenient way to determine, whether an end iterator is potentially reachable from a beg by simple incrementation of the former (and vice versa in case of bidirectional iterator)? How should looks like corresponding assert(?); on the first line of above kind of algorithms?
The intention is to detect errors like std::list< int > l(10); std::iota(std::end(l), std::begin(l), 0); as early as it possible until UB occures.
Are there any proposals or is there something in Range-V3 library to deal with the issue?
I've written a lot of code using std::vector<T> and std::vector<T>::iterator. Now I've decided to replace the vector container with a circular buffer from boost, namely boost::circular_buffer<T>.
Of course now the compiler will complain for every function that uses std::... where I'm passing the boost::... counterpart. Do I have to rewrite all functions now? I'm asking since the container from boost works exactly the same. Also the Boost documentation states the following:
The circular_buffer is a STL compliant container. It is a kind of sequence similar to std::list or std::deque.
What does the "STL compliant" part mean? Is it referring to what I would like to do (interchangability) or is it simply a mental note for programmers, that the containers work the same way in boost as in STL?
EDIT: To give an example
class Item{ };
class Queue{
private:
std::vector<Item*> item_vector; // Want to replace only this...
std::vector<Item*>::iterator current_position; // ...and this
public:
Item* get_current_item() const {
return *current_position;
}
std::vector<Item*> get_item_vector(){
return item_vector;
}
};
Do I have to rewrite all functions now?
If your functions specifically use vector and its iterator types, then yes, you will have to change them to use different types.
If they are templates, designed to work with any sufficiently compatible container and iterator types, then they should work without change.
What does the "STL compliant" part mean?
It usually means it follows the specification for an iterable sequence defined by the C++ standard library (which was influenced by the ancient STL library, whose name some people loosely use to refer to some or all of the modern standard library).
For example, it has begin() and end() member functions returning an iterator type; and the iterator types can be incremented with ++ and dereferenced with *.
This means that an algorithm implemented as a template, for example:
template <typename InputIterator, typename T>
InputIterator find(InputIterator begin, InputIterator end, T const & value) {
for (InputIterator it = begin; it != end; ++it) {
if (*it == value) {
return it;
}
}
return end;
}
will work for any iterator type that supports these operations. While a non-generic function
void find(some_iterator begin, some_iterator end, some_type t);
will only work for a single specific iterator type, and will have to be changed or duplicated to support others.
I'm trying to implement a function which allows the user to input some type of begin and end iterator, then all perform some operation on the data. However, the function has to be generic enough it should work for many types of iterators (for example std::vector::iterator, std::string::iterator, std::iterator, etc.). The only limit is that the iterators have to be at least forward_iterator_tag capabilities.
My function prototype looks like this:
template <class key_type, class data_type> std::shared_ptr<data_type>
remove(std::iterator<std::forward_iterator_tag, key_type> key_start,
std::iterator<std::forward_iterator_tag, key_type> key_end);
However, this limits me to using specifically a forward_iterator_tag iterator, so trying to call the function like this:
remove<char, char>(std::iterator<std::random_access_iterator_tag, char>(), std::iterator<std::random_access_iterator_tag, char());
will fail because the compiler can't convert a std::iterator<std::random_access_iterator_tag,...> to a std::iterator<std::forward_access_iterator_tag,...>. Additionally, this method does not work for string iterators, vector iterators, or other stl iterators.
Does someone know how the stl implements the containers/strings to accept iterators from each other? For example, this compiles correctly:
std::string a = "hello";
std::vector<char> v(a.begin(), a.end());
template < typename Iter >
void fun_impl(Iter begin, Iter end, std::forward_iterator_tag)
{
// do your stuff here...
}
template < typename Iter >
void fun(Iter begin, Iter end)
{
fun_impl(begin,end, std::iterator_traits<Iter>::iterator_category());
}
The types returned by begin() and end() for various containers are not of type iterator<category...> but subclasses of such (sometimes). You never, when you're writing generic code, target a specific iterator type. Instead you use "tag dispatching" to classify the iterator and call the correct implementation. Since random_iterator_tag is-a forward_iterator_tag it will be automatically converted to such so that the above fun_impl will resolve correctly for any forward_iterator or extension.
I'm still trying to implement my own version of LinkedList class and now I have problems with overloading methods for constant iterators. For example, when I try to print out list using this code:
cout << "citer:" << endl;
for (UberList<int>::CIter it = ulist.begin(); it != ulist.end(); ++it)
{
cout << *it << " ";
}
cout << endl;
I have these errors:
Error E2034 UberList2.cpp 532: Cannot convert 'UberList<int>::Iter' to 'UberList<int>::CIter' in function main()
Error E2094 UberList2.cpp 532: 'operator!=' not implemented in type 'UberList<int>::CIter' for arguments of type 'UberList<int>::Iter' in function main()
so as far as I understood, it means that those usual end and begin iterator methods are used. Here's how these methods are declared in my class:
Iter begin();
Iter end();
CIter begin() const;
CIter end() const;
and
template<class T>
typename UberList<T>::Iter UberList<T>::begin()
{
Iter it;
it.curr = head;
return it;
}
template<class T>
typename UberList<T>::Iter UberList<T>::end()
{
Iter it;
it.curr = tail->next;
return it;
}
template<class T>
typename UberList<T>::CIter UberList<T>::begin() const
{
CIter it;
it.ccurr = head;
return it;
}
template<class T>
typename UberList<T>::CIter UberList<T>::end() const
{
CIter it;
it.ccurr = tail->next;
return it;
}
Is there any way I can force my program to use these const methods for constant iterators instead of usual ones? I'd be glad to hear any advice.
Oh and here's the code of my class in one file just in case: http://pastebin.com/Jbvv5Hht
You should provide a conversion from Iter to CIter. Standard containers do (Table 65, in 23.1 "Container requirements", says that X::iterator is convertible to X::const_iterator)
The caller can ensure that the const overload is called by using a const reference, but you shouldn't force them to do that, because they will have to write something like:
UberList<int>::CIter it = static_cast<const UberList<int> &>(ulist).begin()
If you provide the "required" conversion then there's no need for your caller to do anything special: your original code will work, just as it does for standard containers.
Some more comments to the OP's code. Consider separating that gigantic uberl33tlist class and break it up into smaller files. Seeing all those friends class declaration is making me rather uncomfortable. There are also some tricky semantics When you're using stuff like
friend class UberList;
friend class CIter;
In some cases those statements also end up forward declaring those classes if they don't exist yet. There's also something not quite right looking about your assignment operator here:
UberList<T> operator = (const UberList<T>& OL)
{
UberList<T> NL = new (OL);
return NL;
}
Also in your main you have
it2++;
ulist.insertAfter(b, it2);
//...
You're using postfix operator ++ for it2 but didn't implement that your iterator class. Borland accepts it by using the prefix instead but gives a warning. Gcc actually flags that as an error and rejects the code. Might want to look into that
Sigh: there's a level of hackery here designed to hide the fact that conceptually what you want to do cannot be done automatically in C++ because it doesn't understand variance. Some other languages (including Ocaml) do.
If you have a functor (that's a template class to C++ programmers), the question is how it and various functions behave with a variance of the parameter, such as a conversion from T to T const. What you really want is this:
List<T> --> List<T const>
in other words you want the List functor to be covariant. But no, it isn't .. so actually the List template isn't a functor at all, because functors must be structure preserving and the conversion isn't reflected as required. In turn this means either C++ templates are broken OR the concept of const is broken, because a type system that doesn't support parametric polymorhism is broken by specification :)
Providing "const_iterator" does not solve this problem, it simply patches up the break. Where is the volatile and const_volatile version? How about double indirections?
If you don't understand double indirections: consider a tree of vectors of T, that's two templates:
Tree<Vector<T>>
The best solution here is to give up supporting const_iterator. Just don't bother. It's confused anyhow: how about "const vector"? What's that? A vector you can't make longer but it still allows you to write the elements?
The actual requirement is that transforms commute, for example:
vector<T> const == vector<T const>
[or they anti-commute if the transform is contra-variant]
The fact this doesn't happen shows that vector isn't functorial, in other words, templates can't be used effectively for parametric polymorphism. If you want to really get your knickers tied in a knot consider templates with function arguments and ask about the variance of the function's return type and parameters, and how this might impact the container. A good example is how to compose a two functions so they work on a pair. What if they're mutators, how does "const" work then?
You need
teamplate<class T> bool operator!=(UberList<T>::CIter,UberList<T>::CIter);
It's using the regular begin method because the variable is not const. So one way of fixing it is to make another (reference) variable that is const:
UberList<int> const & culist = ulist;
for (UberList<int>::Citer it = culist.begin(); ...)
Alternatively, use a const_cast.
I would like to pass arbitrary container as an argument of function and iterate over it (no erasing nor pushing elements). Unfortunately it looks like there is no standard way of doing this.
First solution which comes to my mind is an interface (let's call it CollectionInterface) implemented by classes that will wrap STL containers. so the function declaration would look like:
f(const CollectionInterface * collection);
Or, I was thinking about method template, which has an advantage that it keeps binding at compilation time:
template <class CONTAINER> void f(const CONTAINER & collection);
Which way do you think is better?
ForwardIterator? This is a type of InputIterator (or OutputIterator) that also allows multi-pass algorithms (incrementing it does not invalidate prior values).
Iterators (which are quite different from Java iterators) are the central thread unifying C++ collections. For examples of algorithms working on them (and associated iterator type requirements), you can start with <algorithm>. In particular, search provides an example of using ForwardIterator. It finds the first occurrence within the range [first1, last1] of the sequence defined by the range [first2, last2). These are all objects meeting the requirements of ForwardIterator.
You can also write methods that accept the entire container instead of a reference if that's the way you want to handle things. Iterators into standard library containers are all provided via the member functions begin() and end(), or in some cases rbegin() and rend() for iterating backwards. The way templates work, you don't have to create an actual interface type that objects derive from; the requirements are instead inferred by the object is used.
template<typename Container> void Function(const Container& c) {
for(typename Container::const_iterator i = c.begin(), end = c.end(); i != end; ++i)
//do something
}
Passing iterators provide more flexibility when using the functions, particularly in that not all iterators come from containers with explicit begin() and end() functions, and you can provide whatever explicit subrange you want. But sometimes this method is appropriate.
I would like to pass arbitrary container as an argument of function and iterate over it (no erasing nor pushing elements).
Pass iterators. Here is an example for implementation and use:
template <typename Iter>
void function(Iter begin, Iter end)
{
for (Iter it = begin; it != end; ++it)
{
std::cout << *it << std::endl;
}
}
int main()
{
std::string array[] = {"hello", "array", "world"};
function(array, array + 3);
std::vector<std::string> vec = {"hello", "vector", "world"};
function(vec.begin(), vec.end());
}
Note that in many cases, you don't actually need to write the function, but you can compose it using the library facilities instead and then simply apply std::for_each on that. Or even better, use a preexisting algorithm like std::accumulate or std::find_if.