New SVN Version

[T.T.H.]

...and throw a message on the standard error output.

And how to read that message e.x. in a windowed application under Windows or e.x. in a "daemonised" application under Linux, both having no obvious "stdout" or "stderr"? Or how to know the reason for an error when a function hidden deep in the inner workings of SFML just saying "uops, didn't work"?

To be honest it took me some serious amount of time at my initial steps with SFML to get things done correctly when something obviously didn't work and the error message had only been dumped to stdout. To actually have access to those error messages I wrote a pretty complex logging system which "bends" stdout over to some std::stream which then puts its input in a list of strings stored in a logging system singleton which then can output its content to several defined outputs, e.x. the GUI of my application or a log file or even back to console if I have one.

In addition some errors can get pretty much "spamming" in an application "doing something wrong every frame, 250 frames a second"  :lol:


Anyway. Personally I work with exceptions since I like them but if you don't use exceptions that's perfectly fine, too. But simply outputting errors to stdout is far less than optimal in my opinion, due to the types of applications named above and due to beginners not being able to recognize errors which are not slapped directly into their face (and, yes, I was a beginner with SFML, too).

[Laurent]

Outputing to the standard error stream is very flexible, it let users redirect it to wherever they need very easily, just as you do. I don't see the problem with that ?

Regarding spamming messages, I try to remove them as possible. If you still get some of them let me know

Anyway, this is purely for information and debugging, the true error reporting is the boolean return of functions which can fail. If you want to discuss error handling then it should be about this, and not about messages

[T.T.H.]

Outputing to the standard error stream is very flexible, it let users redirect it to wherever they need very easily, just as you do. I don't see the problem with that ?

It might be "flexible" but it is not "beginner friendly"; in my humble opinion.

On the other hand I found freopen() after a short Google search...

Regarding spamming messages, I try to remove them as possible. If you still get some of them let me know

Will do.

Anyway, this is purely for information and debugging, the true error reporting is the boolean return of functions which can fail. If you want to discuss error handling then it should be about this, and not about messages

I remember that when I started SFML (a bit before version 1.2) I had an occasion where I called a function returning void or called a constructor which called several functions internally and finally outputted some error message to stdout - and there was no way to determine whether it went right or wrong based on return values. Unfortunately I can't remember which function or constructor that was, sorry.

At that time I didn't want to start a discussion about error handling since I was pretty new to SFML and feared I could not have the "big picture" yet.

Meanwhile I can't start that discussion, too,  since my spare time is limited and when I code I do that mostly on the server part of my application, not the client part which uses SFML - and so I'm not sure what you changed lately. I'm currently using revision 651 from 4. Mai 2008 and I don't intend to update soon because that version simply does what I want and I have made my own changes to it (due to my sub pixel accuracy problem I posted here).

P.S.: sorry for going offtopic...

[Laurent]

t might be "flexible" but it is not "beginner friendly"; in my humble opinion.

On the other hand I found freopen() after a short Google search...

It's even simpler with standard C++ streams :

Code: [Select]

std::cerr.rdbuf(TargetStream.rdbuf(());
Where TargetStream is any kind of standard stream : ofstream for a file, ostringstream for a string, custom ostream for whatever, ...

I remember that when I started SFML (a bit before version 1.2) I had an occasion where I called a function returning void or called a constructor which called several functions internally and finally outputted some error message to stdout - and there was no way to determine whether it went right or wrong based on return values. Unfortunately I can't remember which function or constructor that was, sorry.

All these functions should have been fixed now

[Nexus]

Concerning the inconsistences, I found some points:

sf::Sprite:
- the method to get the size on the screen is GetSize().

sf::String:
- the method to get the rectangle (and the size about it) is GetRect().
- but GetSize() returns the font size.

I think this is a little bit confusing. For me, both classes are quite similar, so why once using a Rectangle and once a 2D-Vector?
And another thing is the base class sf::Drawable. I think, there is no GetSize() method because of inherited sf::Shape and sf::PostFX, right? I don't use those 2 classes often, but don't they require a size? If yes, would make polymorphism easier (for example you don't have to overload specific functions for sf::Sprite and sf::String)...

And what I is also not really consistent, is GetSize() vs. GetWidth() or GetHeight() methods. For example Sprites use GetSize().x or GetSize().y, and the "greater" classes like sf::Image or sf::RenderWindow use GetWidth() or GetHeight(). And why did you implement sf::View::GetHalfSize()? Is that for people who don't want to write sf::View::GetRect()::GetWidth()/2?  Or because of 2D-Vector (now there's again the question why a Rectangle with 2 specific size methods).

What's the reason for these things? They might follow a simple logic, but at the moment I don't really see it

[Laurent]

Cleaning all this stuff is my next task, actually

[Nexus]

Cleaning all this stuff is my next task, actually

Oh, so there wasn't any intention behind those names?

[Laurent]

No, I even agree 100% that these functions are confusing and everything but consistent

In fact, when I implemented each of them (at different times) it was just a local feature of each class, I didn't have in mind to get a generic behaviour for geometry testing and collision tests. Now I realize that I need to get a little more abstraction and consistency on this side.

[Nexus]

Yes, I can completely understand that. I think it's quite normal to write working code first, and care about things like name consistency later.
I just didnt know, maybe there could have been a special reason for those identifiers.