Author Topic: using sf::string gives an memory error when closing (Read 8842 times)

kwuuak · « **on:** April 20, 2009, 11:00:23 pm »

hi guys:)

i'm working on a project and i have a problem i dont understand

i declare a variable of the type sf::string and there appears an error message when i close the application

it says: the operation "read" couldn't be executed to the memory in "0x....."

but i just declare the variable and don't do anything else

(sorry i had to translate it on my own)

kwuuak

Laurent · « **Reply #1 on:** April 20, 2009, 11:01:39 pm »

It's a known bug.

kwuuak · « **Reply #2 on:** April 20, 2009, 11:02:33 pm »

wow you are very fast:D

is there any way to deal with??

Daazku · « **Reply #3 on:** April 21, 2009, 05:46:57 pm »

Wait until the fix is done.

Laurent · « **Reply #4 on:** April 21, 2009, 05:52:13 pm »

There are currently two workarounds:
- Use the static libraries of SFML
- Never use the default font, which means always passing a sf::Font to sf::String constructors

Daazku · « **Reply #5 on:** April 21, 2009, 06:03:31 pm »

Quote from: "Laurent"

There are currently two workarounds:
- Use the static libraries of SFML
- Never use the default font, which means always passing a sf::Font to sf::String constructors

Ho ya... those too

rpgmaker · « **Reply #6 on:** April 21, 2009, 11:47:00 pm »

or if you are using .net. Use reflection to get the default font and delete it. That works for me

kwuuak · « **Reply #7 on:** April 22, 2009, 06:56:35 pm »

thank you all guys:)

i need dynamic libraries i think, so i'll try the second possibility

Edit: Passing font to strings constructor works fine

Laurent · « **Reply #8 on:** April 22, 2009, 11:15:20 pm »

Quote

i need dynamic libraries i think

I'm just curious: why?

kwuuak · « **Reply #9 on:** April 23, 2009, 03:27:05 pm »

I created a post some time ago where you gave me the advice to use them, laurent :wink:

i 'm creating a snake clone, where i save the the piecesof the snake in a list of the stl

pushing a sf::shape ( i use sf::sprite now, but it's the same) into the list cause errors but linking dynamic libraries solves

so thanks for solving both my problems :wink:

Laurent · « **Reply #10 on:** April 23, 2009, 03:55:20 pm »

This one?
http://www.sfml-dev.org/forum/viewtopic.php?t=1123

I don't see any advice to use the dynamic libraries. And I don't see where we talk about static libraries.

kwuuak · « **Reply #11 on:** April 23, 2009, 04:58:56 pm »

yeah, i mean this treads.

i have to admit i don't know much about the using of different types of libraries and the differences, but you told me to define SFML_DYNAMIC
, which solves the problem.

Correct me if i am wrong, but i thought by defining SFML_DYNAMIC you automatically use the dynamic libraries and not the static ones.

Laurent · « **Reply #12 on:** April 23, 2009, 05:13:30 pm »

Quote

Correct me if i am wrong, but i thought by defining SFML_DYNAMIC you automatically use the dynamic libraries and not the static ones

No no. Static and dynamic build produce two different binaries ; choosing one or the other is just a matter of choosing which file to link against.
Then, you define or not SFML_DYNAMIC only to let SFML know which version you've chosen.

On Linux, only the dynamic libraries are provided by default. On Windows, both static and dynamic versions are given, the static ones have a "-s" suffix in their names.

kwuuak · « **Reply #13 on:** April 23, 2009, 06:24:08 pm »

hmm...
but for example i linked against libsfml-graphics and not against libsfml-graphics-s or libsfml-graphics-d.

Now you told to use the macro SFML_DYNAMIC and it worked.

Now i thought without any macro i link against the static ones, but by setting this macro i link against the dynamic ones, because i neither link against the static nor against the dynamic and leave this question open.

Laurent · « **Reply #14 on:** April 23, 2009, 06:58:23 pm »

Quote

Now i thought without any macro i link against the static ones

I repeat what I said: the configuration is determined by the file, not the macro.

libsfml-xxx is the dynamic/release build
libsfml-xxx-d is the dynamic/debug build
libsfml-xxx-s is the static/release build
libsfml-xxx-s-d is the dynamic/debug build

The SFML_DYNAMIC macro has to be defined when you link to either libsfml-xxx or libsfml-xxx-d, to inform SFML that you have chosen the dynamic library.

I think you were confused by the -d suffix, which is for "debug" not "dynamic"