sf Variable declaration outside the main

[jimboTL60]

Hi,

When I declare my image and sprite variables outside of the main function, any access to the sprites crashes the program, but it works fine if the variables are declared inside the main. Why is it that way and what if I really need global stuff?

This doesn't affect myimage.LoadFromFile(myfilename). I also can declare my sf::Event variables outside without problem.

Edit: I get the same crashing problem with rendering windows declared outside the main.

[Laurent]

SFML use global initializers, so it's never safe to use SFML objects outside the main function.

However there are only a few cases that won't work, can you show me your code? What kind of crash did you get? Did you try using the debugger? Which version of SFML are you using?

what if I really need global stuff?

You never need global stuff

[jimboTL60]

I'm using SFML version 1.5. I don't use the debugger since I've always debugged my code oldschool, with console prints, thinking and research. Does a debugger tell where in SFML it crashed? Because in my program I know exactly where.

My code: pratically the same as the examples; change the names and declare the vars before the main. That's all. I tried to declare them dynamically using new, not much of a success. (Actually, it worked a few times then started crashing back again... probably a [dynamic] memory allocation problem)

The crash: well a crash is a crash ... it hangs and Windows "tries" to understand why. Then I copy-paste the declarations into the main and it works again. As I said in the preceding post, no probs with Images yet, just sprites and windows, but if I declare the Images outside, the sprites don't like them.

[Laurent]

I'm using SFML version 1.5

If you can, you should try the sfml2 branch from the SVN repository.

I'm using SFML version 1.5. I don't use the debugger since I've always debugged my code oldschool, with console prints, thinking and research. Does a debugger tell where in SFML it crashed?

Sure it does, if you use the debug SFML libraries. And it does many more things automatically (show the context, the call stack, put conditional breakpoints, ...). You should really try "new-school" debugging

The crash: well a crash is a crash ...

Well, the error message is important. And if you run the debugger you can report many more informations about the crash.

[jimboTL60]

If you can, you should try the sfml2 branch from the SVN repository.

Alright, I just downloaded it. I'll update the appropriate file tomorrow.

Sure it does, if you use the debug SFML libraries. And it does many more things automatically (show the context, the call stack, put conditional breakpoints, ...). You should really try "new-school" debugging

Well, from what you tell me, new-school debugging implies debugging SFML ...  :roll:  anyways, how do I proceed?

Well, the error message is important. And if you run the debugger you can report many more informations about the crash.

There's no error message. It just crashes. And it does because my sf objects are declared outside of the main, when I try to access their functions, like sprite.SetImage or window.Create. Sometimes it works, sometimes it doesn't, sometimes partially. It's like lotto, and it's a symptom of bad memory allocation [by the sfml classes].

My only solution for now is to share objects by passing them to my functions by reference, but it's no garantee. God I miss my good old FBgfx ... never let me down.  :wink: [/quote]

[Laurent]

how do I proceed?

It depends which debugger you use

[jimboTL60]

I use what comes with CodeBlocks. I guess there's some tutorial somewhere. Looks like what we used with VB in high school. What about the debug SFML libraries?

[Laurent]

What about the debug SFML libraries?

What do you mean?

[Nexus]

There's no error message. It just crashes.

You mean, the program suddenly ends without anything? How can you recognize it as a crash then?

And it does because my sf objects are declared outside of the main, when I try to access their functions, like sprite.SetImage or window.Create. Sometimes it works, sometimes it doesn't, sometimes partially. It's like lotto, and it's a symptom of bad memory allocation [by the sfml classes].

I guess, it's rather your fault.
Can you show some short code which reproduces the mentioned behaviour?

[jimboTL60]

I already said it, it ends at a certain point, in a call to the sf objects, and Windows tells me it crashed. And I don't have this problem with OpenAl.

Code: [Select]

// If I declare this inside the main it never crashes, array or not
// Dynamic allocation sometimes works, sometimes not.
sf::Image IMG_PianoB[3][3];
sf::Image IMG_PianoN[3];
sf::Sprite SPR_PianoB[3][3], SPR_PianoN[3];

int main()
{

[...]
// Exemple of dynamic allocation
sf::RenderWindow * Interface;
Interface = new sf::RenderWindow;

// CHARGEMENT DES IMAGES ET ALLOCATION DANS DES SPRITES
//// Piano
if (!IMG_PianoB[0][0].LoadFromFile("IMAGES/PianoB0A.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoB[0][1].LoadFromFile("IMAGES/PianoB1A.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoB[0][2].LoadFromFile("IMAGES/PianoB2A.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoB[1][0].LoadFromFile("IMAGES/PianoB0B.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoB[1][1].LoadFromFile("IMAGES/PianoB1B.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoB[1][2].LoadFromFile("IMAGES/PianoB2B.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoN[0].LoadFromFile("IMAGES/PianoN0.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoN[1].LoadFromFile("IMAGES/PianoN1.tga"))
    return EXIT_FAILURE;
if (!IMG_PianoN[2].LoadFromFile("IMAGES/PianoN2.tga"))
    return EXIT_FAILURE;

// This tends to crash when Images are declared outside the main
    SPR_PianoB[0][0].SetImage(IMG_PianoB[0][0]);
    SPR_PianoB[0][1].SetImage(IMG_PianoB[0][1]);
    SPR_PianoB[0][2].SetImage(IMG_PianoB[0][2]);
    SPR_PianoB[1][0].SetImage(IMG_PianoB[1][0]);
    SPR_PianoB[1][1].SetImage(IMG_PianoB[1][1]);
    SPR_PianoB[1][2].SetImage(IMG_PianoB[1][2]);
    SPR_PianoN[0].SetImage(IMG_PianoN[0]);
    SPR_PianoN[1].SetImage(IMG_PianoN[1]);
    SPR_PianoN[2].SetImage(IMG_PianoN[2]);

// Same here if Interface is declared outside, random results
    (*Interface).Create(VideoModes[0], "QUANTON AUDIO", sf::Style::Fullscreen);
    (*Interface).Clear();
    (*Interface).Draw(SPR_PianoB[0][0]);
    (*Interface).Display();

[...]

EXIT RETURN_SUCCESS;
}

I really don't know what else I could tell you.

Edit: And I know exactly where in my code it stops because I usually add
std::cout << "What it's about to do" << std::endl;

[jimboTL60]

What about the debug SFML libraries?

What do you mean?

I mean what are they, how do I use them.

[Laurent]

Link to the libraries with a -d suffix (sfml-system-d, sfml-window-d, etc.)

[jimboTL60]

Ok, here's what I learned about the problem:

These sf objects I declare as Globals contain dynamically allocated memory, because they use Vectors for pixels, which is a good thing.

But Globals are stored in the Data segment while the Heap segment contains the dynamically allocated variables.

I think that might cause the crash when my Global objects are initialized and the constructors called.

It's hard to be certain about how exactly it occurs, but using globals seems a pretty bad idea anyways, especially with dynamic memory allocation.

Here's an article:
http://bytes.com/topic/c/insights/737451-case-against-global-variables

I think I've spent enough time on this, I might move on with my project

Thanks anyway!