OSX: GetFrameTime() causes SIGABRT signal

[seb.dd]

GetFrameTime() causes a SIGABRT signal after Close() was called on the render window.
the signal is recieved at the return of test() and kind of crashes the application.

Code: [Select]


int test()
{
// Create the main window
sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SIGABRT");
App.PreserveOpenGLStates(true);

// Start main loop
while (App.IsOpened())
{
// Process events
sf::Event Event;
while (App.GetEvent(Event))
{
            if (Event.Type == sf::Event::Closed) App.Close();
}

App.Clear();

// fps
char buffer[16];
int fps = 100;
fps = int(1.f / App.GetFrameTime()); // this causes the signal
sprintf(buffer, "fps = %d", fps);
App.Draw(sf::String(buffer));

App.Display();
}

return EXIT_SUCCESS;
}

int main()
{
return test();
}


[seb.dd]

oh no, i got a feeling GetFrameTime() just returns zero after window was closed...

edit:
yes it does. if this behaviour was intended the documentation should point it out.

[Hiura]

Tips :
In C++ don't use char array but std::string.

in C++ don't use sprintf, printf or any C function. If you want to display some text then use std::cout.

If you want to convert a type T into a string use some stringstream. (See FAQ)

In C++ avoid using C-cast style ( for example (int)(var) ) : use static_cast<T> instead.

Read some FAQ for more details.

[Laurent]

oh no, i got a feeling GetFrameTime() just returns zero after window was closed...

edit:
yes it does. if this behaviour was intended the documentation should point it out.

It doesn't
GetFrameTime() simply returns the time elapsed between two calls to Display(), it doesn't care about the window being opened or not. I tested it and couldn't get 0 even after the window is closed.

[seb.dd]

I tested it and couldn't get 0 even after the window is closed.

i tested it again and you're right. the zero is thrown right after program start. though the signal is recieved at return of test(). i changed the fps code to this:

Code: [Select]


// fps
char buffer[16];
int fps = 100;
float time = App.GetFrameTime();
if (time != 0.f) fps = int(1.f / time);
else printf("zero!\n");
sprintf(buffer, "fps = %d", fps);
App.Draw(sf::String(buffer));

i get the "zero!" right after program start.
but the signal on closing the window is avoided by "if (time != 0.f)"
?

@ Hiura: thanx for tips. do you mean those commands may cause the signal? i assumed that old c-libraries are assimilated by c++ and that for instance "#include <cmath>" would be standard c++.

[Ceylo]

but the signal on closing the window is avoided by "if (time != 0.f)"
?

You should not compare floating values in this way. == and != are not safe with floats, for example you could get something like 0.0000f != 0.0000f without knowing why. This is due to the lack of precision.

Instead, use intervals or <,> comparators. Here you could use time > 0.f.

[seb.dd]

Instead, use intervals or <,> comparators. Here you could use time > 0.f.

so i improved the comparison: "if (time > 0.f || time < 0.f)"
but it changes nothing.

[Hiura]

@ Hiura: thanx for tips. do you mean those commands may cause the signal? i assumed that old c-libraries are assimilated by c++ and that for instance "#include <cmath>" would be standard c++.

If you use them right you won't get any crash with them (and here you're using them right). And yes, cmath is in the standard. BUT in C++ we rather prefer C++ functions because they are :
-> easier to use,
-> sometimes faster,
-> easier to use (yes, again),
-> you can do more things with them.
-> ...

My point of view is : if one wants to do C++ then he should do it without C functions and use only C++ ones because one would prefer use all C++ power.

--

As the time cannot be negative you can (maybe should) do if (time > 0.f) only.

[Laurent]

You should not compare floating values in this way. == and != are not safe with floats, for example you could get something like 0.0000f != 0.0000f without knowing why.

This is not true in this case. Only a true 0 will lead to an error, dividing by 0.0000001 will produce a valid number for example. So using == is perfectly correct here.

Instead, use intervals or <,> comparators. Here you could use time > 0.f.

Using > instead of == doesn't change anything, you must introduce a small epsilon value like this

Code: [Select]

if (abs(f) < 1E-5f)
{
    ...
}

[Nexus]

My point of view is : if one wants to do C++ then he should do it without C functions and use only C++ ones because one would prefer use all C++ power.

I don't think so. The power of C++ results from the multiple paradigms the language supports. Procedural programming and the compatibility to C (and therefore the connection to low-level algorithms) is an important part of C++.

I widely agree, what concerns the functions like printf(), sscanf(), malloc() and similar ones. They have got a lot of problems, and in most cases (not all!), there are better alternatives in C++.

But functions from headers like <cmath>, <ctime> or <cassert> are okay. I don't think that the dogma "C is evil" is a good argument to fundamentally avoid them. Remember: C++ brought nothing new related to the functionality in <cmath> and <ctime>. So you would have to take external libraries into account, just to carry out your questionable principle.

[Laurent]

Well, I think he meant "don't use a C function when an equivalent exists in the C++ SL". <cmath> and <ctime> are both part of the C++ SL, actually. Their contents are not different than the C version but it's because there's no need to do so for this part of the SL.

[Nexus]

Yes, I can imagine he didn't mean it that absolute.

I just don't like wide generalizations of statements, which may even be very legitimate for specific cases. People, who haven't got a lot of experience, will believe such things and possibly, they won't think about them anymore. This eventually leads to propaganda like "OOP, especially virtual functions, is slow", "C is dangerous and evil", "use const wherever possible" and so on.

And that's bad because those people often point out to program worse while they attempt to satisfy their narrow-minded conventions.

I think you understand me.

[Laurent]

Absolutely

[Hiura]

My point of view is : if one wants to do C++ then he should do it without C functions and use only C++ ones because one would prefer use all C++ power.

I don't think so. The power of C++ results from the multiple paradigms the language supports. Procedural programming and the compatibility to C (and therefore the connection to low-level algorithms) is an important part of C++.

I agree with you but I've never spoken about procedural or object coding style.(*) I'm just pointing out that C functions are not the best choices with C++ (you need to be carful about more things so you have potentialy more probability to make a mistake, blablabla).

(*) If you think using std::string make always your application not procedural that's another point.

I don't see in what I say that may be wrong. Explain it to me; I'd like to fully understand your point of view.

[Nexus]

I agree with you but I've never spoken about procedural or object coding style.

That's right, I just wanted to show that some things C++ inherited from C are really useful (as an example that C++ power doesn't only consist of new C++ elements).

I'm just pointing out that C functions are not the best choices with C++ (you need to be carful about more things so you have potentialy more probability to make a mistake, blablabla).

Yes, that's what I confirmed with my sentence "I widely agree...".

I don't see in what I say that may be wrong. Explain it to me; I'd like to fully understand your point of view.

I don't like the generalizing way you said it. My view is further explained three posts above. Don't misconceive it; I don't intend to blame you. But I'd like it if people took a little bit more care of statements that are likely to be misunderstood.