sf::Vector2 Empty value

[hayer]

Hi

I think SFML should have something like XNA vectors. A empty value. Like this(or similar):

Code: [Select]


sf::Vector2f emptyVector = sf::Vector2f::Empty;


Since it is not possible to return NULL from e, ex., search function that didn't find any result.

[Laurent]

I don't think so. If T has no "empty" value, why should sf::Vector<T> have one? I could add a "zero" vector, but a "empty/null" vector would be totally unrelated.

Since it is not possible to return NULL from e, ex., search function that didn't find any result.

You're looking in the wrong direction to solve this problem. You need to handle this in your function, not in the type that you return (how would you do with a single int or float?).

There are several solutions:

Code: [Select]

bool find(sf::Vector2f& result);

Code: [Select]

boost::optional<sf::Vector2f> find();

[Disch]

You can implement your own.

Make a constant vector and give it NaN for x,y components.

Though I agree with Laurent, not necessary for SFML.

[Laurent]

Make a constant vector and give it NaN for x,y components.

Be careful, if I remember correctly some special floating point number(s) can never equal others, even themselves. I don't know if it's the case for NaN.

EDIT: wikipedia confirmed that, NaN is not equal to NaN, and that's the only number to have such a property (+Inf is equal to +Inf, for example)

not necessary for SFML.

I would even say: not a good idea at all.

[omeg]

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

[Lee R]

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.

[Nexus]

The default constructor does already create zero vectors...

Or do you suggest that the default constructor shouldn't initialize the vector? I don't think it's a good idea to deal with uninitialized objects for the tiny performance gain

[omeg]

Right, it's a struct, nevermind

[Laurent]

Right, it's a struct, nevermind

And?

[omeg]

Right, it's a struct, nevermind

And?

I'm using C# only so this will be .NET-specific.
My proposal was to avoid creating multiple Vectors with the same (zero) value. Why give the garbage collector pressure if you can avoid it? But that's with classes, and Vector is actually a struct, so it's always instantiated anew on the stack. Here is the illustration of this issue:

Code: [Select]

class TestClass
{
    public int x;
    private static readonly TestClass _Zero = new TestClass { x = 0 };
    public static TestClass Zero { get { return _Zero; } }
}

struct TestStruct
{
    public int x;
    private static readonly TestStruct _Zero = new TestStruct { x = 0 };
    public static TestStruct Zero { get { return _Zero; } }
}

public static void Main()
{
    unsafe
    {
        TestClass c0a = TestClass.Zero;
        TestClass c0b = TestClass.Zero;
        TestClass c1 = new TestClass {x = 0};
        TestClass c2 = new TestClass {x = 0};
        Console.WriteLine("c1 == c2 ? {0}", c1 == c2);
        Console.WriteLine("c0a == c0b ? {0}", c0a == c0b);
        Console.WriteLine("c1 == TestClass.Zero ? {0}", c1 == TestClass.Zero);
        Console.WriteLine("c0a == TestClass.Zero ? {0}", c0a == TestClass.Zero);

        TestStruct s0a = TestStruct.Zero;
        TestStruct s0b = TestStruct.Zero;
        TestStruct s1 = new TestStruct {x = 0};
        TestStruct s2 = new TestStruct {x = 0};
        Console.WriteLine("s1 == s2 ? {0}", &s1 == &s2);
        Console.WriteLine("s0a == s0b ? {0}", &s0a == &s0b);
        Console.WriteLine("s0a == s1 ? {0}", &s0a == &s1);
    }
}


The output is:

Code: [Select]

c1 == c2 ? False
c0a == c0b ? True
c1 == TestClass.Zero ? False
c0a == TestClass.Zero ? True
s1 == s2 ? False
s0a == s0b ? False
s0a == s1 ? False

You can see that both TestClass.Zero variables are equal (reference to the same static Zero member), no object creation happening there. But with structs it's different: they are always instantiated, hence they have a different address.

[Laurent]

I'm using C# only so this will be .NET-specific.

The default here is C++, so don't forget to say it first if you're referring to another language
What you say didn't make sense for C++, but in the .Net world it is a valid point, yes.