[SOLVED] sf::Text application crash

[mms]

Hi,

Little help please...

The following simple example shows a reproducible crash with no compiler warnings.

1/ Example.cpp

#include <SFML/Graphics.hpp>
#include "MyClass.h"

int main()
{
    // create a graphical text
    sf::Font font;
    font.loadFromFile("c:\\windows\\fonts\\arial.ttf");
    sf::Text txt("sample text", font, 24);

    // create a MyClass object
    MyClass myObject;

    sf::RenderWindow window(sf::VideoMode(800, 600), "");
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        window.clear();
       
        window.draw(txt);                   // this works fine (if we comment out the next line)
        window.draw(myObject.objectText);   // this crashes application!
       
        window.display();
    }
}

2/ MyClass.h

#pragma once
#include <SFML/Graphics.hpp>

class MyClass
{
public:
        MyClass();
        sf::Text objectText;
};

3/ MyClass.cpp

#include "MyClass.h"

MyClass::MyClass()
{
        sf::Font font;
        font.loadFromFile("c:\\windows\\fonts\\arial.ttf");
        objectText.setFont(font);
        objectText.setString("object text");
        objectText.setCharacterSize(24);
        objectText.setPosition(25, 50);
}

Environment is VS 16.6.2 (latest), x64, SFML 2.5.1, Preprocessor SFML_STATIC, additional dependencies sfml-main.lib;sfml-graphics-s.lib;sfml-window-s.lib;sfml-system-s.lib;opengl32.lib;winmm.lib;freetype.lib;

I'm a bit fuzzy why this crashes... can you help?
Thanks!

[Hapax]

The font that you are creating in the constructor of "MyClass" is destroyed when it goes out of scope (at the end of the constructor) but the text still points to the same memory.

The font must exist as long as the text objects that use it.

[mms]

Many thanks!

The specification is very clear, indeed.

I tought that the text object would store a copy of the font, that seemed intuitive to me, for the convenience of not having to manage a separate object, and it would prevent the application crash, that in VS debugs into a misterious "Access violation reading location".
Exception thrown at 0x00007FF6020939E3 in Example.exe: 0xC0000005: Access violation reading location 0x0000000000000008.
In general, I worry about these "Access violation" problems, wondering if they could be a security concern (exploitable). Of course, they depend on a bug in the code, as always... in my case, to let the font object get out of scope. But the point is if that bug is a fairly common mistake, then we have a risk.

Anyway, I understand that was a design choice, and I'm sure for good reasons (memory... if one font and many texts; perhaps performance also for the copy).

[Hapax]

Fonts are extremely "heavy" resources along with things like images/textures and sounds.
These sorts of resources should be shared where possible so, as you mentioned, yes, one font for many texts is possible by just passing a pointer to a font. This also means that text objects themselves are rather small in comparison and can be created/destroyed/copied on the fly quite quickly. If they had fonts as part of them, this would not be possible. In fact, if texts stored fonts inside them, there would be no need for the font class at all
Copying heavy resources can be a comparatively slow process so copying fonts around is usually avoided for that reason and the reason that a text would not automaticallly point to the copy.

Often a good approach is to store all resources separately from objects and just use references or pointers to use, access and pass them around.