SFML community forums

Help => Audio => Topic started by: iride on November 09, 2012, 10:54:03 pm

Title: sf::Music trying to solve non-copy problem with "move"
Post by: iride on November 09, 2012, 10:54:03 pm
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 &)'
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: Laurent on November 09, 2012, 11:00:53 pm
Your std::move has no effect, there's still a copy (resourceMap[name]=...).

You have to use pointers.
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: iride on November 10, 2012, 01:12:17 am
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?
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: cire on November 10, 2012, 01:57:22 am
std::move on an object that doesn't implement a move constructor or move assignment operator (like sf::Music) simply has no effect.
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: iride on November 10, 2012, 02:14:35 am
Laurent, Can move assignment operator and constructor implemented for sf::NonCopyable?
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: FRex on November 10, 2012, 02:32:02 am
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.
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: iride on November 10, 2012, 03:07:08 am
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
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: FRex on November 10, 2012, 03:10:42 am
That is already planned by Laurent unless he forgotten he said that:
Quote from: Laurent
SFML is currently C++03, and will have conditional support for C++11.
Probably not a high priority and will be ready
Quote from: Laurent
when it's done.
As will anything SFMl related..
Sorry, I was too stupid to think of conditional compilation for 0x...
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: Laurent on November 10, 2012, 09:38:55 am
Quote
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.
Title: Re: sf::Music trying to solve non-copy problem with "move"
Post by: Nexus on November 10, 2012, 10:08:08 am
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.