lager: MSVC: C2440 compiler error merging deps

In deps.hpp, we see this method starting at line 399

    template <typename... Ds>
    auto merge(deps<Ds...> other)
    {
        return boost::hana::unpack(
            boost::hana::union_(spec_map, deps<Ds...>::spec_map),
            [&](auto... ts) {
                using deps_t =
                    deps<std::decay_t<decltype(boost::hana::second(ts))>...>;
                return deps_t{*this, std::move(other)};
            });
    }

building with MSVC 2019 16.11.3, return deps_t{*this, std::move(other)}; causes the error message

C2440	'<function-style-cast>': cannot convert from 'initializer list' to 'deps_t'

with this hint in the log

2> message : No constructor could take the source type, or constructor overload resolution was ambiguous

same code compiles and runs good on AppleClang.

I’m not very familiar with boost::hana so some tips to troubleshoot would be appreciated. It seems that perhaps deps_t is not ending up as the expected type?

This error is encountered with any number of deps greater than 0

About this issue

Original URL
State: open
Created 3 years ago
Comments: 23 (14 by maintainers)

Most upvoted comments

Or, if you are staying in the msvc compiler realm, be sure that the /permissive- compiler option is turned on which enables proper standards conformance. Apparently it is normally turned on, but I am using the JUCE framework’s Projucer to launch Visual Studio and it does not turn that setting on. Until I had found and enabled that setting, I had all kinds of additional problems besides the ones described in this thread. But with it turned on I was able to follow the suggestions from this thread to successfully compile in msvc.

All that said, I’m preferring clang because it just happily builds lager as-is with no source modifications. It also builds significantly faster than msvc in my experience.

bobkocisko on Apr 28, 2023

In case anyone else is interested in a workaround which is resolving all the build issues for me in Visual Studio: install “C++ Clang tools for Windows” in the vs installer and then switch the Platform Toolset in the project properties to “LLVM (clang-cl)”. So far I haven’t encountered any downsides to this. As far as I understand, it’s still building a native windows app, linked against the windows runtime libraries, but compiling with clang.

bobkocisko on Apr 28, 2023

I don’t really have a way to try MSVC, but I’d be happy to accept a fix from any of you @kevin-- @timpatt

arximboldi on Nov 21, 2022

My pleasure! Thanks for such an amazing set of libraries! We’re about to head into a long weekend here but will look at raising a PR mid-next week…

timpatt on Oct 27, 2022

I’ve seen some of the same issues on Visual Studio 2019 v16.10.3:

auto merge(deps<Ds...> other) - this can be fixed by adding #define LAGER_DISABLE_STORE_DEPENDENCY_CHECKS. VS seems to hide the required constuctor because the associated std::enable_if doesn’t get evaluated correctly. This define should probably be set whenever we’re using the msvc compiler. I suspect it is currently set for CMake-based lager installs (in the CMake script), but it might be worthwhile considering conditionally setting it by default (for VS compiler) in the config.hpp so that just copying the lager headers into your project works correctly.
“ctx” not being found seems to be a bug with VS evaluating the declspec(eff(ctx)) in the nested lambdas in store_node::dispatch. The fix is to simply add auto& ctxVisualStudioWorkaround = ctx and use declspec(eff(ctxVisualStudioWorkaround)) instead.

timpatt on Oct 24, 2022

I am also using MSVC 2022 and wanted to try lager, but it seems it does not build anymore.

Is anyone still using MSVC and also interested in fixing this?

menzels on May 24, 2022