sf::Music trying to solve non-copy problem with "move"

[iride]

I'm making a music resource manager class and I'm storing sf::Music in a unordered_map

std::unordered_map<std::string, std::pair<int, sf::Music>> resourceMap;

And it seems that I must use a reference or a smart pointer to store the music because of non-copyable
But instead of using this, I tried to get around with using move constructor...

resourceMap[name]=std::make_pair(1, std::move(sf::Music())); //Create the resource using "move"
                resourceMap[name].second.openFromFile(name); //load the resource
                std::cout<<"Loading "<<name<<" for the first time\n";

But it doesn't work
Errors I get...
1>c:\users\park\desktop\my sdks\include\sfml\system\mutex.hpp(89): error C2248: 'sf::NonCopyable::operator =' : cannot access private member declared in class 'sf::NonCopyable'
1>          c:\users\park\desktop\my sdks\include\sfml\system\noncopyable.hpp(79) : see declaration of 'sf::NonCopyable::operator ='
1>          c:\users\park\desktop\my sdks\include\sfml\system\noncopyable.hpp(42) : see declaration of 'sf::NonCopyable'
1>          This diagnostic occurred in the compiler generated function 'sf::Mutex &sf::Mutex::operator =(const sf::Mutex &)'

[Laurent]

Your std::move has no effect, there's still a copy (resourceMap[name]=...).

You have to use pointers.

[iride]

Your std::move has no effect, there's still a copy (resourceMap[name]=...).

You have to use pointers.

Shouldn't it invoke unordered_maps' move assignment operator because I called std::make_pair and std::move?

[cire]

std::move on an object that doesn't implement a move constructor or move assignment operator (like sf::Music) simply has no effect.

[iride]

Laurent, Can move assignment operator and constructor implemented for sf::NonCopyable?

[FRex]

I really hope not. 
That'd throw support for any compiler pre-0x out the window, which is bad.
Use a pointer or implement move in NonCopyable yourself if you need it that much, zlib license permits that.

[iride]

I really hope not. 
That'd throw support for any compiler pre-0x out the window, which is bad.
Use a pointer or implement move in NonCopyable yourself if you need it that much, zlib license permits that.

  Sorry, I thought it was something that can be conditionally compiled

[FRex]

That is already planned by Laurent unless he forgotten he said that:

SFML is currently C++03, and will have conditional support for C++11.

Probably not a high priority and will be ready

when it's done.

As will anything SFMl related..
Sorry, I was too stupid to think of conditional compilation for 0x...

[Laurent]

Shouldn't it invoke unordered_maps' move assignment operator because I called std::make_pair and std::move?

You try to move the sf::Music instance to construct the pair. But then the pair is assigned to the map element with operator=, so there's still a copy there.

And yes, sf::Music is not movable anyway.

[Nexus]

A simple solution is to wrap the sf::Music inside a std::unique_ptr. It has not more overhead than a raw pointer, but handles memory automatically, and is movable.