I have the following situation: I must pack several pointers and an identifier into a tuple like this:
typedef tuple<unsigned*, unsigned*, unsigned*, unsigned> tuple_with_pointers_t;
Here, I have three pointers and one id. In other situations, I may have more or fewer pointers, but the last will be the id. Note that I used unsigned* as an example only. It could be more complex objects.
Now, I want to compare the values of two such tuples. I.e., I need to dereference all tuple elements but the last. We can archive this using the following (in C++17):
template <size_t I = 0, typename T, typename... Ts>
constexpr bool lesser(std::tuple<T, Ts...> a, std::tuple<T, Ts...> b)
{
if constexpr (I < sizeof...(Ts))
return (*std::get<I>(a) < *std::get<I>(b)) ||
((*std::get<I>(a) == *std::get<I>(b)) && lesser<I + 1>(a, b));
else
return std::get<I>(a) < std::get<I>(b);
}
Such construct works very fine when we compare two tuples directly. Now, I would like to use lesser() as a functor on the std::sort(). But, both g++ and clang++ complain that they cannot "couldn't infer template argument '_Compare'". In other words, we need to pass the correct template arguments to lesser.
I have tried some things here, but with no success: we have three template parameters, and I am not sure how I can use the _Elements from the tuple here. What will be the best strategy?
Here is some toy code:
#include <algorithm>
#include <iostream>
#include <tuple>
#include <vector>
using namespace std;
// My weird tuple with pointers and one unsigned index.
typedef tuple<unsigned*, unsigned*, unsigned*, unsigned> tuple_with_pointers_t;
// This works fine for two tuples directly. Note that we cannot dereference
// the last tuple element, so we compare it directly.
template <size_t I = 0, typename T, typename... Ts>
constexpr bool lesser(std::tuple<T, Ts...> a, std::tuple<T, Ts...> b)
{
if constexpr (I < sizeof...(Ts))
return (*std::get<I>(a) < *std::get<I>(b)) ||
((*std::get<I>(a) == *std::get<I>(b)) && lesser<I + 1>(a, b));
else
return std::get<I>(a) < std::get<I>(b);
}
int main() {
// Three sets of values.
vector<unsigned> values1 {1, 2, 3};
vector<unsigned> values2 {10, 20, 30};
vector<unsigned> values3 {11, 22, 33};
// Here, we pack it all together with the index.
vector<tuple_with_pointers_t> all;
for(unsigned i = 0; i < values1.size(); ++i)
all.emplace_back(&values1[i], &values2[i], &values3[i], i);
// So, it works if we want to compare two elements of our vector.
cout << "\n- t0 < t1: " << std::boolalpha << lesser(all[0], all[1]);
cout << "\n- t2 < t1: " << std::boolalpha << lesser(all[2], all[1]);
// Now, I want to sort the tuples by their values. The compiler doesn't
// like it: it cannot deduce the template parameters.
sort(all.begin(), all.end(), lesser);
return 0;
}
I appreciate any help, either using C++17 or C++20. But I'm looking for the most compact and elegant way to do it. It could be using a lambda function directly on the sort() call, too, if possible.
Thanks!
Update:
OK, I found a little hack that works:
sort(all.begin(), all.end(),
[](const auto &a, const auto &b) {
return lesser(a, b);
}
);
Basically, we wrap it into a lambda, and therefore the compiler can deduce the types. But, can we do better?
Thanks
As suggested in the comments, you can add your comparator into a function object and pass an instance of the object to sort:
#include <algorithm>
#include <iostream>
#include <tuple>
#include <vector>
using namespace std;
// My weird tuple with pointers and one unsigned index.
typedef tuple<unsigned*, unsigned*, unsigned*, unsigned> tuple_with_pointers_t;
namespace details {
template <size_t I = 0, typename T, typename... Ts>
constexpr bool lesser(std::tuple<T, Ts...> const& a, std::tuple<T, Ts...> const& b)
{
if constexpr (I < sizeof...(Ts))
return (*std::get<I>(a) < *std::get<I>(b)) ||
((*std::get<I>(a) == *std::get<I>(b)) && lesser<I + 1>(a, b));
else
return std::get<I>(a) < std::get<I>(b);
}
}
struct Less
{
template <typename... Ts>
constexpr bool operator()(std::tuple<Ts...> const& a, std::tuple<Ts...> const& b)
{
return details::lesser<0, Ts...>(a, b);
}
};
int main() {
// Three sets of values.
vector<unsigned> values1 {1, 2, 3};
vector<unsigned> values2 {10, 20, 30};
vector<unsigned> values3 {11, 22, 33};
// Here, we pack it all together with the index.
vector<tuple_with_pointers_t> all;
for(unsigned i = 0; i < values1.size(); ++i)
all.emplace_back(&values1[i], &values2[i], &values3[i], i);
// So, it works if we want to compare two elements of our vector.
cout << "\n- t0 < t1: " << std::boolalpha << Less()(all[0], all[1]);
cout << "\n- t2 < t1: " << std::boolalpha << Less()(all[2], all[1]);
// Now, I want to sort the tuples by their values. The compiler doesn't
// like it: it cannot deduce the template parameters.
sort(all.begin(), all.end(), Less());
return 0;
}
As an alternative, you could wrap your unsigned* in a custom pointer type and provide a comparator for it. Then you can use the default comperator for tuples, which compares the elements lexicographically.
I personally would prefer this approach, because the code is much more readable. I don't know if this would break your existing code or would entail a huge refactor.
#include <algorithm>
#include <iostream>
#include <tuple>
#include <vector>
using namespace std;
class Ptr
{
public:
Ptr(unsigned& v) : m_ptr(&v) {}
unsigned operator*() const {
return *m_ptr;
}
private:
unsigned* m_ptr;
};
bool operator<(Ptr const& l, Ptr const& r)
{
return *l < *r;
}
// My weird tuple with pointers and one unsigned index.
typedef tuple<Ptr, Ptr, Ptr, unsigned> tuple_with_pointers_t;
int main() {
// Three sets of values.
vector<unsigned> values1 {1, 2, 3};
vector<unsigned> values2 {10, 20, 30};
vector<unsigned> values3 {11, 22, 33};
// Here, we pack it all together with the index.
vector<tuple_with_pointers_t> all;
for(unsigned i = 0; i < values1.size(); ++i)
all.emplace_back(values1[i], values2[i], values3[i], i);
// So, it works if we want to compare two elements of our vector.
cout << "\n- t0 < t1: " << std::boolalpha << (all[0] < all[1]);
cout << "\n- t2 < t1: " << std::boolalpha << (all[2] < all[1]);
sort(all.begin(), all.end());
return 0;
}
I think we can use this. Of course, I don't know your tuple can be more complex.
template<typename T, size_t I = 0>
using type_tuple = typename std::tuple_element<I,T>::type;
template<size_t I = 0, template<typename> class F = std::less_equal>
struct TupleCompare
{
template<typename T>
bool operator()(T const &t1, T const &t2){
using _type = typename std::conditional<std::is_pointer<type_tuple<T>>::value,
typename std::remove_pointer<type_tuple<T,I>>::type, type_tuple<T>>::type;
if constexpr (I == std::tuple_size_v<T> - 1) {
return F<_type>()(std::get<I>(t1), std::get<I>(t2));
} else {
return F<_type>()(*std::get<I>(t1), *std::get<I>(t2)) && TupleCompare<I+1, F>()(t1, t2);
}
}
};
By doing a non-"recursive" function, you might do a "one-liner":
sort(all.begin(), all.end(),
[]<typename T>(const T& lhs, const T& rhs) {
return [&]<std::size_t... Is>(std::index_sequence<Is...>){
return std::tie(std::get<Is>(lhs)...)
< std::tie(std::get<Is>(rhs)...);
}(std::make_index_sequence<std::tuple_size_v<T> - 1>{});
});
template lambda are C++20.
Without that, at least an helper function is required, so it becomes, as the other solutions, wrapping a function in a functor.
I am trying to write a template function that will sum up all elements of some collection - specified either as a plain stl container, or as a ranges-v3's range. (The actual function, as shown below is a bit more generic) I thought this would work:
template <typename Range, typename Ret, typename Func>
std::pair<Ret, int> sum(const Range& range, Ret zero, Func extract) {
using It = decltype(range.begin());
Ret sum = zero;
int numElements = 0;
for (It it = range.begin(); it != range.end(); ++it) {
sum += extract(*it);
++numElements;
}
return { sum, numElements };
}
This indeed works for STL elements, but not for ranges. This gives me a very long error:
<this file, at line 'using It'> error C2662: 'ranges::v3::basic_iterator<ranges::v3::adaptor_cursor<ranges::v3::basic_iterator<ranges::v3::adaptor_cursor<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<_Ty>>>,ranges::v3::iter_transform_view<Rng,ranges::v3::indirected<Fun>>::adaptor<false>>>,ranges::v3::remove_if_view<ranges::v3::transform_view<Rng,Fun>,ranges::v3::logical_negate_<EnemyGroup::stepUpdate::<lambda_c582fb1297dce111c4572cef649d86b9>>>::adaptor>> ranges::v3::view_facade<Derived,ranges::v3::finite>::begin<Derived,false,0x0>(void)': cannot convert 'this' pointer from 'const Range' to 'ranges::v3::view_facade<Derived,ranges::v3::finite> &'
note: Conversion loses qualifiers
originally, I thought it was some deficiency of the vs2015 branch of ranges-v3. Without thinking much, I just hacked a quick walkaround:
template <typename Range, typename Ret, typename Func>
std::pair<Ret, int> sum(const Range& range, Ret zero, Func extract) {
using It = decltype(const_cast<Range*>(&range)->begin());
Ret sum = zero;
int numElements = 0;
for (It it = const_cast<Range*>(&range)->begin(); it != const_cast<Range*>(&range)->end(); ++it) {
//sum += extract(std::as_const(*it)); (does not work either, converts to void)
sum += extract(*it);
++numElements;
}
return { sum, numElements };
}
but with the newest MSVC version that just came out from preview, the master branch of ranges is now officially supported. Yet, the above error prevails.
Is using range's objects as const& a wrong thing to do? I know these objects are lightweight and are easy to copy around, but using a const reference shouldn't hurt, or? On the other hand, if a concrete STL container is passed, I need it to be passed as const&
If using const& is incorrect, is there some easy way to have a function work with both containers and ranges, without writing anything at the call site (e.g. invoking view::all)
I am using Visual Studio Community 2017, Version 15.9.3. Note, that before 15.9, range-v3 in its master branch was not supported.
Since you are asking how exactly I call it. My actual code is complicated, but I reduced it down to this small example:
#include <set>
#include <range/v3/view/filter.hpp>
template <typename Range, typename Ret, typename Func>
std::pair<Ret, int> sum(const Range& range, Ret zero, Func extract) {
using It = decltype(range.begin());
Ret sum = zero;
int numElements = 0;
for (It it = range.begin(); it != range.end(); ++it) {
sum += extract(*it);
++numElements;
}
return { sum, numElements };
}
int main() {
std::set<int*> units;
auto [vsum, num] = sum(
units | ranges::v3::view::filter([](const int* eu) { return *eu>0; }),
0,
[](const int* eu) { return *eu/2; }
);
}
This gives me the same conversion errors as above.
Not all ranges are const-iterable. That is, there are range types T for which const T is not a range. filter is the classic example: it needs to cache the value of the iterator returned from begin so that future calls are O(1) (See http://eel.is/c++draft/range.filter.view#6). Consequently, begin cannot be a const member function without violating the Standard Library policy that const members are callable from multiple threads without introducing data races.
As a consequence, const Range& isn't idiomatic for accepting general Range arguments as it was for accepting "container that I don't intend to modify." We recommend that functions that take Range arguments accept them by forwarding reference. If you alter your program to:
#include <set>
#include <range/v3/view/filter.hpp>
template <typename Range, typename Ret, typename Func>
std::pair<Ret, int> sum(Range&& range, Ret zero, Func extract) { // Note "Range&&"
Ret sum = zero;
int numElements = 0;
for (auto&& e : range) {
sum += extract(e);
++numElements;
}
return { sum, numElements };
}
int main() {
std::set<int*> units;
auto [vsum, num] = sum(
units | ranges::v3::view::filter([](const int* eu) { return *eu>0; }),
0,
[](const int* eu) { return *eu/2; }
);
}
It will compile and run correctly.
For an array with multiple dimensions, we usually need to write a for loop for each of its dimensions. For example:
vector< vector< vector<int> > > A;
for (int k=0; k<A.size(); k++)
{
for (int i=0; i<A[k].size(); i++)
{
for (int j=0; j<A[k][i].size(); j++)
{
do_something_on_A(A[k][i][j]);
}
}
}
double B[10][8][5];
for (int k=0; k<10; k++)
{
for (int i=0; i<8; i++)
{
for (int j=0; j<5; j++)
{
do_something_on_B(B[k][i][j]);
}
}
}
You see this kind of for-for-for loops in our code frequently. How do I use macros to define the for-for-for loops so that I don't need to re-write this kind of code every time? Is there a better way to do this?
The first thing is that you don't use such a data structure. If
you need a three dimensional matrix, you define one:
class Matrix3D
{
int x;
int y;
int z;
std::vector<int> myData;
public:
// ...
int& operator()( int i, int j, int k )
{
return myData[ ((i * y) + j) * z + k ];
}
};
Or if you want to index using [][][], you need an operator[]
which returns a proxy.
Once you've done this, if you find that you constantly have to
iterate as you've presented, you expose an iterator which will
support it:
class Matrix3D
{
// as above...
typedef std::vector<int>::iterator iterator;
iterator begin() { return myData.begin(); }
iterator end() { return myData.end(); }
};
Then you just write:
for ( Matrix3D::iterator iter = m.begin(); iter != m.end(); ++ iter ) {
// ...
}
(or just:
for ( auto& elem: m ) {
}
if you have C++11.)
And if you need the three indexes during such iterations, it's
possible to create an iterator which exposes them:
class Matrix3D
{
// ...
class iterator : private std::vector<int>::iterator
{
Matrix3D const* owner;
public:
iterator( Matrix3D const* owner,
std::vector<int>::iterator iter )
: std::vector<int>::iterator( iter )
, owner( owner )
{
}
using std::vector<int>::iterator::operator++;
// and so on for all of the iterator operations...
int i() const
{
((*this) - owner->myData.begin()) / (owner->y * owner->z);
}
// ...
};
};
Using a macro to hide the for loops can be a lot confusing, just to save few characters. I'd use range-for loops instead:
for (auto& k : A)
for (auto& i : k)
for (auto& j : i)
do_something_on_A(j);
Of course you can replace auto& with const auto& if you are, in fact, not modifying the data.
Something like this can help:
template <typename Container, typename Function>
void for_each3d(const Container &container, Function function)
{
for (const auto &i: container)
for (const auto &j: i)
for (const auto &k: j)
function(k);
}
int main()
{
vector< vector< vector<int> > > A;
for_each3d(A, [](int i){ std::cout << i << std::endl; });
double B[10][8][5] = { /* ... */ };
for_each3d(B, [](double i){ std::cout << i << std::endl; });
}
In order to make it N-ary we need some template magic. First of all we should create SFINAE structure to distinguish whether this value or container. The default implementation for values, and specialisations for arrays and each of the container types. How #Zeta notes, we can determine the standard containers by the nested iterator type (ideally we should check whether the type can be used with range-base for or not).
template <typename T>
struct has_iterator
{
template <typename C>
constexpr static std::true_type test(typename C::iterator *);
template <typename>
constexpr static std::false_type test(...);
constexpr static bool value = std::is_same<
std::true_type, decltype(test<typename std::remove_reference<T>::type>(0))
>::value;
};
template <typename T>
struct is_container : has_iterator<T> {};
template <typename T>
struct is_container<T[]> : std::true_type {};
template <typename T, std::size_t N>
struct is_container<T[N]> : std::true_type {};
template <class... Args>
struct is_container<std::vector<Args...>> : std::true_type {};
Implementation of for_each is straightforward. The default function will call function:
template <typename Value, typename Function>
typename std::enable_if<!is_container<Value>::value, void>::type
rfor_each(const Value &value, Function function)
{
function(value);
}
And the specialisation will call itself recursively:
template <typename Container, typename Function>
typename std::enable_if<is_container<Container>::value, void>::type
rfor_each(const Container &container, Function function)
{
for (const auto &i: container)
rfor_each(i, function);
}
And voila:
int main()
{
using namespace std;
vector< vector< vector<int> > > A;
A.resize(3, vector<vector<int> >(3, vector<int>(3, 5)));
rfor_each(A, [](int i){ std::cout << i << ", "; });
// 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
std::cout << std::endl;
double B[3][3] = { { 1. } };
rfor_each(B, [](double i){ std::cout << i << ", "; });
// 1, 0, 0, 0, 0, 0, 0, 0, 0,
}
Also this will not work for pointers (arrays allocated in heap).
Most of the answers simply demonstrate how C++ can be twisted into incomprehensible syntactic extensions, IMHO.
By defining whatever templates or macros, you just force other programmers to understand bits of obfuscated code designed to hide other bits of obfuscated code.
You will force every guy who reads your code to have template expertise, just to avoid doing your job of defining objects with clear semantics.
If you decided to use raw data like 3 dimensional arrays, just live with it, or else define a class that gives some understandable meaning to your data.
for (auto& k : A)
for (auto& i : k)
for (auto& current_A : i)
do_something_on_A(current_A);
is just consistent with the cryptic definition of a vector of vector of vector of int with no explicit semantics.
#include "stdio.h"
#define FOR(i, from, to) for(int i = from; i < to; ++i)
#define TRIPLE_FOR(i, j, k, i_from, i_to, j_from, j_to, k_from, k_to) FOR(i, i_from, i_to) FOR(j, j_from, j_to) FOR(k, k_from, k_to)
int main()
{
TRIPLE_FOR(i, j, k, 0, 3, 0, 4, 0, 2)
{
printf("i: %d, j: %d, k: %d\n", i, j, k);
}
return 0;
}
UPDATE: I know, that you asked for it, but you'd better not use that :)
One idea is to write an iterable pseudo-container class that "contains" the set of all multi-index tuples you'll index over. No implementation here because it'll take too long but the idea is that you should be able to write...
multi_index mi (10, 8, 5);
// The pseudo-container whose iterators give {0,0,0}, {0,0,1}, ...
for (auto i : mi)
{
// In here, use i[0], i[1] and i[2] to access the three index values.
}
I see many answers here that work recursively, detecting if the input is a container or not. Instead, why not detect if the current layer is the same type as the function takes? It's far simpler, and allows for more powerful functions:
//This is roughly what we want for values
template<class input_type, class func_type>
void rfor_each(input_type&& input, func_type&& func)
{ func(input);}
//This is roughly what we want for containers
template<class input_type, class func_type>
void rfor_each(input_type&& input, func_type&& func)
{ for(auto&& i : input) rfor_each(i, func);}
However, this (obviously) gives us ambiguity errors. So we use SFINAE to detect if the current input fits in the function or not
//Compiler knows to only use this if it can pass input to func
template<class input_type, class func_type>
auto rfor_each(input_type&& input, func_type&& func) ->decltype(func(input))
{ return func(input);}
//Otherwise, it always uses this one
template<class input_type, class func_type>
void rfor_each(input_type&& input, func_type&& func)
{ for(auto&& i : input) rfor_each(i, func);}
This now handles the containers correctly, but the compiler still considers this ambiguous for input_types that can be passed to the function. So we use a standard C++03 trick to make it prefer the first function over the second, of also passing a zero, and making the one we prefer accept and int, and the other takes ...
template<class input_type, class func_type>
auto rfor_each(input_type&& input, func_type&& func, int) ->decltype(func(input))
{ return func(input);}
//passing the zero causes it to look for a function that takes an int
//and only uses ... if it absolutely has to
template<class input_type, class func_type>
void rfor_each(input_type&& input, func_type&& func, ...)
{ for(auto&& i : input) rfor_each(i, func, 0);}
That's it. Six, relatively simple lines of code, and you can iterate over values, rows, or any other sub-unit, unlike all of the other answers.
#include <iostream>
int main()
{
std::cout << std::endl;
double B[3][3] = { { 1.2 } };
rfor_each(B[1], [](double&v){v = 5;}); //iterate over doubles
auto write = [](double (&i)[3]) //iterate over rows
{
std::cout << "{";
for(double d : i)
std::cout << d << ", ";
std::cout << "}\n";
};
rfor_each(B, write );
};
Proof of compilation and execution here and here
If you wanted a more convenient syntax in C++11, you could add a macro. (Following is untested)
template<class container>
struct container_unroller {
container& c;
container_unroller(container& c_) :c(c_) {}
template<class lambda>
void operator <=(lambda&& l) {rfor_each(c, l);}
};
#define FOR_NESTED(type, index, container) container_unroller(container) <= [](type& index)
//note that this can't handle functions, function pointers, raw arrays, or other complex bits
int main() {
double B[3][3] = { { 1.2 } };
FOR_NESTED(double, v, B) {
std::cout << v << ", ";
}
}
I caveat this answer with the following statement: this would only work if you were operating on an actual array - it wouldn't work for your example using std::vector.
If you are performing the same operation on every element of a multi-dimensional array, without caring about the position of each item, then you can take advantage of the fact that arrays are placed in contiguous memory locations, and treat the whole thing as one big one-dimensional array. For example, if we wanted to multiply every element by 2.0 in your second example:
double B[3][3][3];
// ... set the values somehow
double* begin = &B[0][0][0]; // get a pointer to the first element
double* const end = &B[3][0][0]; // get a (const) pointer past the last element
for (; end > begin; ++begin) {
(*begin) *= 2.0;
}
Note that using the above approach also allows the use of some "proper" C++ techniques:
double do_something(double d) {
return d * 2.0;
}
...
double B[3][3][3];
// ... set the values somehow
double* begin = &B[0][0][0]; // get a pointer to the first element
double* end = &B[3][0][0]; // get a pointer past the last element
std::transform(begin, end, begin, do_something);
I don't generally advise this approach (preferring something like Jefffrey's answer), as it relies on having defined sizes for your arrays, but in some cases it can be useful.
I was kind of shocked that no one proposed some arithmetic-magic based loop to do the work. Since C. Wang is looking for a solution with no nested loops, I'll propose one:
double B[10][8][5];
int index = 0;
while (index < (10 * 8 * 5))
{
const int x = index % 10,
y = (index / 10) % 10,
z = index / 100;
do_something_on_B(B[x][y][z]);
++index;
}
Well, this approach isn't elegant and flexible, so we could pack all the process into a template function:
template <typename F, typename T, int X, int Y, int Z>
void iterate_all(T (&xyz)[X][Y][Z], F func)
{
const int limit = X * Y * Z;
int index = 0;
while (index < limit)
{
const int x = index % X,
y = (index / X) % Y,
z = index / (X * Y);
func(xyz[x][y][z]);
++index;
}
}
This template function can be expressed in the form of nested loops as well:
template <typename F, typename T, int X, int Y, int Z>
void iterate_all(T (&xyz)[X][Y][Z], F func)
{
for (auto &yz : xyz)
{
for (auto &z : yz)
{
for (auto &v : z)
{
func(v);
}
}
}
}
And can be used providing a 3D array of arbitrary size plus the function name, letting the parameter deduction do the hard work of counting the size of each dimension:
int main()
{
int A[10][8][5] = {{{0, 1}, {2, 3}}, {{4, 5}, {6, 7}}};
int B[7][99][8] = {{{0, 1}, {2, 3}}, {{4, 5}, {6, 7}}};
iterate_all(A, do_something_on_A);
iterate_all(B, do_something_on_B);
return 0;
}
Towards more generic
But once again, it lacks of flexibility 'cause it only works for 3D arrays, but using SFINAE we can do the work for arrays of an arbitrary dimension, first we need a template function which iterates arrays of rank 1:
template<typename F, typename A>
typename std::enable_if< std::rank<A>::value == 1 >::type
iterate_all(A &xyz, F func)
{
for (auto &v : xyz)
{
func(v);
}
}
And another one which iterates arrays of any rank, doing the recursion:
template<typename F, typename A>
typename std::enable_if< std::rank<A>::value != 1 >::type
iterate_all(A &xyz, F func)
{
for (auto &v : xyz)
{
iterate_all(v, func);
}
}
This allows us to iterate all the elements in all the dimensions of a arbitrary-dimensions arbitrary-sized array.
Working with std::vector
For the multiple nested vector, the solution ressembles the one of arbitrary-dimensions arbitrary-sized array, but without SFINAE: First we will need a template function that iterates std::vectors and calls the desired function:
template <typename F, typename T, template<typename, typename> class V>
void iterate_all(V<T, std::allocator<T>> &xyz, F func)
{
for (auto &v : xyz)
{
func(v);
}
}
And another template function that iterates any kind of vector of vectors and calls himself:
template <typename F, typename T, template<typename, typename> class V>
void iterate_all(V<V<T, std::allocator<T>>, std::allocator<V<T, std::allocator<T>>>> &xyz, F func)
{
for (auto &v : xyz)
{
iterate_all(v, func);
}
}
Regardless of the nesting level, iterate_all will call the vector-of-vectors version unless the vector-of-values version is a better match thus ending the recursivity.
int main()
{
using V0 = std::vector< std::vector< std::vector<int> > >;
using V1 = std::vector< std::vector< std::vector< std::vector< std::vector<int> > > > >;
V0 A0 = {{{0, 1}, {2, 3}}, {{4, 5}, {6, 7}}};
V1 A1 = {{{{{9, 8}, {7, 6}}, {{5, 4}, {3, 2}}}}};
iterate_all(A0, do_something_on_A);
iterate_all(A1, do_something_on_A);
return 0;
}
I think that the function body is pretty simple and straight-forward... I wonder if the compiler could unroll this loops (I'm almost sure that most compilers could unroll the first example).
See live demo here.
Hope it helps.
Use something along these lines (its pseudo-code, but the idea stays the same). You extract the pattern to loop once, and apply a different function each time.
doOn( structure A, operator o)
{
for (int k=0; k<A.size(); k++)
{
for (int i=0; i<A[k].size(); i++)
{
for (int j=0; j<A[k][i].size(); j++)
{
o.actOn(A[k][i][j]);
}
}
}
}
doOn(a, function12)
doOn(a, function13)
Stick with the nested for loops!
All the methods suggested here have disadvantages in terms of either readability or flexibility.
What happens if you need to use the results of an inner loop for the processing in the outer loop? What happens if you need a value from the outer loop within your inner loop? Most of the "encapsulation" methods fail here.
Trust me I have seen several attempts to "clean up" nested for loops and in the end it turns out that the nested loop is actually the cleanest and most flexible solution.
One technique I've used is templates. E.g.:
template<typename T> void do_something_on_A(std::vector<T> &vec) {
for (auto& i : vec) { // can use a simple for loop in C++03
do_something_on_A(i);
}
}
void do_something_on_A(int &val) {
// this is where your `do_something_on_A` method goes
}
Then you simply call do_something_on_A(A) in your main code. The template function gets created once for each dimension, the first time with T = std::vector<std::vector<int>>, the second time with with T = std::vector<int>.
You could make this more generic using std::function (or function-like objects in C++03) as a second argument if you want:
template<typename T> void do_something_on_vec(std::vector<T> &vec, std::function &func) {
for (auto& i : vec) { // can use a simple for loop in C++03
do_something_on_vec(i, func);
}
}
template<typename T> void do_something_on_vec(T &val, std::function &func) {
func(val);
}
Then call it like:
do_something_on_vec(A, std::function(do_something_on_A));
This works even though the functions have the same signature because the first function is a better match for anything with std::vector in the type.
You could generate indices in one loop like this (A, B, C are dimensions):
int A = 4, B = 3, C = 3;
for(int i=0; i<A*B*C; ++i)
{
int a = i/(B*C);
int b = (i-((B*C)*(i/(B*C))))/C;
int c = i%C;
}
One thing you may want to try if you only have statements in the inner-most loop - and your concern is more about the overly verbose nature of the code - is to use a different whitespace scheme. This will only work if you can state your for loops compactly enough so that they all fit on one line.
For your first example, I would rewrite it as:
vector< vector< vector<int> > > A;
int i,j,k;
for(k=0;k<A.size();k++) for(i=0;i<A[k].size();i++) for(j=0;j<A[k][i].size();j++) {
do_something_on_A(A[k][i][j]);
}
This is kinda pushing it because you are calling functions in the outer loops which is equivalent to putting statements in them. I have removed all unnecessary white-space and it may be passible.
The second example is much better:
double B[10][8][5];
int i,j,k;
for(k=0;k<10;k++) for(i=0;i<8;i++) for(j=0;j<5;j++) {
do_something_on_B(B[k][i][j]);
}
This may be different whitespace convention than you like to use, but it achieves a compact result that nonetheless does not require any knowledge beyond C/C++ (such as macro conventions) and does not require any trickery like macros.
If you really want a macro, you could then take this a step further with something like:
#define FOR3(a,b,c,d,e,f,g,h,i) for(a;b;c) for(d;e;f) for(g;h;i)
which would change the second example to:
double B[10][8][5];
int i,j,k;
FOR3(k=0,k<10,k++,i=0,i<8,i++,j=0,j<5,j++) {
do_something_on_B(B[k][i][j]);
}
and the first example fares better too:
vector< vector< vector<int> > > A;
int i,j,k;
FOR3(k=0,k<A.size(),k++,i=0,i<A[k].size(),i++,j=0,j<A[k][i].size(),j++) {
do_something_on_A(A[k][i][j]);
}
Hopefully you can tell fairly easily which statements go with which for statements. Also, beware the commas, now you can't use them in a single clause of any of the fors.
Here is a C++11 implementation that handles everything iterable. Other solutions restrict themselves to containers with ::iterator typedefs or arrays: but a for_each is about iteration, not being a container.
I also isolate the SFINAE to a single spot in the is_iterable trait. The dispatching (between elements and iterables) is done via tag dispatching, which I find is a clearer solution.
The containers and the functions applied to elements are all perfect forwarded, allowing both const and non-const access to the ranges and functors.
#include <utility>
#include <iterator>
The template function I am implementing. Everything else could go into a details namespace:
template<typename C, typename F>
void for_each_flat( C&& c, F&& f );
Tag dispatching is much cleaner than SFINAE. These two are used for iterable objects and non iterable objects respectively. The last iteration of the first could use perfect forwarding, but I am lazy:
template<typename C, typename F>
void for_each_flat_helper( C&& c, F&& f, std::true_type /*is_iterable*/ ) {
for( auto&& x : std::forward<C>(c) )
for_each_flat(std::forward<decltype(x)>(x), f);
}
template<typename D, typename F>
void for_each_flat_helper( D&& data, F&& f, std::false_type /*is_iterable*/ ) {
std::forward<F>(f)(std::forward<D>(data));
}
This is some boilerplate required in order to write is_iterable. I do argument dependent lookup on begin and end in a detail namespace. This emulates what a for( auto x : y ) loop does reasonably well:
namespace adl_aux {
using std::begin; using std::end;
template<typename C> decltype( begin( std::declval<C>() ) ) adl_begin(C&&);
template<typename C> decltype( end( std::declval<C>() ) ) adl_end(C&&);
}
using adl_aux::adl_begin;
using adl_aux::adl_end;
The TypeSink is useful to test if code is valid. You do TypeSink< decltype( code ) > and if the code is valid, the expression is void. If the code is not valid, SFINAE kicks in and the specialization is blocked:
template<typename> struct type_sink {typedef void type;};
template<typename T> using TypeSink = typename type_sink<T>::type;
template<typename T, typename=void>
struct is_iterable:std::false_type{};
template<typename T>
struct is_iterable<T, TypeSink< decltype( adl_begin( std::declval<T>() ) ) >>:std::true_type{};
I only test for begin. An adl_end test could also be done.
The final implementation of for_each_flat ends up being extremely simple:
template<typename C, typename F>
void for_each_flat( C&& c, F&& f ) {
for_each_flat_helper( std::forward<C>(c), std::forward<F>(f), is_iterable<C>() );
}
Live example
This is way down at the bottom: feel free to poach for the top answers, which are solid. I just wanted a few better techniques to be used!
Firstly, you shouldn't use a vector of vectors of vectors. Each vector is guaranteed to have contiguous memory, but the "global" memory of a vector of vectors isn't (and probably won't be). You should use the standard library type array instead of C-style arrays as well.
using std::array;
array<array<array<double, 5>, 8>, 10> B;
for (int k=0; k<10; k++)
for (int i=0; i<8; i++)
for (int j=0; j<5; j++)
do_something_on_B(B[k][i][j]);
// or, if you really don't like that, at least do this:
for (int k=0; k<10; k++) {
for (int i=0; i<8; i++) {
for (int j=0; j<5; j++) {
do_something_on_B(B[k][i][j]);
}
}
}
Better yet though, you could define a simple 3D matrix class:
#include <stdexcept>
#include <array>
using std::size_t;
template <size_t M, size_t N, size_t P>
class matrix3d {
static_assert(M > 0 && N > 0 && P > 0,
"Dimensions must be greater than 0.");
std::array<std::array<std::array<double, P>, N>, M> contents;
public:
double& at(size_t i, size_t j, size_t k)
{
if (i >= M || j >= N || k >= P)
throw out_of_range("Index out of range.");
return contents[i][j][k];
}
double& operator(size_t i, size_t j, size_t k)
{
return contents[i][j][k];
}
};
int main()
{
matrix3d<10, 8, 5> B;
for (int k=0; k<10; k++)
for (int i=0; i<8; i++)
for (int j=0; j<5; j++)
do_something_on_B(B(i,j,k));
return 0;
}
You could go further and make it fully const-correct, add matrix multiplication (proper and element-wise), multiplication by vectors, etc. You could even generalise it to different types (I'd make it template if you mainly use doubles).
You could also add proxy objects so you can do B[i] or B[i][j]. They could return vectors (in the mathematical sense) and matrices full of double&, potentially?
We've been bitten by the following bug many times:
#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;
void print(int* pn) { cout << *pn << " "; }
int main() {
int* n1 = new int(1);
int* n2 = new int(2);
int* n3 = new int(3);
vector<int*> v;
v.push_back(n1);
v.push_back(n2);
v.push_back(n3);
sort(v.begin(), v.end()); // Here be dragons!
for_each(v.begin(), v.end(), print);
cout << endl;
delete n1; delete n2; delete n3;
}
The problem is that std::sort is comparing integer pointers not integers, which is not what the programmer intended. Worse, the output may appear correct and deterministic (consider the order of addresses returned by new or allocated on the stack). The root problem is that sort eventually calls operator< for T, which is rarely a good idea when T is a pointer type.
Is there any way to prevent this or at least get a compiler warning? For example, is there a way to create a custom version of std::sort that requires a comparison function when T is a pointer?
IMO, the programmers should know that std::sort assumes the container stores values. If you need a different behavior for the comparison, then you provide a comparison function. E.g. (untested):
template<typename T>
inline bool deref_compare(T* t1, T* t2) { return *t1 < *t2; }
//...
std::sort(v.begin(), v.end(), deref_compare<int>);
Edit
FWIW, Jacob's answer comes closest to directly accomplishing what you want. There might be some ways to generalize it further.
For pointers in general you could do this:
#include <ctime>
#include <vector>
#include <cstdlib>
#include <algorithm>
#include <functional>
#include <type_traits>
namespace util {
struct sort_pointers {
bool operator() ( int *a, int *b ) {
return *a < *b;
}
};
template <typename T, bool is_pointer = !std::tr1::is_pointer<T>::value>
struct sort_helper {
typedef std::less<T> wont_compare_pointers;
};
template <typename T>
struct sort_helper<T,false> {
};
template <typename Iterator>
void sort( Iterator start, Iterator end )
{
std::sort( start,
end,
sort_helper
<
typename Iterator::value_type
>::wont_compare_pointers() );
}
template <typename Iterator, class Func>
void sort( Iterator start, Iterator end, Func f ) {
std::sort( start, end, f );
}
}
int main() {
std::vector<int> v1;
std::vector<int*> v2;
srand(time(0));
for( int i = 0; i < 10; ++i ) {
v1.push_back(rand());
}
util::sort( v1.begin(), v1.end() );
for( int i = 0; i < 10; ++i ) {
v2.push_back(&v1[i]);
}
/* util::sort( v2.begin(), v2.end() ); */ //fails.
util::sort( v2.begin(), v2.end(), util::sort_pointers() );
return 0;
}
std::tr1::is_pointer was just what it was called in Visual Studio 2008, but I think Boost has one too, and newer compiles might provide it as std::is_pointer. I'm sure someone would be able to write a prettier solution, but this appears to work.
But I must say, I agree with cogwheel, there is no reason for this, the programmer should be able to see if this is going to be a problem and act accordingly.
Addition:
You can generalize it a bit more I think, to automatically select a functor that will dereference the pointers and compare the values:
namespace util {
template <typename T>
struct sort_pointers {
bool operator() ( T a, T b ) {
return *a < *b;
}
};
template <typename T, bool is_pointer = !std::tr1::is_pointer<T>::value>
struct sort_helper {
typedef std::less<T> compare;
};
template <typename T>
struct sort_helper<T,false> {
typedef sort_pointers<T> compare;
};
template <typename Iterator>
void sort( Iterator start, Iterator end )
{
std::sort( start,
end,
sort_helper
<
typename Iterator::value_type
>::compare() );
}
}
That way you don't have to think about if you're providing it with pointers to compare or not, it will automatically be sorted out.
I don't have a good answer for pointers in general, but you can restrict comparisons if you're using a smart pointer of any kind - eg boost::shared_ptr.
#include <boost/shared_ptr.hpp>
using namespace std;
template<class T>
bool operator<(boost::shared_ptr<T> a, boost::shared_ptr<T> b)
{
return boost::shared_ptr<T>::dont_compare_pointers;
}
int main () {
boost::shared_ptr<int> A;
boost::shared_ptr<int> B;
bool i = A < B;
}
Output:
In function 'bool operator<(boost::shared_ptr<T>, boost::shared_ptr<T>) [with T = int]':
t.cpp:15: instantiated from here
Line 8: error: 'dont_compare_pointers' is not a member of 'boost::shared_ptr<int>'
compilation terminated due to -Wfatal-errors.
So you can use smart pointers, or create your own smart pointer wrapper. This is very heavyweight for what you want though, so if you do create a wrapper to detect this situation, I recommend you only use it in debug mode. So create a macro (ugh, I know) and use it to declare pointers.
#ifdef DEBUG
#define pointer(x) pointer_wrapper<X>
#else
#define pointer(x) x*
#endif
This still requires your programmers to use it, of course!