• .

  • This issue spoiled all the fun of this kata for me :( @A.Partridge, please, please fix this!

  • approved some time ago

  • Approved

  • I think that since order of evaluation of arguments is not specified by C++ rules, following line: do_test(generateSum(expected), expected); has a potential problem of passing "" as expected to do_test.

    Call to generateSum should be made in a separate statement, before a call to do_test.

    It turns out I was probably wrong, because all args are passed by reference here.

  • vector<string> anagrams(const string &word, const vector<string> &words)
    static int answer = 0;
      switch(answer++) {
          case 0: return {"a"};
          case 1: return {"ab", "ba"};
          case 2: return {"aabb", "bbaa"};
          case 3: return {"aabb", "bbaa", "abab", "baba", "baab"};
          case 4: return {"carer", "racer"};
          case 5: return {};
        vector<string> matches;
        for (auto w : words)
            if ( w.length() == word.length() )
        return matches;

    Random tests are bad.

  • As far as I know, quite a few people solve katas locally in IDEs, so sample tests should preferably be self-contained, not depending on hidden preloaded code. What is do_test even for if it only calls Assert::That?

  • Maybe this is relevant.


    Section para 15.

    For two function types to be compatible, both shall specify compatible return types.
    Moreover, the parameter type lists, if both are present, shall agree in the number of
    parameters and in use of the ellipsis terminator;

    IIUC that means your cast of the predicate with 1 param to the predicate with 2 params technically made them "incompatible", right?

  • Depending on the calling convention, stack or registers, you'll end up with an unused NULL ptr on the stack or a zeroed out register that's ignored.

    I am not really sure it's true but I'd appreciate if anyone points me to the source which proves otherwise.

    Behavior here indeed depends on used calling convention, and it would work only for conventions with stack set up and cleaned up by the caller. Incidentally, 32-bit cdecl and 64-bit linux calling conventions are such, so it works in all current cases, but I am not 100% sure that it's universally safe and guaranteed to work by rules of C language, or on all platforms. AFAIK, C does not guarantee any type of calling convention, and does not guarantee anything about passing of superfluous parameters.

    Or does it?

  • Thanks for the detailed reply. Here is a +1 clever vote :-)

    EDIT: Hmmm let me retract that +1 clever pending more information!

  • Added a couple fixed cases with the full alphabet, lower and upper case, as well as more punctuation. Copied the same cases to my other translations.

  • Yes. If the predicate is only expecting 1 arg, then the 2nd one will be ignored. The NULL is just a placeholder. Depending on the calling convention, stack or registers, you'll end up with an unused NULL ptr on the stack or a zeroed out register that's ignored. A problem does arise when you pass too few parameters and the callee tries to use uninitialized garbage data.

    Of course, this is all dependent on the user calling the reentrant version with a two-arg predicate, and the non-reentrant version with either a one-arg predicate or a two-arg predicate that handles NULL correctly. You could write a single two-arg predicate that functions as a one-arg version depending on the 2nd arg's value, then use that for both reentrant and non-reentrant applications.

    If you haven't yet, take a look at variable arguments handling in C (stdarg.h). The initial parameter(s) must be strictly defined, as they tell the function how many additional parameters are passed, and potentially how to interpret them. See the printf family of functions. I know that while javac verifies all the parameters passed to String.format, I've never seen a C compiler parse the format string. It's done at run-time.

  • Missing fixed tests with punctuation other than "!". I think all letters should be covered by the fixed tests too.

  • This is either very clever or very lucky. I am not sure.

    Is it really ok to call the predicate with a 2nd NULL arg if it expected only 1 argument?

  • Added an empty string test case to my translations. Broke two C solutions and four Java solutions with the change. People, come on! :-P

    The JavaScript test framework breaks when fed an empty string, so I'll leave that to the original author. Not touching the other languages.

  • Loading more items...