Enumerable 'infinite'

Input

Any value with copy constructor

Output

Enumerable returning the input value at every iteration.

Example

for(const auto &i : infinite(3))
    cout << i << ", "; //should print 3, 3, 3, 3 .........

The title is pretty self explanatory ;)

As far as I know the code should be compilable under VS2015 - and so CI should also cover this compiler/ide.

Currently tests are only made on gcc7, but the code should also be runnable (and tested) at gcc5 and gcc6.

Operator mapped_values

Input

Associable enumerable.

Output

Enumerable to iterate through mapped values of given associable enumerable.

Example

const auto input = { std::make_pair(1, 2), std::make_pair(3, 4), std::make_pair(5, 6) };
const auto output = input | keys;
for(const auto &i : output)
    std::cout << i;
//output should be 2, 4, 6

They act as code bloat currently and rarerly are even compileable - let's remove them.

Currently some data (mostly in holders) is passed always by value. It is not very bad, but can be fixed using perfect forwarding.

I started with this name, but let's be honest - it is not very good. Perhaps you can come up with something better

Currently there are two versions of fold_left, because MSVC has issues with auto conversion operator. Even though there should be way to merge them in the way that both compilers will accept the code.

Currently operator count requires a predicate to count specific data. It should be possible to count all the elements regardless of any predicate.

Currently there is quite a lot files in tpl directory. It should have few subdirectories like: sources, operators, sinks with corresponding headeres put inside them.

Currently Visual Studio at AppVeyor complains about `operator decltype(...)' in fold_left_* operators.

gcc4.9 has theoretically all the features this library needs to work. We should try to add it to the matrix.

Currently most of these warnings are order of initailization lists in constructor. This can be easily fixed

Enumerable generator

Input

Single argument function returning type convertible to its argument and initializing value of the same type as the function.

Output

Enumerable returning value "generated" by the function. Generator passes previous generated value to the function which builds up new value from it and returns it.

Example

for(const auto &i : generator([](const auto &i){ return i+i; }, 1))
    cout << i << ", "; //should print 1, 2, 4, 8, 16, ......

There should be operator.hpp for all headers in operator directory, sink.hpp for all in sink directory and so forth. Additionaly there should be a tpl.hpp including all of these.

It may be convinient to add possibility for all operators (for which it makes sense ofc) to use two argument functions, where first would be keys and the second one would be mapped values. Currently given operators would need work:

• filter
• transform

operator++ in flatten operator causes crash at VS2017 x64 with Debug enabled. This should be fixed immidiatelly.

Currently infinite generates sequence of single value. It would be nice to be able to generate repeating sequence of values like {1, 2}.

Operator copy_to

Input

Enumerable and output iterator to copy into.

Output

No output. The outcome is that all elements from enumerable are copied into the output iterator,

Example

const auto input = { 1, 2, 3, 4, 5, 6 };
std::vector<int> output; 
input | copy_to(std::back_inserter(output));
//vector output should contain 1, 2, 3, 4, 5, 6

Operator drop

Input

Enumerable and unsigned number.

Output

Enumerable from the argument without given numer of elements from beginning.

Example

const auto input1 = { 1, 2, 3, 4, 5 };
const auto out = intput1 | drop(2);
//out should contain 3, 4, 5

Many operations in iterators is repeatable. It would be wise to create common base for iterators.

Operator reverse

Input

Enumerable.

Output

Enumerable with reversed order of elements.

Example

const auto input = { 1, 2, 3, 4, 5, 6 };
//sum example
const auto output = input | reverse;
//output should contain { 6, 5, 4, 3, 2, 1 };

Remarks

This feature depends on implementation of:

• #8 Implementation of reverse iterators for enumerables

Operator zip

Input

Two enumerables

Output

Enumerable coresponding to "zipping" of two enumerables. For example from zip({1, 2}, {'a', 'b'}) -> { (1, 'a'), (2, 'b') }. In case zipped enumerables have different number of elements, the longer is truncated at the end.

Example

const auto input1 = { 1, 2, 3 };
const auto input2 = { 'a' , 'b', 'c', 'd' };
const auto zippped = zip(input1, input2);//zipped should contain { (1, 'a'), (2, 'b'), (3, 'c') }
//optionally input1 | zip(input2)

Blockers:
[x] #56
[x] #57
[ ] #59

These two operators have generally a lot of common code, they should be made a template depending on function to extract value from pair.

If gcc compiles the code, the clang should also be checked. Probably versions 3, 4 and 5 would be sufficient

Currently there is no code coverage control. Yet for the code to be tested well the coverage should be measured and controlled all the time.

Namespaces and names of directories should be the same. Currently it is not unified

For code to be more readable it should be used with internal naming - every Container in code should be raplaced with Enumerable.

Operator flatten

Input

Enumerable of enumerables of generic type T.

Output

Enumerable containing all elements of the internal enumerables from input.

Example

const auto input = { (std::vector{1, 2}), (std::vector{3, 4, 5}), (std::vector{6}) };
const auto output = input | flatten;
for(const auto &i : output)
    std::cout << i;
//output should be 1, 2, 3, 4, 5, 6

Currently only Travis is supported - Windows builds would be helpful.

Operator take

Input

Enumerable and unsigned number.

Output

Enumerable containing given numer of elements from the beginning of the enumerable argument.

Example

const auto input1 = { 1, 2, 3, 4, 5 };
const auto out = intput1 | take(2);
//out should contain 1, 2

Currently many operations are using "holders" to construct operators later. There should be more OO solution used - instead of holders factories should be used with create method.

Currently all "holders" are held in detail namespace which causes problems with operator| usage. Simply enough - the detail namespace aruond those should be removed.

"Deep" versions of algorithms would work for nested enumerables without breaking this nested hierarchy. For example:

const auto input = { (std::vector{1, 2}), (std::vector{3, 4, 5}), (std::vector{6}) };
const auto output1 = input | deep_filter([](const auto &i){ return i >=2; });
// output1 is now {{2}, {3, 4, 5}, {6}}

const auto output2 = input | deep_filter([](const auto &i){ return i < 6; });
// output2 is now {{1, 2}, {3, 4, 5}, {}}

I will gladly disscuss pros and cons of keeping the empty containers inside hierachy.

Our TODO list is:

• transformed
• sorted
• filtered
• flattened

child of #17

As the title says, it should be possible to iterate backwards on the enumerables .

Currently callables are store in lambdas by value but if callables were pure they could be stored by reference. This requires further research

It looks like these namespaces give more problems than gain. They should be removed and their contents moved to tpl namespace.

Currently sorted_sequence caches the input only once. It can be a problem when dealing with mutable input enumerables. All in all, it should sort data everytime it is requested iterator.

TODO list (checked are already done):

• trait for checking if given type is enumerable
• trait for checking if given type is associative
• proper typedefs concerning associative enumerables
• function types traits
• enumerable traits

Currently constexpr is not used - but it should be to move some of evaluations to the compile time.

Currently, every time iterator is dereferenced whole computation process is required. Cache operator would store the data at some point to avoid computing same data multiple times.

Currently the whole "flow" of data from source through operators to sinks is required for operator | to work properly. It would be useful to be able to compose more complex operators using the ones provided without need to specify input and/or output.

Operator fold_left

Input

Enumerable and folding functiion. Optionally folding start value
Enumerable, folding function and folding start value. If start value is not given, default value of the enumerable value type is used as initial.

Output

Folded value depending on folding function.

Additional info

As fold is not so easy to describe here is given quite good explanation:
https://en.wikipedia.org/wiki/Fold_(higher-order_function)

Example 1

const auto input = { 1, 2, 3, 4, 5, 6 };
//sum example
const auto output = input | fold_left((const auto &a, const auto &b)[]{ return a + b; });
//output should be 21

Example 2

const auto input = { 1, 2, 3, 4, 5, 6 };
//sum example
const auto output = input | fold_left((const auto &a, const auto &b)[]{ return a + b; }, 2/*fold initial value*/);
//output should be 23

Operator keys

Input

Associable enumerable.

Output

Enumerable to iterate through keys of given associable enumerable.

Example

const auto input = { std::make_pair(1, 2), std::make_pair(3, 4), std::make_pair(5, 6) };
const auto output = input | keys;
for(const auto &i : output)
    std::cout << i;
//output should be 1, 3, 5

Lot's of features has been added since last readme update. There is also a lot to clarify and fix.

Root should be directory include. Inside should go tpl directory with its contents. Operation directory sholud be renamed to operator.