Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Why do I need to get a reference of a class when including certain SFML files?  (Read 1896 times)

0 Members and 1 Guest are viewing this topic.

BonBons

  • Newbie
  • *
  • Posts: 9
    • View Profile
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

  • Sr. Member
  • ****
  • Posts: 284
    • View Profile
because of the copy constructor is not allowed in most SFML classes.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11027
    • View Profile
    • development blog
    • Email
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Mortal

  • Sr. Member
  • ****
  • Posts: 284
    • View Profile
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?
« Last Edit: May 08, 2016, 08:51:50 pm by MORTAL »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11027
    • View Profile
    • development blog
    • Email
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/