Topics

1

Audio / Is SoundBufferRecorder made to be subclassed ?

« on: December 02, 2011, 11:56:18 pm »

I'm not sure it make that much sense to subclass this, as long as all useful things are private.

If it is not meant to be subclassed, callback should be declared non virtuals.

If it is meant to be subclassed, internal buffer should be protected and/or callbacks too (to allow subclasses to recall parent's callback).

2

Graphics / sf::Texture::CopyToImage return by value

« on: December 01, 2011, 10:59:58 pm »

It would be nicer if it could return by reference. In some cases, you have to create temporary variables, for exemple, to pass the returned image to a function that require a reference (invalid initialization of non-const reference of type ‘sf::Image&’ from an rvalue of type ‘sf::Image’).

In most cases, it doesn't change anything as the compiler is able to avoid the copy.

3

Audio / SoundSource and the rule of 3

« on: November 28, 2011, 12:52:17 pm »

Soundsource define a copy constructor but doesn't define a assignment operator. I don't really see the point of that.

As the main constructor is protected and the destructor virtual, SoundSource isn't made to exist in itself, but to be used as a base class. So the copy constructor shouldn't be defined.

Or does cases exists where it can be used by itself ? In such a case, the copy constructor made sense, but overloading assignment should be done too.

4

System / segfault/memory curruption risk in SFML Thread class.

« on: November 24, 2011, 09:58:58 pm »

If you spawn a thread, launch it, and immediately delete it, you get intermitent segfault (or worse, memory corruption).

I triggered that with simple code as follow :

Code: [Select]

Thread* t = new Thread(someFunction);
t->Launch();
delete t;

I'm not sure how this is fixable (or not). Maybe by copying the Thread object in the launch function and using that copy ?

5

Network / Packet has dangerous behaviour with char* and operator >&

« on: October 30, 2011, 06:15:04 pm »

Code: [Select]

Packet& Packet::operator >>(char* data)
{
    // First extract string length
    Uint32 length = 0;
    *this >> length;

    if ((length > 0) && CheckSize(length))
    {
        // Then extract characters
        std::memcpy(data, GetData() + myReadPos, length);
        data[length] = '\0';

        // Update reading position
        myReadPos += length;
    }

    return *this;
}

This piece of code is made for buffer overflow. This function should be aware of teh size pointed by data.

As C++ as a string class, this operator overloading should just be removed in my oppinion. To ensure the possibility of binding throw C, a function can be added like read(char* data, size_t maxCharRead).

6

Feature requests / SFML should use only types of defined size

« on: October 29, 2011, 01:35:05 pm »

SFML uses a lot of types like int. Thoses types has different size on different architecture.

This leads to difficulties to have consistent results on different hardware. Plus, this leads to difficulties to interface SFML with languages other than C or C++, that can have different type systems.

If the type depend explicitely on the architecture, the usage of typedef like size_t should be the usage.

What do you think ?

7

General discussions / Pull request ?

« on: June 16, 2011, 03:41:19 pm »

Hi,

I recently make a small modification on dsfml. Not a breaking feature, simply a little patch fixing compilation issues on 64bits systems. However, I have no clue how to do a pull request for that modification.

How can I do that ?

In addition, I think pull requests should be as easy as possible. Discouraging contributions because of complex process is counterproductive IMHO.

8

D / What are main goals of DSFML2 and can I help ?

« on: June 15, 2011, 06:06:45 pm »

I'm currently back into D devellopement, and I love it.

I just saw that SFML has a new version, v2, which isn't finished yet, but seems promizing.

I have basically 2 questions about the D port. The first one is about the objectives.

Does the D port aim D1 or D2, phobos or tango, will it use D2 C++ interfacing where it's possible, will threading will be managed by D stuff instead of C/C++ bonding (the threading in D is wayyyy better) and so on . . .

The second point it what I can do to help ?