LeetCode 399: Evaluate Division
Seems basically reasonable. Some English nits: You said &quot;nominator and denominator,&quot; when the English terms are &quot;numerator and denominator.&quot; You also seem to be using the word &quot;evaluate(s)&quot; as a noun (something like &quot;precipitate&quot; in chemistry), when I think the word you meant was more like &quot;value(s).&quot;

struct Node {
    Node(std::string const parameter, double const evaluate) {
        this -&gt; parameter = parameter;
        this -&gt; evaluate = evaluate;
    }

    std::string parameter;
    double evaluate;
};

Write this-&gt;x, not this -&gt; x, for the same reason you write st.x and not st . x. But in fact, this constructor would be better written as either
struct Node {
    explicit Node(const std::string&amp; p, double v) : parameter(p), value(v) {}
    std::string parameter;
    double value;
};

or simply
struct Node {
    std::string parameter;
    double value;
};

since simple aggregates can already be initialized with e.g. Node{&quot;a&quot;, 2}. Notice that I'm passing std::string by const reference, because it is expensive to copy.
You could actually rewrite all of the helper functions and data structures to use C++17 std::string_view instead of std::string, as long as all the stringviews referred to the original long-lived strings from equations and queries which you are appropriately careful not to modify. This would be an &quot;advanced&quot; idea, though, and probably wouldn't even buy you any speed in this case where all your strings seem to be 1 character long.

for (auto&amp; query : queries) — Use for (const auto&amp; query : queries) to indicate that the const-qualification is on purpose; or use auto&amp;&amp; in generic code if you just want something that always works. I don't see any reason to use specifically auto&amp; to get a specifically const-qualified result.

        if (visited.find(child.parameter) == visited.end()) {
            accumulated *= child.evaluate;

            if (child.parameter == denominator) {
                return true;
            }

            if (solve_equation(child.parameter, denominator, accumulated, visited)) {
                return true;

            } else {
                accumulated /= child.evaluate;
            }
        }

This if-else ladder is indeed confusing. I would write it like this:
        if (visited.find(child.parameter) != visited.end()) {
            // we have already visited this node; skip it
        } else if (child.parameter == denominator) {
            // we've reached our destination node and resolved the query
            accumulated *= child.value;
            return true;
        } else if (solve_equation(child.parameter, denominator, accumulated, visited)) {
            // this node is on a path that resolves the query
            accumulated *= child.value;
            return true;
        } else {
            // this node is not involved in the solution; do nothing
        }

The most confusing part of the original ladder was
            } else {
                accumulated /= child.evaluate;
            }

That line is really just undoing the multiplication hidden at the top of the loop. But the multiplication is done one scope higher than it is undone, which violates most programmers' intuition. It would have been a simple fix to write
        if (visited.find(child.parameter) == visited.end()) {
            accumulated *= child.evaluate;
            if (child.parameter == denominator) {
                return true;
            }
            if (solve_equation(child.parameter, denominator, accumulated, visited)) {
                return true;
            }
            accumulated /= child.evaluate;
        }

thus visually indicating the symmetry between *= and /=.

bool solve_equation(std::string const nominator,
    std::string const denominator, double&amp; accumulated,
    std::set&lt;string&gt;&amp; visited)

Consider whether visited should be a data member of class Solution.
Passing by const value is always a bug; you left off the &amp;. If you used west const style, you could use these git grep lines to find such bugs: https://quuxplusone.github.io/blog/2019/01/03/const-is-a-contract/
Consider whether the return type of this function should be std::pair&lt;bool, double&gt;; or, in C++17, std::optional&lt;double&gt;.
Put it all together and you get a C++14 signature like
std::pair&lt;bool, double&gt; solve_equation(const std::string&amp; numerator,
                                       const std::string&amp; denominator);

or a C++17 signature like
std::optional&lt;double&gt; solve_equation(std::string_view numerator,
                                     std::string_view denominator);


You have methods named both calcEquation and solve_equation. Admittedly, the name calcEquation is just flat wrong; it should be something like solve_equations (plural). But, given that you aren't allowed to change the public name, personally I would go with calcEquation and calcSingleEquation — reusing the same verb instead of a near-synonym, and emphasizing that this function calculates for a single equation, since I don't have the option of adding an s to pluralize the public name.