Messages

1

D / Proper setup guide and usage tutorial?

« on: January 29, 2012, 05:57:14 pm »

Getting D to link against CSFML was hard, so I did everything dynamically instead.

Yep that's a big open issue. DSFML ought to load everything statically.
But that makes inheritance in the wrapper more complicated.

Other than that and a few other small stuff in the D compiler. The language is freaking sweet and I would love to see someone pick it up again and create a new DSFML bindings for version 2.

I'm working on it.

It is linked to C++ directly (with some C++ glue between SFML and D code). Most of it is done, but the build system is currently very broken and the new graphic API isn't readu yet, amking the grapgics module unusable (ATM).

2

General discussions / New naming convention

« on: January 29, 2012, 04:51:27 pm »

Ho God

I hate you and love you at the same time. The convention is way better but . . . So much broken code.

3

General discussions / New graphics API ready

« on: December 12, 2011, 03:17:56 pm »

Hi,

Do you know, approximatively, when this new API will be merged in SFML2 ?

4

Audio / Is SoundBufferRecorder made to be subclassed ?

« on: December 05, 2011, 05:59:42 pm »

I suggest one of thoses :

1/ Make mySamples protected, so callback function can use it when overloaded. With such a decision, SoundBufferRecorder can be subclassed in a usefull way.

Callback function could be delared protected too if we consider that the subclass can call SoundBufferRecorder's callback.

2/ Make callback's function non virtual. This will not change anything at runtime, because thay are called from SoundRecorder, so the function call will be virtual anyway.

But it makes it clear that the class is not meant to be overriden.

Let's explain what make me start this topic. I did look at the SoundBufferRecorder class and saw that it has some virtual function. So I wondered what I could do to subclass SoundBufferRecorder in a usefull way. And nothing that couldn't be done with SoundRecorder directly, because every additions in SoundBufferRecorder are private. At the end, this virtual stuff isn't usefull and can confuse a person reading the header file.

5

Audio / Is SoundBufferRecorder made to be subclassed ?

« on: December 05, 2011, 12:12:03 am »

You can rediefine virtual function in subclasses even if they are private. You cannot call them, but can define them.

Well it is a strangeness, but it is confusing, not dangerous.

6

Audio / Is SoundBufferRecorder made to be subclassed ?

« on: December 04, 2011, 04:00:31 pm »

Yes, but you can prevent someone to try to redefine it in subclasses.

7

Audio / Is SoundBufferRecorder made to be subclassed ?

« on: December 03, 2011, 12:30:48 pm »

That was what I thought. Even made private virtual function can still be redefined in subclasses. So I guess we should make callback non virtual in this class.

8

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).

9

Audio / SoundSource and the rule of 3

« on: December 02, 2011, 10:01:19 pm »

Well, I'm experienced enough to know that I do mistake and stupid stuff sometime (see the thread in graphic for example). And at this point, I never met anybody that wasn't making some of them

Coding is a practice that show us how fallible we are, and how defensive we should be against ourselves. Sure, SoundSource is not meant to be used directly, but subclassed. Sure also it is in headers, so anybody can use it, whether it makes sense or not. So, by prevention, I think it should be done.

10

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

« on: December 02, 2011, 12:36:11 am »

Well the return area is create by the caller on the stack. This is why you don't have any copy when you do :

Image i = texture.CopyToImage(); // Copy constructor isn't called here

This copy constructor isn't called because the memory are where the image is intanciated is created by the caller and passeed to the function as an hidden parameter (a pointer). So you can return a reference in this particular case.

Nevermind, this isn't a big deal.

EDIT: Well that remembers me why I do less C++ and looks for alternatives in things like D Obviously, the area on the stack isn't create if you return by reference. My C++ is a bit rusty, you are right. keeping the original post for the reccord.

11

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.

12

Audio / SoundSource and the rule of 3

« on: November 28, 2011, 04:40:46 pm »

So maybe the assignment operator should be declared private and never defined to avoid any mistakes ?

13

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.

14

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

« on: November 26, 2011, 03:57:39 pm »

The problem is that it is used, for exemple by the audio module. Trass3r had made a workaround for that but it is not very clean and asynchronous. I plan to provide something better to handle that.

15

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

« on: November 25, 2011, 03:39:44 pm »

No, because I'm working on the D bonding, and I did face some tricky bugs relative to threading due to bad interraction between the D runtime and SFML implementation of threads.

After more investigations, this is definitively not SFML's problem, but a bad interraction in low level memory management due to D runtime (memory management in D is thread aware).