Why do I need to get a reference of a class when including certain SFML files?

[BonBons]

Hello there! I just wondering why I have to get the reference of a class when including certain SFML files within that class and not being able to directly copy it. For an example I have some code here:

#ifndef GAME_H
#define GAME_H

#include "Window.h"
class Game
{
public:
        Game();
        ~Game();

        void handleEvents();
        void update();
        void render();

        Window* getWindow() { return &m_window; }

private:
        bool m_isRunning;
        Window m_window;
};
#endif // !GAME_H

 

#ifndef WINDOW_H
#define WINDOW_H


#include <SFML\Graphics.hpp>
#include <string>
class Window
{
public:
        Window();
        ~Window();

        void activateFullScreen();
        void deactivateFullScreen();
        void setup(const std::string& title, sf::Vector2f& windowSize);
        void destroy() { m_window.close(); }

private:
        sf::RenderWindow m_window;
        sf::Vector2f m_windowSize;
        std::string m_title;
        bool m_fullScreen;

        void create(); //Create window

};
#endif // !WINDOW_H
 

My line of thinking was because the m_window is being stored in the Game class, in theory I should of just been able to get the Window without the need of referencing but it but when attempting that it says "Attempting to reference a deleted function."

Would love for some to explain why. Thank you!

[Mortal]

because of the copy constructor is not allowed in most SFML classes.

[eXpl0it3r]

because of the copy constructor is not allowed in most SFML classes.

More like some classes.

The reason is mostly that a copy of the class doesn't make sense or is technically ambiguous. If you copy a window you end up with two "identically" windows, you pretty much never want this, plus you'll have to create another window through the OS API which also invalidates your OpenGL context and it's not exactly clear what gets "ported" over correctly.
In short, you really don't want to copy windows around.

[Mortal]

because of the copy constructor is not allowed in most SFML classes.

More like some classes.

yes, i had to look to documents http://www.sfml-dev.org/documentation/2.3.2/classsf_1_1NonCopyable.php

The reason is mostly that a copy of the class doesn't make sense or is technically ambiguous. If you copy a window you end up with two "identically" windows, you pretty much never want this, plus you'll have to create another window through the OS API which also invalidates your OpenGL context and it's not exactly clear what gets "ported" over correctly.
In short, you really don't want to copy windows around.

thanks for clarifying the side effects of copying. i'm also having terrible with sf::Window is being non-copyable
but from c++ perspective, the move constructor can do the trick. like so,

#include <utility>
struct A
{
    A() = default;
    A(A&&) = default;
    A(const A&) = delete; // disable copy constructor
};

struct B
{
    A getA()
    {
        return std::move(a);
    }
    A a;
};

int main()
{
    B b;
    A a(b.getA());
}

the above code run fine as expected without any copying invoked, but if i'm not mistaken, SFML doesn't implement it in their classes. i don't know if same effects will be applied on move constructor as copy constructor in this case?

[eXpl0it3r]

the above code run fine as expected without any copying invoked, but if i'm not mistaken, SFML doesn't implement it in their classes. i don't know if same effects will be applied on move constructor as copy constructor in this case?

Move constructors and move semantics was only introduced with C++11 which we still don't support internally (of course you can use C++11 and SFML). But if you do a std::move on the window and don't touch the moved-from object anymore, then this should work fine.