SFML community forums

Help => Audio => Topic started by: lorence30 on November 29, 2015, 03:42:50 pm

Title: stack allocated sf::Music
Post by: lorence30 on November 29, 2015, 03:42:50 pm

why cant I allocated sf::Music on stack

heres my code:

class Track
{
   public:
       Track(const std::string&);
       const std::string& getName() const;
       const sf::Music& getAudio() const;
   private:
       std::string name;
       sf::Music audio;
};

this spits out:
error: use of deleted function 'sf::Music::Music(const sf::Music&)'
error: use of deleted function 'sf::SoundStream::SoundStream(const sf::SoundStream&)'
error: use of deleted function 'sf::Mutex::Mutex(const sf::Mutex&)'
error: 'sf::NonCopyable::NonCopyable(const sf::NonCopyable&)' is private NonCopyable(const NonCopyable&);
error: use of deleted function 'sf::InputSoundFile::InputSoundFile(const sf::InputSoundFile&)'
 error: use of deleted function 'sf::Mutex::Mutex(const sf::Mutex&)'
 class SFML_AUDIO_API Music : public SoundStream
 error: use of deleted function 'Track::Track(Track&&)'

but when i allocate it on heap like this:

class Track
{
   public:
       Track(const std::string&);
       const std::string& getName() const;
       const sf::Music& getAudio() const;
   private:
       std::string name;
       sf::Music* audio;
};

it works fine

TIA.

Title: Re: stack allocated sf::Music
Post by: eXpl0it3r on November 29, 2015, 06:41:10 pm

Since sf::Music has an sf::Mutex as member variable which is sf::NonCopyable the music object becomes non-copyable as well. This means you either have to implement a copy constructor and handle the "copying" of the music object manually, or you just don't copy your Track class.

For the SFML Team: Shouldn't we derive sf::Music from sf::NonCopyable to make it more explicit?

Title: Re: stack allocated sf::Music
Post by: Nexus on November 29, 2015, 08:30:21 pm

You can generally solve such problems by separating resources (like music) and their clients (like the "track" in your example), and let the latter reference the former.

Quote from: eXpl0it3r on November 29, 2015, 06:41:10 pm

For the SFML Team: Shouldn't we derive sf::Music from sf::NonCopyable to make it more explicit?

I think we should. There won't even be any overhead (EBO).

Title: Re: stack allocated sf::Music
Post by: lorence30 on November 30, 2015, 09:25:38 am

thanks guys


im using QT and SFML audio , i was trying to inherit sf::Music to my Track class and just add a feature for std::string name so i can keep track of the name of the song, so if the user double clicks the song i will just find the name matches with the name being clicked then play the Track::audio

Title: Re: stack allocated sf::Music
Post by: Nexus on November 30, 2015, 10:46:59 am

You shouldn't use inheritance for this purpose, most of the SFML classes are not designed as a base class. Just use composition.

Title: Re: stack allocated sf::Music
Post by: Hapax on November 30, 2015, 05:28:44 pm

Quote from: lorence30 on November 30, 2015, 09:25:38 am

i was trying to inherit sf::Music to my Track class and just add a feature for std::string name so i can keep track of the name of the song

I think using the word "inherit" here is incorrect. It's probably a genuine language mistake.
It looks like you're writing a "wrapper" class that includes the music object and also extra information.
"Inheritance", though, would look something like this (DO NOT TRY THIS!): class Track : public sf::Music