Translation old and author long time inactive. It's easier to reject it and rewrite tests from scratch.

I had the same issue at first. I don't know if you have the same issue, but give the following a thought:
What happens if you use your MagicCompare instance in a for loop's body for your comparison and then re-use it as your loop index.
Hope this helps ;)

I'm completely stumped by exit code 139, presumably a segfault, running the sample tests in the web interface. I can't reproduce locally and valgrind/ubsan/asan don't see anything wrong in my code. My code does no heap allocations and the vector indexing in the sample tests dont overrun the vector. So haven't a clue. I'm using g++ 7.3 and clang++ 6.0.

Not posting the solution code here (yet), but here's the steps I'm taking locally:

$ g++ -Wall -Wno-deprecated-declarations -g -O2 -std=c++14 -I../igloo-igloo.1.1.1 cw_test.cpp -fsanitize=address,undefined -o cw
cw_test.cpp: In member function ‘virtual void Tests::should_work_for_basic_relations()’:
cw_test.cpp:14:35: warning: suggest parentheses around comparison in operand of ‘!=’ [-Wparentheses]
     bool res_5gtalt7neqa = (5 > a < 7 != a);
                             ~~~~~~^~~
$ ./cw
...
Test run complete. 3 tests run, 3 succeeded, 0 failed.
$ valgrind ./cw
==22141== Memcheck, a memory error detector
==22141== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22141== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==22141== Command: ./cw
==22141== 
==22141==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==22141== 
==22141== HEAP SUMMARY:
==22141==     in use at exit: 0 bytes in 0 blocks
==22141==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==22141== 
==22141== All heap blocks were freed -- no leaks are possible
==22141== 
==22141== For counts of detected and suppressed errors, rerun with: -v
==22141== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Here's a rust translation...

Added rust version. Looks like OP not been active for some time. What happens next?

To say there's a C++ version of this Kata is stretching things somewhat. The challenge's "interface" is identical to the C version. Instead of this:

struct block { const char *data; int n; };
char *toAscii85 (block b);
block fromAscii85 (const char *string);

what about this?

std::string toAscii85(std::vector<char>&);
std::vector<char>& fromAscii85 (const std::string&);

and you could get rid of the block struct and those macros, which while tolerated in C, are considered bad practice in C++ (even more so lower case ones). It also doesn't force the caller to manage the memory of the returned pointers (the sample tests as they stand leak memory).

I'm trying to learn to code in rust. There are a lot of Katas like this one where the real effort is in reducing the problem to a simple mathematical statement then implementing a one-liner solution.
Don't get me wrong I do enjoy puzzles like this, but they aren't helping me learn what I came here to learn.