Ambiguous access of delete/new

Windows
1

Hello all,

I’m completely stumped. The following minimal code compiles on GNU:

#include "juce.h"

struct MyMainComponent : public TextEditor 
{
	MyMainComponent(){}
	~MyMainComponent(){deleteAllChildren();}
};

struct MyMainWindow : public DocumentWindow, public MenuBarModel,
	public ApplicationCommandTarget
{
	MyMainWindow(ApplicationCommandManager* cmdmanager) : 
		juce::DocumentWindow (juce::String("MyMainWindow"), 
		juce::Colours::lightgrey, 
		juce::DocumentWindow::allButtons, true)
	{
		cmdmanager->registerAllCommandsForTarget (this);
		addKeyListener(cmdmanager->getKeyMappings());
		setContentComponent(new MyMainComponent());
		setMenuBar(this);
		setVisible(true);
		centreWithSize(400, 400);
	}

	~MyMainWindow(){}

	void resized(){}
	void closeButtonPressed(){}

	const StringArray getMenuBarNames()
	{StringArray t;return t;}

	const PopupMenu getMenuForIndex(int index, const String& name)
	{PopupMenu m; return m;}

	void menuItemSelected(int menuItemID, int topLevelMenuIndex){}
	ApplicationCommandTarget* getNextCommandTarget(){return 0;}
	void getAllCommands(Array <CommandID>& commands){}
	void getCommandInfo(const CommandID commandID, ApplicationCommandInfo& result){}
	bool perform(const InvocationInfo& info){return true;}
};

struct MyApplication : public juce::JUCEApplication
{
	MyMainWindow* _mainwindow;
	ApplicationCommandManager* _commandmanager;

	MyApplication() : _mainwindow (0),	_commandmanager (0) {}
	~MyApplication(){}

	void initialise(const juce::String& commandLine)
	{
		_commandmanager = new ApplicationCommandManager();
		_mainwindow = new MyMainWindow(_commandmanager);
	}

	void shutdown()
	{
		delete _mainwindow;
		delete _commandmanager;
	}

	const juce::String getApplicationName(){return juce::String("Test");}
};

START_JUCE_APPLICATION(MyApplication)

But on Visual Studio 2005, I get the error messages:

d:\projects\mtw\gui\mtw\mtwapplication.cpp(41) : error C2385: ambiguous access of 'delete'
1>        could be the 'delete' in base 'juce::DocumentWindow'
1>        or could be the 'delete' in base 'juce::MenuBarModel'
1>        or could be the 'delete' in base 'juce::ApplicationCommandTarget'
1>        This diagnostic occurred in the compiler generated function 'void *MyMainWindow::__delDtor(unsigned int)'
1>d:\projects\mtw\gui\mtw\mtwapplication.cpp(54) : error C2385: ambiguous access of 'new'
1>        could be the 'new' in base 'juce::DocumentWindow'
1>        or could be the 'new' in base 'juce::MenuBarModel'
1>        or could be the 'new' in base 'juce::ApplicationCommandTarget'
1>d:\projects\mtw\gui\mtw\mtwapplication.cpp(54) : error C2385: ambiguous access of 'delete'
1>        could be the 'delete' in base 'juce::DocumentWindow'
1>        or could be the 'delete' in base 'juce::MenuBarModel'
1>        or could be the 'delete' in base 'juce::ApplicationCommandTarget'
1>d:\projects\mtw\gui\mtw\mtwapplication.cpp(59) : error C2385: ambiguous access of 'delete'
1>        could be the 'delete' in base 'juce::DocumentWindow'
1>        or could be the 'delete' in base 'juce::MenuBarModel'
1>        or could be the 'delete' in base 'juce::ApplicationCommandTarget'

There’s nothing out there on this kind of error, but I’m guessing it’s something to do with how I’m inheriting things. Can someone point me in the right direction?

Thank you!

2

Just add

to your class declaration. Have a look through some of the JUCE files to see how Jules has used it.

3

Thanks, Frodo! I would have spent days figuring that out.

For the record, this ain’t in the release notes, and it’s definitely a breaking change if you got caught unawares.

Also, the documentation is a bit vague and nondescript:

It should really just say to declare it in public scope (or whatever else not breaking code might be contingent on). It should also mention that it can be disabled by undefining JUCE_CHECK_MEMORY_LEAKS.

4

I wish there was some kind of assertion or cunning macro I could add that’d make this error obvious, because it’s a tough one to track down if you haven’t seen it before!

5

How about a good ole fashioned:

That would do the trick :wink:

6

Yes, but it’d annoy me and all the people who don’t need to be reminded every time they compile!

7

Well, of course, that’s what the JUCE_STOP_ANNOYING_ME macro is for :wink:

But yeah, there’s no way an assert could handle it because it causes the break at compile time, and then your options are limited it seems… Microsoft’s pragmas wouldn’t really help it looks like.

Here’s a thought… in the juce_Config do:

[code]
//Enables with message
#define JUCE_CHECK_MEMORY_LEAKS 2 //or whatever

//Enables without message
#define JUCE_CHECK_MEMORY_LEAKS[/code]

and then it would be a cinch to toggle the message using #if statements.

Of course when someone changes this, and the project has a dependency on JUCE then it might trigger an unnecessary recompile.

It’s probably moot, since now at least Google searches on the error message should pop up with this thread.