Messages

1

General / Using the stack or the heap for SFML objects

« on: April 12, 2013, 12:25:44 am »

All the example code I've seen for SFML creates objects such as textures and sprites as follows:

Code: [Select]

sf::Texture texture;
texture.loadFromFile("texture.png"))
sf::Sprite sprite;
sprite.setTexture(texture);

I don't see the new keyword anywhere here, so I'm assuming this means the objects are created on the stack, and not on the heap? Surely this is a bad idea, since with a decent size codebase you'll eventually exceed the stack size and get stack overflow issues?

So my question is this: should I create new objects on the heap or on the stack? Or is SFML internally managing memory allocation in such a way that the stack isn't actually used?

2

General / Re: Static Linking for SFML 2.0 RC on Linux

« on: April 04, 2013, 11:20:45 pm »

There's nothing wrong with static linking, but it's simply not the "linux way", and using the system shared libraries (installed from your distribution packages) is regarded as a better practice.

Fair enough, but I'm only really interested in statically linking the SFML libraries, not all of its dependencies. Besides, I don't see SFML 2.0 in the Ubuntu repos yet, so I'd have to bundle the SFML shared object files with my project anyway.

Libraries are usually built for shared linking, so if you intend to static link, you'll probably have to compile them yourself, which can be a serious pain.

Good point. Although I've managed to compile and use the SFML shared libraries without much trouble, I haven't had any luck getting the static libraries to work. During the linking of my own project with the SFML libraries, I'm presented with undefined references to pthread_getspecific. Could this be a bug somewhere in SFML, or is it more likely that there's something wrong on my side? I fairly certain that I do have the correct development headers package installed, besides, it's only the static libraries that are giving problems, not the shared libraries.

Yes, this is very easy and seems to be the more popular way for distributing stand-alone release of your project.
Just copy the .so files to a sub directory, and provide a shell launcher.
You can see an example of mine here.

Great, thank you

3

General / Re: Static Linking for SFML 2.0 RC on Linux

« on: April 02, 2013, 04:12:51 pm »

Ah, fantastic, thank you!

Why would you say it's impractical to link statically? Surely dynamic linking is just another thing that could go wrong when distributing the binary? A separate run script needs to be created to first export the LD_LIBRARY_PATH variable before executing the binary, or is there another way?

4

General / Static Linking for SFML 2.0 RC on Linux

« on: April 02, 2013, 03:35:31 pm »

I'm running 64-bit Ubuntu, and I've managed to get my code to compile and run, but only by dynamically linking against the SFML libraries at runtime (by setting the environmental variable LD_LIBRARY_PATH to my SFML lib directory).

However, I'd like to statically link SFML into my application, which is where I'm running into problems. I get the following errors:

Code: [Select]

/usr/bin/ld: cannot find -lsfml-graphics-s
/usr/bin/ld: cannot find -lsfml-window-s
/usr/bin/ld: cannot find -lsfml-system-s
However, if I leave off the -s suffix, I don't have any problems, but I then need to set the LD_LIBRARY_PATH variable at runtime, which is what I'm trying to avoid. So how do I link the SFML libraries into my application statically? I've looked into my SFML lib directory, and I don't see and libraries matching the -s suffix. Does this mean that the current version of SFML 2.0 RC does not come with static libraries? Or do static linking and dynamic linking use the same libraries, and I'm just missing something obvious?

The version of SFML I'm using is the C++ version 2.0 RC available from this link on the downloads page.