mmozeiko
There is exception where you can do, but you shouldn't rely on that (class has no vtable, and no members in its or its parent classes which have constructors).
I don't think you meant to say that you can't rely on POD semantics if it's truly a POD type...
C0D3
oh sorry, Texture,Image and Sprite is all part of the cocos framework so I guess I would have to go in and change it. I guess I can't use that class for this method then?
It sounds like you've found an impedance mismatch between Cocos and your memory manager. I think the thing to do is ask the Cocos people how to integrate it with custom memory management.
Yeah, sorry if I made that unclear. English is not my native language.
What I wanted to tell is simply that you should expect for this to not work in general case when C++ class can contain who knows what. Except for those POD types (which I also mentioned in #30001).
@C0D3: if this library is not designed with preallocated memory technique in mind, you really should not try to apply it. Just use new + unique_ptr. Otherwise as you see for yourself not only allocation can be problematic, but also you need to think about memory deallocations and ownership. What if library contains some global list of reference counted Textures2D objects and it tries to delete them (with operator delete) when reference count goes to 0? You will crash, because you need to disable default memory deallocation. Either you understand how exactly memory is managed by this library and modify it to suit your needs or you don't fight it and use regular C++ memory allocation.
What I wanted to tell is simply that you should expect for this to not work in general case when C++ class can contain who knows what. Except for those POD types (which I also mentioned in #30001).
@C0D3: if this library is not designed with preallocated memory technique in mind, you really should not try to apply it. Just use new + unique_ptr. Otherwise as you see for yourself not only allocation can be problematic, but also you need to think about memory deallocations and ownership. What if library contains some global list of reference counted Textures2D objects and it tries to delete them (with operator delete) when reference count goes to 0? You will crash, because you need to disable default memory deallocation. Either you understand how exactly memory is managed by this library and modify it to suit your needs or you don't fight it and use regular C++ memory allocation.
Edited by Mārtiņš Možeiko
on
Edited by Ben
on
I looked at the source, thanks. I realize I was doing it wrong. Create() creates an "Image" and Texture so when I did a SetTexture, it ignored the texture that I tried to set because it was no longer null when I did a create(). I look though the source again and found createWithTexture but that doesn't seem to work.
I am also wondering if should be loading the image into the memory before.
I am also wondering if should be loading the image into the memory before.