Messages

76

Feature requests / sf::Vector2 Empty value

« on: October 05, 2011, 06:39:04 pm »

Still Vector.Zero would be useful to not create unnecessary objects as zero vectors are pretty common.

Unless you mean to takes its address, you'll be creating objects anyway (which if you need them at all, are clearly not "unnecessary").

Edit: Not that I'm particularly against the proposal.

77

General discussions / The new graphics API in SFML 2

« on: October 05, 2011, 05:18:06 pm »

I wont be putting much effort into arguing for QuadList et al, since I share your concern over the possible annoyance of static typing there. I suppose people who really care about such things can write some sort of QuadView structure over a VertexArray or similar.

78

General discussions / The new graphics API in SFML 2

« on: October 05, 2011, 04:12:22 pm »

-1 for "Mesh". In English, the word "Mesh" cannot in any sense represent the notion of a list containing discrete (non-mesh forming) geometry (e.g. a list of quads).

Correct. But I was thiking it would be ok, because 95% of meshes would truly be meshes;

Then perhaps you would prefer 'MeshMostlyExceptWhenItsNot'

I don't like VertexArray, it's more an array of primitives (unlike OpenGL, the primitive type is an attribute of the class, it's not given at draw time). However it acts like an array of vertices (operator[] returns a vertex), so... I don't know.
What about sf::Geometry, or sf::Primitives? I guess they are bad too, because of the "array of vertices" semantics.

That would seem to argue in favour of QuadList, TriangleList etc. I'd also like to point out the amount of times you quite naturally used the word "vertex" there

-1 for "Point". I personally predict that users seeing the name "Vertex" along with a brief description of what that means, will be less confused than a seeing a "Point" class/struct containing all manner of data members which are completely unrelated to the notion of a position in space.

It is a position in space, with some extra data attached to it.

No. It is a vertex which has a position in space. For instance, it wouldn't be unheard of to see something like:

Code: [Select]


struct Point
{
    float x;
    float y;
};

struct Vertex
{
    Point position;
    // ...
};


+1 for VertexArray (and/or possibly even QuadList, TriangleList .etc with the appropriate interface)

I tried this approach before, but these classes would have to return a Quad/Triangle with their operator[], which is not very convenient.

I had actually thought it would have been more convenient. It would certainly make the tile-sheet code you presented earlier a lot more readable. I'm not at all attached to those structures, but I wonder what exactly you thought would be the inconvenience? dealing structure padding or?

79

General discussions / The new graphics API in SFML 2

« on: October 05, 2011, 03:24:47 am »

-1 for "Mesh". In English, the word "Mesh" cannot in any sense represent the notion of a list containing discrete (non-mesh forming) geometry (e.g. a list of quads).

-1 for "Point". I personally predict that users seeing the name "Vertex" along with a brief description of what that means, will be less confused than a seeing a "Point" class/struct containing all manner of data members which are completely unrelated to the notion of a position in space.

+1 for VertexArray (and/or possibly even QuadList, TriangleList .etc with the appropriate interface)

+1 for Vertex.

80

General discussions / Origin at bottom left (SFML2!?)

« on: October 05, 2011, 03:00:33 am »

What kind of use case can you find for mirrored views

Mirrors :lol:

+1

My current project is based on the concept of a mirrored world. Currently, the world is drawn onto a RenderImage which is then drawn onto the window via an axis-flipped Sprite.

81

Feature requests / Request: Exceptionhandling?

« on: July 09, 2011, 06:57:18 pm »

Unfortunately not. There was a series written by one of the library's authors, but it seems his site is currently down.

There are various links to documentation available, though:
VC2010: http://msdn.microsoft.com/en-us/library/ee372183.aspx
Boost.System (the library's original seed): http://www.boost.org/doc/libs/1_46_1/libs/system/doc/index.html

82

Feature requests / Request: Exceptionhandling?

« on: July 09, 2011, 05:33:34 pm »

I haven't worked with the error codes in Boost.Filesystem yet, so I can't really judge it. How do they solve the problem of failing constructors?.

I just had a look through its source, and in fact they don't. For some reason the documentation doesn't have an exception specification on the 'path' constructor, but it can throw if character conversion fails.

Just to reiterate, I don't disagree that exceptions are the One True Way to report errors from constructors, except when they're not: a type that has a legitimate intermediate state, or where failure is expected to occur during normal execution. Examples would include std::iostream construction, where opening the file may fail, or std::shared_ptr being constructed from a null pointer.

Also take into account that SFML has other aims and another target group than Boost, for example it tries to be beginner-friendly and to have a clean API without much redundance, while Boost libraries often intend to be as generic and configurable as possible.

Error codes are hardly rocket science, and they will have to learn them sooner or later anyway, since they are soon to be standardised.

By the way, thanks for the explanation, I didn't know about the integration of error codes into C++11.

You're quite welcome.

And in all this, nobody thought to mention that in fact SFML already uses exceptions. sf::Shape::AddPoint, for instance, will throw an std::bad_alloc exception on memory exhaustion.

83

Feature requests / Request: Exceptionhandling?

« on: July 09, 2011, 03:48:58 pm »

Attempts to make everyone happy are the keystone of every bad design. I don't consider the duality a good practice to apply in general. An exception doesn't exist if it can be replaced by a bool flag in every case.

Just consider a constructor that might fail. An exception is a good way to abort it. On the other side, providing an additional error checking mechanism implies the existence of a zombie object state. We introduce again the disadvantages we wanted to avoid by using exceptions.

I don't actually disagree with that, but there is a problem here, and Boost.Filesystem has a reasonable answer, or are you also suggesting that Boost.Filesystem is badly designed?

Note also that this technique is going to become standard practice in the next C++ version.

Can you explain this?

Sure.

The error handling facilities from Boost.System, used in both Boost.Filesystem and Boost.Asio to provide the exact interface we are discussing, have been incorporated into the C++11 FDIS. Both Boost.Filesystem and Boost.Asio are expected to the incorporated into the next C++ standard. Once they become standard, I would also expect to see more libraries use the same, already standardised, error handling facilities (i.e. both exceptions and error-codes).

84

Feature requests / Request: Exceptionhandling?

« on: July 09, 2011, 03:10:34 pm »

There are maybe really some justified use cases for return codes (the "non-fatal cases"). Eventually, some people end up writing wrappers that catch exceptions and return bools

Or you just use the dual exception/error-code technique presented earlier in this thread and everyone is happy, including binding authors. Note also that this technique is going to become standard practice in the next C++ version (using the already available std::error_code et al).

85

Feature requests / Request: Exceptionhandling?

« on: July 09, 2011, 02:32:17 pm »

How does that solve the problem of exceptions across shared libraries boudaries?

As presented it doesn't, and nor should it. You do realise that Boost.Filesystem is a compiled library? The "exception problem" really isn't that much of a problem, and as far as it is a problem, the solution is to let the user compile the library themselves when they need non-default compiler settings (again, just as Boost.Filesystem does).

That being said, you could of course sidestep the issue all together by using the technique I presented, but have the throwing version of the functions be defined, inline, in the header file.

86

Feature requests / Request: Exceptionhandling?

« on: July 09, 2011, 12:45:38 am »

I would suggest following the Boost.Filesystem approach to the dual exception/error-code interface problem.

Pseudo-code example:

Code: [Select]


namespace sf
{
    class ErrorCode
    {
        // impl..
    };
    class Exception
    {
        // impl...
    };

    //...

    void Devil::SetNumber( int param )
    {
        ErrorCode ec;
        SetNumber( param, ec );

        if ( ec )
        {
            throw Exception( ec );
        }
    }

    void Devil::SetNumber( int param, ErrorCode& ec )
    {
        if ( param != 666 )
        {
            ec = ErrorCode( EvilError );
            return;
        }
       
        m_Number = param;
    }
}   // namespace sf