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

Compile Error on g++ using get() function #3827

Closed
2 tasks done
phil-zxx opened this issue Nov 12, 2022 · 2 comments · Fixed by #4039
Closed
2 tasks done

Compile Error on g++ using get() function #3827

phil-zxx opened this issue Nov 12, 2022 · 2 comments · Fixed by #4039
Labels
kind: bug solution: invalid the issue is not related to the library

Comments

@phil-zxx
Copy link

Description

When iterating over a nlohmann::json object and then casting the values using value.get<std::string>(), we observe that g++ gives a compile error. On clang and msvc everything compiles just fine.

Replacing value.get<std::string>() with std::string(value) fixes the problem on g++. But I wonder why the get function does not work?

Reproduction steps

See https://godbolt.org/z/Gxv7dbsjW

Expected vs. actual results

I would expect the "minimal code example" to compile as is on g++. But it does not.

Minimal code example

// https://godbolt.org/z/Gxv7dbsjW

#include <nlohmann/json.hpp>
#include <iostream>

template<class K, class V>
void convert(const nlohmann::json& sourceData, std::map<K, V>& targetMap)
{
    for (const auto& [key, value] : sourceData.items())
    {
        if constexpr(std::is_same_v<V, std::string>)
            targetMap.emplace(key, value.get<std::string>());
            //targetMap.emplace(key, std::string(value));  // Only way to fix g++ is to use this line
        else
            throw std::runtime_error("Case not covered");
    }
}

int main()
{
    const nlohmann::json data = {
        {"Year2", "2022" },
        {"Year3", "2023" },
        {"Year9", "2029" }
    };
    std::map<std::string, std::string> m;
    convert(data, m);

    for (const auto& [k, v] : m)
        std::cout << " - " << k << ": " << v << std::endl;

    return 0;
}

Error messages

<source>:10:42: warning: expected 'template' keyword before dependent template name [-Wmissing-template-keyword]
   10 |             targetMap.emplace(key, value.get<std::string>());
      |                                          ^~~
      |                                          template

<source>:10:57: error: expected primary-expression before '>' token
   10 |             targetMap.emplace(key, value.get<std::string>());
      |                                                         ^

<source>:10:59: error: expected primary-expression before ')' token
   10 |             targetMap.emplace(key, value.get<std::string>());
      |                                                           ^

Compiler and operating system

g++ (Linux)

Library version

3.11.1 & trunk

Validation

@falbrechtskirchinger
Copy link
Contributor

falbrechtskirchinger commented Nov 12, 2022

Don't use structured bindings or do as the compiler asks. Adding the template keyword to disambiguate the dependent name (which I assume is due to the compiler-generated code for the structured binding) resolves the issue on GCC and still compiles on Clang and MSVC.

targetMap.emplace(key, value.template get<std::string>());

This is not a bug in the library.

Edit: In case you're unfamiliar with this construct, see: https://en.cppreference.com/w/cpp/language/dependent_name#template_disambiguator

@phil-zxx
Copy link
Author

phil-zxx commented Nov 12, 2022

Thank you for the detailed explanation. I did not know about this syntax. Though, I am surprised clang and msvc don't complain.

As this is not a bug, the issue may be closed.

@nlohmann nlohmann added the solution: invalid the issue is not related to the library label Dec 3, 2022
@nlohmann nlohmann closed this as not planned Won't fix, can't repro, duplicate, stale Dec 3, 2022
@nlohmann nlohmann added this to the Release 3.11.3 milestone Jun 11, 2023
@nlohmann nlohmann reopened this Jun 11, 2023
@nlohmann nlohmann linked a pull request Jun 11, 2023 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug solution: invalid the issue is not related to the library
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants