Performance is too low, online compiler wants a faster way to find all possible combinations of k numbers out of 1...n
Preface:


  if you can, don't use advanced syntax


I understand why you say this, but do not shy away from strange looking syntax.  When you encounter something you cannot read, take the time to lookup what the syntax does (even experienced developers do this).  The weird looking syntax may be doing useful stuff.  And after you understand what's going on, the syntax usually doesn't look weird anymore.

Another algorithm:

First off, for a beginner, this is a great start.  It's very simple code which is good.

If you want faster code, the first thing to do is make sure your general approach is reasonable or better yet optimal.  Your algorithm generates all possible sets of length K with elements from {1,2,...N} and then checks if the sets are sorted.  Note that I have used N for the size of the input set and K for the size of the combinations -- this is a convention I have seen in many places but is different from your code.

There are $$K^N$$ possible sets of length K from a set of N objects.  For the same set of N objects, there are $$\frac{N!}{K!(N-K)!}$$ combinations.  Since the combinations are a subset of the possible sets, they are a smaller set and in many cases they are a much smaller set.  Interestingly there are some non integer solutions for K^N &lt; (N choose K) e.g. K = 0.5 and N = 1.5. maybe someone else can shed some light on that.  But they key takeaway is that only generating combinations will be a lot faster.

How can you only generate combinations?  There's more than one way to do this, but I will describe one way.

Consider the n=5, k=3 example.  The set of numbers to maybe print is 1,2,3,4,5, and the set of numbers to definitely print is {} (empty set).  I'll simplify this as ({}, {1,2,3,4,5}).  Some of the combinations have 1 and some don't. So we now have to consider both the possibilities ({1},{2,3,4,5}) and ({}, {2,3,4,5}).  We repeat this recursively, and when we have a set of things of size el_maxim (or, by convention, k), we print.  In psuedo-code:

void recurse(int indexK, int indexN) {
    if (indexK == K) {
        print(result);
        return;
    }

    // "if there more slots to fill than numbers to fill them"
    // could also say `if (indexN == N)` ... correct but slower
    if (N - indexN &lt; K - indexK) {
        return;
    }

    result[indexK] = indexN;

    recurse(indexK + 1, indexN + 1);
    recurse(indexK, indexN + 1);
}


I encourage you to try getting this function to compile and then benchmarking to make sure you see the speedup you would expect.  You'll have to try a few different values of N and K.  For some inputs &lt;10, the improved algorithm should run 1000s of times faster!

Review of your code:

Since my main advice is to use a better algorithm, I haven't given any specific comments on your code.  I'll do that here:

Your program should be based around a function that can generate combinations.  The function should take N and K as input, and it should return all the combinations.  Something like this:

/// This function generates all combinations of integers {1,2,...,N}
/// @param N    the size of the set
/// @param K    the size of the combinations
ResultType generateCombinations(int N, int K) { ... }


Then your main function should call generateCombinations.  This has several advantages over your method:


The compiler will make sure you set all the inputs.  In your version, if you forget to set a global variable, then you'll get the wrong answer.
You have a convenient place to put a big comment about what the function does.  The comment I've placed above is in Doxygen's format so you can generate documentation from your comments.  It also looks pretty good in my opinion.
You can easily call the function in several places.
You don't have to worry about name collisions.
The compiler can optimize arguments better than global variables.  In general, compilers are really good with functional code and not so good with code that uses lots of memory.
I could go on but I think you get the point.




Separate printing the combinations from generating the combinations.  You've sort of done that with the display function, but not really since anyone who calls bkt is forced to print the result.  There are two main ways to do this.  The first way is to return a big data structure, and then print it:

std::vector&lt;std::vector&lt;int&gt;&gt; generateCombinations(int N, int K) { ... }

for (auto&amp; vec : genCombinations(5, 3)) { print(vec); }


This way is pretty easy/simple.  The downside is it uses a lot of memory.

The second way is to accept an argument that says what to do with each result:

void genCombinations(int N, int K, std::function&lt;void(vector&lt;int&gt;&amp;)&gt; func) { ... }

genCombinations(5, 3, [](auto&amp; vec) { print(vec); });


This is probably harder to read for many people, but it saves a large amount of memory in this case!



Your names are a little weird.  el_maxim instead of maximum_element or N as dictated by convention.  n instead of num_elements or K per the convention.  Also bkt and okay seem like they were chosen because they are short rather than because they are good descriptions of what they do.



okay();
if (okay() == 1)


Is this intended?

P.S.

I encourage you to rewrite and post another code review using a faster algorithm!  You may get more comments on your code rather than on your approach.