Is it possible to have stringification after numeric evaluation?
Yes. For reference here are some specific definitions I'll use:
- arithmetic The ability to perform calculations on numbers using common primitives such as adding, subtracting, multiplication, division, etc.
- expression A grammatical representation of arithmetic using common operators such as parenthetical groupings, infix operators +, -, *, /, etc.
Arithmetic approach
Given these definitions, macro expansions cannot evaluate expressions, but they can perform arithmetic. Instead of the operators you would use macros, each of which would implement arithmetic from scratch. Here's a boost pp usage using this approach:
#include <boost/preprocessor/arithmetic.hpp>
#include <boost/preprocessor/stringize.hpp>
#define A 1
#define B 2
#define SUM BOOST_PP_ADD(A, B)
BOOST_PP_STRINGIZE(SUM)
Demo
With this approach, you get to simply expand a macro to a result; that result can then be stringified. But you're implementing arithmetic itself in macros as opposed to operators, and that takes a lot of macros. So to pull this off, either your number ranges need to be severely limited, or you need to use numbers that are decomposable to macro evaluation (e.g., represent 20000 as (2,0,0,0,0) as opposed to 20000). Boost pp arithmetic uses the former approach (works with ranges from 0 to 256; yes, I realize that's 257 numbers).
Expression approach
Alternately, you can evaluate expressions. As noted, the preprocessor can evaluate expressions in conditional directives. Using that as a primitive, you can tease out the result; e.g., if EXPRESSION expands to your expression, you can #define D0, representing the unit digit of the result, using a construct like this:
#if ((EXPRESSION)%10)==9
#define D0 9
#elif ((EXPRESSION)%10)==8
#define D0 8
...
You can then similarly #define D1 to be the specific digit for the ten's place, D2 for the hundreds, etc... then have a RESULT macro expand to ... D3##D2##D1##D0. Wrap this entire thing into something like evaluator.hpp and you can pump an arbitrary expression in by defining EXPRESSION as your expression, using #include "evaluator.hpp" to evaluate it, and finally use RESULT to represent the result. With this approach each "evaluator" needs the specific Dx macros defined to the specific digits to work... so that behaves analogously to "variables", but consumes the entire evaluator.
Boost pp has this capability with each evaluator known as a "slot", and provides 5 slots. So you have to pump with #include's, and each evaluator can only store one result at a time... but in return your range is not restricted (more than native ranges) and you're actually evaluating expressions. Here's an example of using this approach using boost pp:
#include <boost/preprocessor/slot/slot.hpp>
#include <boost/preprocessor/stringize.hpp>
#define A 1
#define B 2
#define SUM (A+B)
#define BOOST_PP_VALUE SUM
#include BOOST_PP_ASSIGN_SLOT(1)
BOOST_PP_STRINGIZE(BOOST_PP_SLOT(1))
Demo
(Edit: Hand rolled evaluator here (wandbox) might be worth review to see how the mechanics explained above work).
TL;DR summary
arithmetic
- pro: evaluates entirely by macro invocation
- con: macros instead of infix operators
- con: either ranges are limited or uses alternate literal representations
expressions
- pro: evaluates actual expressions (infix, groups, etc)
- pro: ranges as open as native ranges, with ordinary literals
- con: requires `#include` to pump generic mechanism
- con: reuse of evaluator must lose previous result
