0

trying to find a (probably) preprocessing trick which will do something similar to the next pseudo C++

myVariadicFun(argv[0],argv[1],argv[2],...,argv[argc] );

the variadic function is ready and working, just need to parse the array arguments in it.

reason for not just passing an array pointer is because im playing with constexpr / metaprogramming actually.

Arty McLabin
  • 83
  • 1
  • 10

2 Answers2

0

With [Boost.Preprocessor] you can easily achieve appropriate code generation for your needs described in the screenshot:

#include <boost/preprocessor/repetition/enum.hpp>

#define ARRAY_ELEMENTS(z, n, arrVar) arrVar[n]

#define EXPAND_ARRAY(N, arrVar) \
  BOOST_PP_ENUM(N, ARRAY_ELEMENTS, arrVar)

#define EXPAND_CASE(N, arrVar) \
    case N: cout << crawler(EXPAND_ARRAY(N, arrVar)).best_sum << endl; break

int main(int argc, char* argv[]) {
    char** input = &argv[1];
    --args;
    switch(argc) {
    EXPAND_CASE(1, input);
    EXPAND_CASE(2, input);
    EXPAND_CASE(3, input);
    }
}

BOOST_PP_REPEAT_FROM_TO allows to perform further code folding:

#include <boost/preprocessor/repetition/enum.hpp>
#include <boost/preprocessor/repetition/repeat_from_to.hpp>

#define ARRAY_ELEMENTS(z, n, arrVar) arrVar[n]

#define EXPAND_ARRAY(N, arrVar) \
  BOOST_PP_ENUM(N, ARRAY_ELEMENTS, arrVar)

#define EXPAND_CASE_Z(z, N, arrVar) \
 case N: cout << crawler(EXPAND_ARRAY(N, arrVar)).best_sum << endl; break;

// actually each OS has its own limitation for maximal number of arguments, see your
// OS docs for more info. Beware Boost.Preprocessor has its own limits for repeatable
// macros expansions
#define MAX_ARGS 100

int main(int argc, char* argv[]) {
    char** input = &argv[1];
    --args;
    switch(argc) {
    BOOST_PP_REPEAT_FROM_TO(1, MAX_ARGS, EXPAND_CASE_Z, input);
    }
}

But frankly speaking I doubt variadic template functions are intended to be used this way.

user3159253
  • 16,836
  • 3
  • 30
  • 56
  • i do work with constexpr and i did use a recursive tail of course, can you just tell me a way to parse array elements in preprocessor if you know one? ill deal with the rest. – Arty McLabin Oct 30 '15 at 10:14
  • Hmm do ask about [variadic preprocessor macros](https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html) ? For macros with different number of arguments you may consider [this](http://stackoverflow.com/questions/11761703/overloading-macro-on-number-of-arguments) – user3159253 Oct 30 '15 at 10:26
  • nice one, but unfortunately that's not what i search for. i seek something like #define moo(array, n) array[0],array[1],...array[n] – Arty McLabin Oct 30 '15 at 10:43
  • like [Boost_PP_FOR](http://www.boost.org/doc/libs/1_59_0/libs/preprocessor/doc/ref/for.html) ? What _is_ the task you're trying to solve? – user3159253 Oct 30 '15 at 11:04
  • i try to avoid anything but standard C++ for this task, as it is made for the sake of research. the task is exactly what i've asked before. everything works including the meta-calculation, and constexpr processes argv. i just want to somehow automatize the code with some kind of macro/template so it won't look as "manual" and long as this (current working state): http://i.imgur.com/z2Bz17L.jpg – Arty McLabin Oct 30 '15 at 12:00
  • 2
    Well, do you understand, that argc and argv are _unknown_ at the moment of compilation? That is **completely unknown**. It's theoretically impossible to avoid _runtime_ check of `argc`, and therefore in either case you will need some sort of `switch` (perhaps, hidden by a macro but it's not that important). But you _may_ generate the repeated code. Certainly Boost.Preprocessor looks scary, but nevertheless, it's just a _library_ of macros and thus works with any C preprocessor. Certainly there's some code for portability between various implementations of `cpp` but not that much. – user3159253 Oct 30 '15 at 12:13
  • of course, i don't even aim to omit the check of argc, the goal is to make the code less handwrited, say 1 "(100)times-macro" instead of what you could see in the picture from my previous comment. i'm not too familar with Boost, can that Boost_PP_FOR actually do the trick in my case? – Arty McLabin Oct 30 '15 at 14:20
0

No, by definition you cannot use a dynamic sized array (i.e. whose size is defined at execution) with a compilation time size deduction.

Johan
  • 3,728
  • 16
  • 25
  • wrong. POC here: (forgot '!' before bool met_end_char) http://i.imgur.com/XsWCu0v.jpg http://i.imgur.com/LJUIM3e.jpg – Arty McLabin Oct 30 '15 at 10:24
  • @ArtyMcLabin The size you use in to deduce the compile time size is not the size of the array but a compile time provided value. – Johan Oct 30 '15 at 12:01
  • you may have noticed, that a runtime user input redirects the flow control. it was a simple prove of concept, yet it shows that runtime CAN control the output of compiled calculation table. take a look at my current state. http://prntscr.com/8x6nq5 fully working. just a lot of manual copypast work which i could express using macros instead. – Arty McLabin Oct 30 '15 at 19:44