Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue: Incorrect Overload Selection for Templated DeserializeFromBuffer Function (same issue for Serialize) #39

Open
damien-robotsix opened this issue Nov 6, 2024 · 0 comments

Comments

@damien-robotsix
Copy link

damien-robotsix commented Nov 6, 2024

Description:

I am encountering an issue with the DeserializeFromBuffer function templates in the serialization header. When attempting to deserialize a user-defined templated type, the compiler selects the incorrect overload. Specifically, it picks the container overload intended for standard containers (like std::vector, std::array, etc.) instead of the generic overload.

Code Details:

We have the following overloads of DeserializeFromBuffer:

  1. Generic Overload:

    template <typename T>
    void DeserializeFromBuffer(SpanBytesConst& buffer, T& dest);
  2. Container Overload:

    template <template <class, class> class Container, class T, class... TArgs>
    void DeserializeFromBuffer(SpanBytesConst& buffer, Container<T, TArgs...>& dest);

Problem:

When deserializing a user-defined templated type, such as:

template <typename... Args>
struct MyCustomType {
  // Implementation details...
};

the compiler incorrectly selects the container overload instead of the generic one. This happens because MyCustomType matches the template pattern Container<T, TArgs...> due to its variadic template parameters, even though it is not a container (and not iterable).

Proposed Solutions:

To resolve this issue, I suggest constraining the container overload so that it only matches actual container types.

We could implement a type trait to detect acceptable containers (iterables?) and use std::enable_if to constrain the container overload.

Or, we could use has_TypeDefinition to enforce usage of the generic overload when a TypeDefinition is available.

Thank you for your attention to this matter!


In addition to the overload resolution problem, I've noticed that the example provided for TypeDefinition in the README or documentation corresponds to an older implementation. The current code uses a function template for TypeDefinition, but the example still shows a struct specialization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant