So I've been trying to create a function that will receive vector objects as a general type in C++.
I have three classes Coffee, Snack, and Juice. And I have a binary search function to search for a specific item in each of the three vector objects created by those classes. But in order to do the binary search, I'd have to define three binary search functions. For example, binarySearchCoffee(vector coffeeList), binarySearchSnack(vector coffeeList) and the same for the Juice. So, is there a way to create a general vector type parameter that will take in whatever I inserted or is defining three functions ordinary? But I do not think so because it violates the DRY rule.
Thank you for your time.
This is what templates are for. Indeed, that's how the vector itself works!!
template <typename ElementType>
bool DoMyBinarySearch(const std::vector<ElementType>& container, const ElementType& value)
{
auto it = std::lower_bound(std::begin(container), std::end(container), value);
return it != std::end(container) && *it == value;
}
You might even consider making the container type the template argument, so that you're not restricted to vectors (though that may not be useful in this case).
This example also doesn't consider alternative allocators, or alternative comparators, which may or may not matter to you. cppreference.com's std::lower_bound article has a more robust example.
Don't forget to document the precondition that container must be sorted.
Related
Should the custom iterator for a customer container be a nested class or a free(for a lack of better word) class? I have seen it both ways, especially in books and online, so not sure if one approach has advantage over other. The two books I am using both have the iterators defined as free classes where as online first few implementations I checked, all were nested.
I personally prefer nested iterator, if the iterator only serves a particular container.
Thanks,
DDG
p.s. - The question is not about preference but about advantages of one approach over others.
the iterator only serves a particular container.
The main thing to know is how true this will be.
Depends on the amount of types of containers you will define and the implementations you are applying, it's quite possible for some of them using the exact same type of iterator.
For instance, you will likely find myArray::iterator and myVector::iterator have the exact same implementation. Similarly, mySet::iterator and myMap::iterator might be the same as well.
If that's the case, it might be better do something like this to avoid implementing the same iterator multiple times:
// iterators.h
template<typename T>
struct contiguous_iterator
{
// implementation for array and set iterator
};
template<typename T>
struct rb_tree_iterator
{
// implementation for set and map iterator
};
// contiguous_containers.h
template<typename T>
struct myArray
{
using iterator = contiguous_iterator<T>;
//...
};
// rb_tree_containers.h
template<typename Key, typename Value>
struct myMap
{
using iterator = rb_tree_iterator<tuple<Key, Value>>;
//...
};
The fact is that an iterator, it is built and used for a specific class, so there is no need for it to be defined outside. Since you only use it in coordination with your container.
Different thing if your iterator it is used by different classes, but I can't really find an example of where it could be useful.
Edit. Finally, to wrap up, both can be done and I don't think there are any advantages in terms of memory used or execution times. For a better understanding of this we should check difference between a nested class and a not-nested class, but I think is off-topic here.
While there would be no definitive answer,
I prefer to define them outside.
And I disagree with ranghetto's claim
The fact is that an iterator, it is built and used for a specific class
Different thing if your iterator it is used by different classes, but I can't really find an example of where it could be useful.
I implemented std::vector-like containers(notice plural form), including double-ended one, small-buffer optimized one, etc..
And they use same iterator implementation.
In general, defining iterators outside reduces unnecessary dependencies.
Plain and simple: what's the advantage of tag dispatching over normal overload resolution?
These are both compile-time processes right? So there shouldn't be a 'performance winner' I suppose. And every tag dispatching case should be able, to some extent, to be rewritten/refactored into normal overloading (possibly by adding multiple types), right?
Aside from the different way of working and selecting candidates, why should I prefer tag dispatching over overload resolution and in which cases?
Tag dispatching is basically a name given to a technique employed to find correct overloaded function. So, technically it is nothing but overloading only.
To put it from Boost site:
Tag dispatching is a way of using function overloading to dispatch
based on properties of a type, and is often used hand in hand with
traits classes.
You can see it used all over in you standard library algorithm header file. Just for the sake of an example, consider that there is an algorithm AlgoX which can be performed a lot more efficiently on a container providing random access (eg vector) than a container providing bidirectional access (list). So, for selecting the algorithm based on the iterator type one would use tag dispatching using iterator_traits
template <typename Iter>
void AlgoXImpl(Iter first, Iter last, bidirectional_iterator_tag) {
//.....Algo specialized to bidirectional iterators
}
template <typename Iter>
void AlgoXImpl(Iter first, Iter last, random_access_iterator_tag) {
//.....Algo specialized to random access iterators
}
template <typename Iter>
void AlgoX(Iter first, Iter last) {
if (first == last) return;
AlgoXImpl(first, last, typename iterator_traits<Iter>::iterator_category());
}
As you can see, to a simple mind this is nothing but an example of operator overloading as the categories are essentially different types.
For a more real world example, you can checkout out how std::rotate is implemented.
Tags can be associated with a type, even including basic primitive types, through appropriate trait classes. E.g., it would be impossible to make a pointer type a subclass of some iterator concept. However, a templated trait class may associate it with the desired tag. Thus, tag-based dispatching adds flexibility that allows to build a dispatch scheme that must not already be defined by the involved types.
I'm writing a linked list for a C++ class and am stuck trying to figure out how to compare two generic typed nodes for a sorting algorithm. In Java I would just implement the Comparable interface and use the compareTo() method to determine which is "larger" or "smaller", letting the user of the Collection define this. Is there something similar in C++ that I can use? I know I can override the "<" operator but I don't know if this is the "best" method (subjective, I know; really just asking for pros and cons if there is another) to compare unknown types.
So, are there any other options to compare unknown types at runtime that seem to be more appropriate than overriding the "<" operator?
EDIT: Changed the operator I need to override.
From what I gather you have a list class template and you want to implement a sort() method on it. I would follow the example set by std::list<T> for this:
template <typename T>
class List
{
public:
// ...
template <typename Compare>
void sort(Compare compare) {
// use compare(x, y) to determine if x is smaller than y
}
void sort() { this->sort(std::less<T>()); }
};
That is, instead of making a fixed choice you would default to use operator<() but allow the user to use a different ordering predicate. As long as the comparison function implement a strict weak order anything can be used.
Yes, overloading operators (for sorting, you'd use operator< and maybe operator==) is the way. It's idiomatic and you needn't mark the interface (like deriving from a specific interface), and it is not typically done.
The good thing is that even if the user wanted to use some type without relation operators, he/she can extend their interface by providing free function overloads of the operators.
You could use any other method (such as inventing your own interface, eg. function int T::cmp(...) that would return 0/1/-1 depending on the relation of the parameters. However, this has the great disadvantage that you won't be able to reuse others' classes.
The STL uses a user-passed function object object to compare what it needs, which is needed to provide different sorting orders on the same data (say, ordering people by surname vs. by telephone number). If you don't need this (or are prepared to forgo this functionality), you can stick to using operator<.
What are good use-cases for using tuples in C++11? For example, I have a function that defines a local struct as follows:
template<typename T, typename CmpF, typename LessF>
void mwquicksort(T *pT, int nitem, const int M, CmpF cmp, LessF less)
{
struct SI
{
int l, r, w;
SI() {}
SI(int _l, int _r, int _w) : l(_l), r(_r), w(_w) {}
} stack[40];
// etc
I was considering to replace the SI struct with an std::tuple<int,int,int>, which is a far shorter declaration with convenient constructors and operators already predefined, but with the following disadvantages:
Tuple elements are hidden in obscure, implementation-defined structs. Even though Visual studio interprets and shows their contents nicely, I still can't put conditional breakpoints that depend on value of tuple elements.
Accessing individual tuple fields (get<0>(some_tuple)) is far more verbose than accessing struct elements (s.l).
Accessing fields by name is far more informative (and shorter!) than by numeric index.
The last two points are somewhat addressed by the tie function. Given these disadvantages, what would be a good use-case for tuples?
UPDATE Turns out that VS2010 SP1 debugger cannot show the contents of the following array std::tuple<int, int, int> stack[40], but it works fine when it's coded with a struct. So the decision is basically a no-brainer: if you'll ever have to inspect its values, use a struct [esp. important with debuggers like GDB].
It is an easy way to return multiple values from a function;
std::tuple<int,int> fun();
The result values can be used elegantly as follows:
int a;
int b;
std::tie(a,b)=fun();
Well, imho, the most important part is generic code. Writing generic code that works on all kinds of structs is a lot harder than writing generics that work on tuples. For example, the std::tie function you mentioned yourself would be very nearly impossible to make for structs.
this allows you to do things like this:
Store function parameters for delayed execution (e.g. this question )
Return multiple parameters without cumbersome (un)packing with std::tie
Combine (not equal-typed) data sets (e.g. from parallel execution), it can be done as simply as std::tuple_cat.
The thing is, it does not stop with these uses, people can expand on this list and write generic functionality based on tuples that is much harder to do with structs. Who knows, maybe tomorrow someone finds a brilliant use for serialization purposes.
I think most use for tuples comes from std::tie:
bool MyStruct::operator<(MyStruct const &o) const
{
return std::tie(a, b, c) < std::tie(o.a, o.b, o.c);
}
Along with many other examples in the answers here. I find this example to be the most commonly useful, however, as it saves a lot of effort from how it used to be in C++03.
I think there is NO good use for tuples outside of implementation details of some generic library feature.
The (possible) saving in typing do not offset the losses in self-documenting properties of the resulting code.
Substituting tuples for structs that just takes away a meaningful name for a field, replacing the field name with a "number" (just like the ill-conceived concept of an std::pair).
Returning multiple values using tuples is much less self-documenting then the alternatives -- returning named types or using named references. Without this self-documenting, it is easy to confuse the order of the returned values, if they are mutually convertible.
Have you ever used std::pair? Many of the places you'd use std::tuple are similar, but not restricted to exactly two values.
The disadvantages you list for tuples also apply to std::pair, sometimes you want a more expressive type with better names for its members than first and second, but sometimes you don't need that. The same applies to tuples.
The real use cases are situations where you have unnameable elements- variadic templates and lambda functions. In both situations you can have unnamed elements with unknown types and thus the only way to store them is a struct with unnamed elements: std::tuple. In every other situation you have a known # of name-able elements with known types and can thus use an ordinary struct, which is the superior answer 99% of the time.
For example, you should NOT use std::tuple to have "multiple returns" from ordinary functions or templates w/ a fixed number of generic inputs. Use a real structure for that. A real object is FAR more "generic" than the std::tuple cookie-cutter, because you can give a real object literally any interface. It will also give you much more type safety and flexibility in public libraries.
Just compare these 2 class member functions:
std::tuple<double, double, double> GetLocation() const; // x, y, z
GeoCoordinate GetLocation() const;
With a real 'geo coordinate' object I can provide an operator bool() that returns false if the parent object had no location. Via its APIs users could get the x,y,z locations. But here's the big thing- if I decide to make GeoCoordinate 4D by adding a time field in 6 months, current users's code won't break. I cannot do that with the std::tuple version.
Interoperation with other programming languages that use tuples, and returning multiple values without having the caller have to understand any extra types. Those are the first two that come to my mind.
I cannot comment on mirk's answer, so I'll have to give a separate answer:
I think tuples were added to the standard also to allow for functional style programming. As an example, while code like
void my_func(const MyClass& input, MyClass& output1, MyClass& output2, MyClass& output3)
{
// whatever
}
is ubiquitous in traditional C++, because it is the only way to have multiple objects returned by a function, this is an abomination for functional programming. Now you may write
tuple<MyClass, MyClass, MyClass> my_func(const MyClass& input)
{
// whatever
return tuple<MyClass, MyClass, MyClass>(output1, output2, output3);
}
Thus having the chance to avoid side effects and mutability, to allow for pipelining, and, at the same time, to preserve the semantic strength of your function.
F.21: To return multiple "out" values, prefer returning a struct or tuple.
Prefer using a named struct where there are semantics to the returned value. Otherwise, a nameless tuple is useful in generic code.
For instance, if returned values are value from the input stream and the error code, these values will not ego far together. They are not related enough to justify a dedicated structure to hold both. Differently, x and y pair would rather have a structure like Point.
The source I reference is maintained by Bjarne Stroustrup, Herb Sutter so I think somewhat trustworthy.
I'm doing a computation in C++ and it has to be as fast as possible (it is executed 60 times per second with possibly large data). During the computation, a certain set of items have to be processed. However, in different cases, different implementations of the item storage are optimal, so i need to use an abstract class for that.
My question is, what is the most common and most efficient way to do an action with each of the items in C++? (I don't need to change the structure of the container during that.) I have thought of two possible solutions:
Make iterators for the storage classes. (They're also mine, so i can add it.) This is common in Java, but doesn't seem very 'C' to me:
class Iterator {
public:
bool more() const;
Item * next();
}
Add sort of an abstract handler, which would be overriden in the computation part and would include the code to be called on each item:
class Handler {
public:
virtual void process(Item &item) = 0;
}
(Only a function pointer wouldn't be enough because it has to also bring some other data.)
Something completely different?
The second option seems a bit better to me since the items could in fact be processed in a single loop without interruption, but it makes the code quite messy as i would have to make quite a lot of derived classes. What would you suggest?
Thanks.
Edit: To be more exact, the storage data type isn't exactly just an ADT, it has means of only finding only a specific subset of the elements in it based on some parameters, which i need to then process, so i can't prepare all of them in an array or something.
#include <algorithm>
Have a look at the existing containers provided by the C++ standard, and functions such as for_each.
For a comparison of C++ container iteration to interfaces in "modern" languages, see this answer of mine. The other answers have good examples of what the idiomatic C++ way looks like in practice.
Using templated functors, as the standard containers and algorithms do, will definitely give you a speed advantage over virtual dispatch (although sometimes the compiler can devirtualize calls, don't count on it).
C++ has iterators already. It's not a particularly "Java" thing. (Note that their interface is different, though, and they're much more efficient than their Java equivalents)
As for the second approach, calling a virtual function for every element is going to hurt performance if you're worried about throughput.
If you can (pre-)sort your data so that all objects of the same type are stored consecutively, then you can select the function to call once, and then apply it to all elements of that type. Otherwise, you'll have to go through the indirection/type check of a virtual function or another mechanism to perform the appropriate action for every individual element.
What gave you the impression that iterators are not very C++-like? The standard library is full of them (see this), and includes a wide range of algorithms that can be used to effectively perform tasks on a wide range of standard container types.
If you use the STL containers you can save re-inventing the wheel and get easy access to a wide variety of pre-defined algorithms. This is almost always better than writing your own equivalent container with an ad-hoc iteration solution.
A function template perhaps:
template <typename C>
void process(C & c)
{
typedef typename C::value_type type;
for (type & x : c) { do_something_with(x); }
}
The iteration will use the containers iterators, which is generally as efficient as you can get.
You can specialize the template for specific containers.