Problems with sf::SoundBuffer

[Laurent]

What if you remove your manager from this code, and use a sf::SoundBuffer directly?

[CBenni::O]

This worked...

Code: [Select]

sf::SoundBuffer* SB = new sf::SoundBuffer;
if(!SB->LoadFromFile("nice_music.ogg"))return 1;
sf::Sound* MS = new sf::Sound();
MS->SetBuffer(*SB);
MS->Play();
sf::Sleep(1.0f);

But I'm too lazy to test it in deph I think that I did a mistake somewhere, because it works now...

bye, CBenni::O

[Nexus]

Why do you allocate everything with new? There's no need for that. I already pointed out, what problems come with dynamic allocations and why alternatives like RAII and automatic memory management are really worthwhile.

If you encapsulated the low-level parts of your code, then you'll have to worry far less about errors, memory leaks and undefined behaviour in your programs. I even guess this problem here might not have happened with a clearly structured design...

[CBenni::O]

What I have above, is just a short snippet of a Program I used for testing... in my example Program (that I will release tonight ), I use auto_ptr's if not local variables...

One good thing: my Framework does not have any memoryleaks and is exeption-safe (I hope so ) thanks to "Effektiv C++ Programmieren"
Thank you for that tipp

bye, CBenni::O

[Laurent]

I use auto_ptr

std::auto_ptr is a dangerous beast with its move semantics, I personnaly never use it. Are you sure that you use it properly?

[CBenni::O]

Yes, I only use it in my example program, in all other cases I use some kind of RAII

Download of my Framework

bye, CBenni::O

[Nexus]

One good thing: my Framework does not have any memoryleaks and is exeption-safe (I hope so ) thanks to "Effektiv C++ Programmieren"

Ah okay, I didn't know that. Congratulations then!

std::auto_ptr is a dangerous beast with its move semantics, I personnaly never use it. Are you sure that you use it properly?

At the moment, std::auto_ptr is the only smart-pointer that's really part of the standard library (shared_ptr is in TR1, scoped_ptr only in Boost (I still don't understand why)). Of course, one has to work with auto_ptr carefully, because as you said, it doesn't have common value semantics and can't be used like other objects, for example in STL-containers. Also things like that can be very tricky:

Code: [Select]

void func(std::auto_ptr<X> ptr);
I like std::auto_ptr because it is one of the few ways to employ move-semantics in current C++. For example, it works well with factory methods. Raw possessing pointers are rather unconvenient (especially regarding exception safety), shared_ptr would be the alternative. But why share ownership when we need to transfer it?

[Laurent]

Is your demo supposed to show the problem? It seemed to work fine when I tested it, I mean sounds played properly.

By the way, I looked at your code and there are indeed too many pointers and dynamic allocations
None of them are really necessary, and you have many leaks because you don't destroy all the objects that you create with new.

[CBenni::O]

No, It's the final version of my framework...

All I need to add is the Release ()-Function in ResourceManager, but this is no Problem...

And:

By the way, I looked at your code and there are indeed too many pointers and dynamic allocations
None of them are really necessary, and you have many leaks because you don't destroy all the objects that you create with new.

Are you sure? I didn't find any Hidden memory leaks using vld, and auto_ptr or whatever does nothing else but to allocate and free Memory... And I Hate to return auto_ptr's, because you get More and more get()'s etc...

bye, CBenni::O

[Laurent]

No, It's the final version of my framework...

Sorry, I'm lost. Is your problem solved now?

Are you sure? I didn't find any Hidden memory leaks using vld, and auto_ptr or whatever does nothing else but to allocate and free Memory...

I'm talking about your framework, not the demo (which is the only place where you use std::auto_ptr, right?). An example of memory leak is in FloatingObj: the image used by the sprite is allocated with new but never deleted.

You should really not allocate everything dynamically

[CBenni::O]

No, It's the final version of my framework...

Sorry, I'm lost. Is your problem solved now?

Yes, it is... But I don't know what the error was... It had something to do what I do with my Resource after Aquiring it...

I'm talking about your framework, not the demo (which is the only place where you use std::auto_ptr, right?). An example of memory leak is in FloatingObj: the image used by the sprite is allocated with new but never deleted.

You should really not allocate everything dynamically

Yes, thank you... I've changed it... There ist only 1 dynamic Allocation per FloatingObj-Constructor now...

bye, CBenni::O