Compiler error in juce_ScopedMessageBoxImpl.h (Windows)

General JUCE discussion
1

I’m getting this weird error on VisualStudio 2019 with Juce 7.0.9

juce_ScopedMessageBoxImpl.h, line 78	

Error E0289	no instance of constructor "std::shared_ptr<_Ty>::shared_ptr [with _Ty=juce::detail::ConcreteScopedMessageBoxImpl]" matches the argument list
argument types are: (juce::detail::ConcreteScopedMessageBoxImpl *)

Error C2664 'std::shared_ptr<juce::detail::ConcreteScopedMessageBoxImpl>::shared_ptr(std::nullptr_t) noexcept':
cannot convert argument 1 from 'juce::detail::ConcreteScopedMessageBoxImpl *' to 'std::nullptr_t'

Here’s the code (line 78 is the first line in the body):

    static std::shared_ptr<ConcreteScopedMessageBoxImpl> runAsync (std::unique_ptr<ScopedMessageBoxInterface>&& p,
                                                                   std::unique_ptr<ModalComponentManager::Callback>&& c)
    {        
        std::shared_ptr<ConcreteScopedMessageBoxImpl> result (new ConcreteScopedMessageBoxImpl(std::move(p), std::move(c)));
        result->self = result;
        result->triggerAsyncUpdate();
        return result;
    }

The project is a dynamic library that doesn’t have a UI. It includes GUI modules merely as a prerequisite for AudioProcessor, which other modules depend on.

Any ideas how to get past this road block?

2

This code obviously hasn’t been tested yet. Shared pointers can’t instantiate from a raw pointer. Here’s the fix:

std::shared_ptr<ConcreteScopedMessageBoxImpl> result = std::make_shared<ConcreteScopedMessageBoxImpl>(std::move(p), std::move(c));

There’s another instance of this error in juce_ScopedContentSharerImpl.h
(I have no idea why this didn’t happen on macOS)

3

This should be possible, according to cppreference (look at signature 3). The Microsoft docs also show this in action.

Calling make_shared here isn’t guaranteed to work on all platforms because the constructor of ConcreteScopedMessageBoxImpl is private. This is likely why plain new was used here instead.

I’m not sure what’s causing the initial error, but I don’t think the proposed fix is correct. Perhaps it’s worth checking that your Visual Studio install is up-to-date, and that your copy of JUCE doesn’t have any accidental modifications.

4

There are more compilation issues piling up here with these two classes. Concerning destructors being private (inherited from AsyncAupdater) and member variables being private.

Since it looks like the code hasn’t been reached during testing yet (at least in a DLL project on Windows), it’s probably best to run it through the compiler and fix them as they come up.

5

What’s the very first compilation error that is generated?

6

The top one in my first post is the initial error.

7

More precisely, C2664 comes up, then only after double-clicking it in the error list, E0289 is added to the top of the error list.

8

In a clean empty Projucer-created DLL project this does not come up. In my project however include_juce_gui_basics.cpp does not compile. I will report back when I found a solution.

9

Got it! The culprit is JUCE_DLL_BUILD

Here’s how to reproduce:

  • Save a Projucer project VS 2019 (dynamic library, audio processors module incl. prerequisites)
  • Enable creation of AppConfig.h
  • Add this to AppConfig.h at the beginning: #define JUCE_DLL_BUILD 1

Without the define everything is ok. And that also explains why it doesn’t occur on macOS.

10

And thanks to a comment in Slider::Pimpl here’s already the fix:

Classes ConcreteScopedMessageBoxImpl, TemporaryFilesDecorator, ConcreteScopedContentSharerImpl need to inherit public from AsyncUpdater.

Have a nice weekend :wink:

11

Bump.

The fix proposed in my last comment should maybe inlcuded with Juce. Otherwise DLL builds all fail on Windows.

1 Like
12

True I have the same issue with the newest vesrion of JUCE crazy that this has not been fixed

13

Thanks for reporting, this issue should now be fixed:

Thanks for your patience. While this was a (relatively) quick fix, it also wasn’t very high-priority because DLL builds that expose JUCE symbols are not a common use-case. JUCE doesn’t guarantee a stable binary interface, so DLL builds have limited usefulness (you can’t replace an old JUCE DLL with a new one and expect things to ‘just work’). While there may be valid use-cases for a DLL that exposes JUCE functions, I’d normally recommend to follow an approach closer to that of plugin formats. That is, expose a minimal, stable API using only C functions or COM types, keeping all JUCE types and functions completely private.

2 Likes
14

Thanks.

Actually I’m not exposing any JUCE functions directly. There’s an “extern C” API that does the job. Not sure why the DLL_BUILD option is necessary in the first place.

15

If you’ve got a C API then it indeed sounds like you probably don’t need DLL_BUILD.