SFML community forums
Help => Graphics => Topic started by: pdinklag on March 16, 2013, 09:39:49 am
-
I know Laurent asks for common use cases when asked to introduce new features, now I must ask this for an existing one. :D I just stumbled across sf::Font's copy costructor and can't think of any use case for it.
While copying textures and sounds can make sense, since they are "editable" using update / loadFromSamples, I can't happen to find any use for copying a font. You can't "edit" fonts or glyphs, so there's no use case like "copy that font but change that property". Any copy created would be nothing but wasted memory.
The only uses I found on the forum were a workaround to make something ugly even more ugly (talking about this post (http://en.sfml-dev.org/forums/index.php?topic=8894.msg59763#msg59763)) and awkward resource management (= wasted memory, see this post (http://en.sfml-dev.org/forums/index.php?topic=9757.msg66745#msg66745)).
So, where is the benefit of this constructor? In essence, why was it implemented?
-
To be honest, I don't remember. Maybe for consistency with other resource classes?
-
Multi-threaded applications without locking came to my mind, but is it even safe to have two instances of sf::Font, where one is the copy of the other? Because if the font has to load new glyphs, accesses to the original source (file, memory, stream) may happen concurrently...
-
The copy costructor does copy the pixel buffer, but the data source (m_streamRec?) as well as the freetype font data is not. A comment in the implementation (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Font.cpp#L84) notes that freetype does not even support such kind of cloning. The copied font simply gets the pointers to the freetype data shoved into them, so I believe any concurrency issues in reading the source data would remain.