C++ variardic universal template for unknown types, used to handle multiple network protocols

Question

I am creating a template function with variardic arguments, to handle a specific classes that have some interface, method, member or whatever is specialized in a specialization area. However I came to a solution to handle even types that are not supported, thus avoid exceptions, polymorphism, virtual functions, RTTI, etc. I'd like to hear a suggestions and also a peak to the implementation. The example below shows a simple parsing of known network protocols (pseudo logic), that can handle all relevant types, if not specialized classes are passed, they shall be omitted as it happens.

#include <iostream>
#include <cstring>

template<typename T>
struct is_validator
{
    static const bool value = false;
};


struct Null {

    Null(const std::string& res[[maybe_unused]]) {}

    bool valid() const {
        return  false;
    }
};


struct RtpRFC
{

    std::string m_res;

    RtpRFC(const std::string& res) : m_res{res}{}

    bool valid() const {
        if (!strcmp(m_res.c_str(), "rtp"))
            return true;
        return  false;
    }

};


struct RtspRFC
{
public:

    std::string m_res;

    RtspRFC(const std::string& res) : m_res{res}{}

    bool valid() const {
        if (!strcmp(m_res.c_str(),"rtsp"))
            return  true;
        return false;
    }

};


struct StunRFC
{
    std::string m_res;

    StunRFC(const std::string& res) : m_res{res}{}

    bool valid() const {
        if (!strcmp("stun", m_res.c_str()))
            return  true;
        return false;
    }

};


struct NonValid
{
};



template<>
struct is_validator<Null>
{
    static const bool value  = true;
};
template<>
struct is_validator<RtpRFC>
{
    static const bool value  = true;
};
template<>
struct is_validator<StunRFC>
{
    static const bool value  = true;
};
template<>
struct is_validator<RtspRFC>
{
    static const bool value  = true;
};

/*terminator*/
bool  VParse(...) {
    return false;
}

template <class T,
         //typename std::enable_if<is_validator<T>::value>::type,
         typename...ARgs>
bool VParse(T type, ARgs&&... FArgs)
{
    if constexpr (is_validator<T>::value) {
    if (type.valid()) {
         return true;
    }
        else {
            return VParse(std::forward<ARgs>(FArgs)...);
        }
    }
    return VParse(std::forward<ARgs>(FArgs)...);

}


int main(void)
{
    std::string ret{};
    const std::string someNetworkData[10] = {
        "stun", "rtp", "stun", "stun", "rtsp", "rtp", "http", "http2", "udp"
    };

    for(int i=0; i < 10; i++) {
        auto res = someNetworkData[i];
        bool valid = VParse(
                10,
                "test",
                NonValid{},
                RtpRFC{res} ,
                RtspRFC{res},
                StunRFC{res},
                Null{res}, //dummies
                Null{res},
                Null{res}
            );
        if  (valid) {
            ret += res;
            ret += "|";
        }
    }

    std::cout << ret;
    return 0;
}

Answer 1

Avoid C string functions if possible

There is no need to use strcmp(), especially not if you are working with std::strings to begin with. For example, you can just write:

bool valid() const {
    return m_res == "rtp";
}

Also make sure then to #include <string> instead of #include <cstring>.

Simplifying the code

Since your code needs C++17 anyway, you can simplify VParse() significantly by using fold expressions and a helper function, like so:

template <typename T>
bool is_valid(T&& type)
{
    if constexpr(is_validator<T>::value) {
        return type.valid();
    }
    return false;
}

template <typename... Args>
bool VParse(Args&&... args)
{
    return (is_valid(std::forward<Args>(args)) || ...);
}

This splits the code into one self-contained part that checks a single argument, and another part that just iterates over all arguments.

Should you allow types that are not validators?

I think it's risky to have your function check whether is_validator<T>::value is a valid expression, and ignoring it if not. It's quite easy to make a typo somewhere and turn a valid validator into something that's not, and your code will then explicitly allow that, instead of letting the compiler catch the error. So I would recommend using SFINAE (like the one you commented out), or concepts if you can use C++20, to limit the accepted types, unless you really have a situation where it would be better to allow arbitrary types and ignore those that you can't use.

Alternatives

I assume the above code is just a toy example, but consider what happens if the list of validators grows a lot more than you have in your example. VParse() will have to call each validator in turn before one returns true. This can be expensive. If it is just matching strings, then you could just use a std::unordered_set<std::string> of valid types and check if a given protocol name is in that set.

Answer 2

GSliepen posted some good stuff, so I'll try to omit duplicates in my own answer.

Formatting. The compiler doesn't care, but the human reader cares. You wrote:

template <class T,
         //typename std::enable_if<is_validator<T>::value>::type,
         typename...ARgs>
bool VParse(T type, ARgs&&... FArgs)
{
    if constexpr (is_validator<T>::value) {
    if (type.valid()) {
         return true;
    }
        else {
            return VParse(std::forward<ARgs>(FArgs)...);
        }
    }
    return VParse(std::forward<ARgs>(FArgs)...);

}

Notice the misindented if; the random blank line after return; the arbitrary mixture of class and typename keywords; the miscapitalized ARgs; the mixture of cases in variable names (type, FArgs). Also the number of lines wasted by { braces; but that's more of a religious issue, I admit. Anyway, I would have written:

template <class T, typename... Args>
bool VParse(T type, Args&&... args) {
    if constexpr (is_validator<T>::value) {
        return type.valid() || VParse(std::forward<Args>(args)...);
    }
    return VParse(std::forward<Args>(args)...);
}

GSliepen's simplification using a helper is_valid and a fold-expression is indeed the best answer.

---

template<>
struct is_validator<Null> {
    static const bool value  = true;
};
template<>
struct is_validator<RtpRFC> {
    static const bool value  = true;
};

(1) Use constexpr for compile-time constants, not plain const. (const is useful for pass-by-const-reference and stuff, where you're saying "I promise not to modify this, but somebody else might be allowed to, I don't care.")

(2) C++11 has true_type and false_type for this. Write:

template<class> struct is_validator : std::false_type {};
template<> struct is_validator<Null> : std::true_type {};
template<> struct is_validator<RtpRFC> : std::true_type {};

(3) It seems to me that your criterion for "Is it a validator?" is really no more or less than "Does it have a .valid() method?" You can implement a trait that checks for that exact requirement, using a C++11 partial specialization:

template<class, class = void> struct is_validator : std::false_type {};

template<class T>
struct is_validator<T, decltype(
    std::declval<const T&>().is_valid(), void()
)> : std::true_type {};

or using a C++20 requires-expression:

template<class T>
concept validator = requires (const T& t) {
    t.is_valid();
};

// optionally, keep your familiar type trait, like this
template<class> struct is_validator : std::false_type {};
template<validator T> struct is_validator<T> : std::true_type {};

---

The efficiency issue that stands out to me isn't that your recursive (or fold-expression) implementation loops linearly over all possible validator types. The issue for me is that you spent all that time to construct all N validators in the first place, when only one of them will ever be used!

    bool valid = VParse(
            10,
            "test",
            NonValid{},
            RtpRFC{res} ,
            RtspRFC{res},
            StunRFC{res},
            Null{res}, //dummies
            Null{res},
            Null{res}
        );

Maybe this is just a toy example. But notice how many different std::string copies you're making of res. I think it would make more sense to pass in just the names of the types, like

template<class... Validators>
bool canParseAsOneOf(const std::string& res) {
    return (
        Validators(res).valid() || ...
    );
}

bool valid = canParseAsOneOf<RtpRFC, RtspRFC, StunRFC>(res);

Now you don't spend time constructing a StunRFC object until you've already determined that RtpRFC and RtspRFC don't work.

If you do this, of course, you're expanding the list of affordances required by your validator types. A validator now must also be constructible from a const string&. So we should update our "validator" concept:

template<class T>
struct is_validator<T, decltype(
    T(std::declval<const std::string&>()),
    std::declval<const T&>().is_valid(),
    void()
)> : std::true_type {};

or in C++20

template<class T>
concept validator = requires (const T& t, const std::string& s) {
    T(res);
    t.is_valid();
};