search

floooh / oryol

A small, portable and extensible C++ 3D coding framework
MIT License
2k stars 200 forks source link

using Oryol::Ptr<> #256

Closed neshume closed 7 years ago

neshume commented 7 years ago

Is it wise to keep Oryol::Ptr<> when using functions or use const ref ? or maybe even use the bare internal pointer..

std::smart_ptr has many forms .. Oryol::Ptr<> is a little different what is the preferred strategy when moving the smart pointer around?

cheers,

floooh commented 7 years ago

Usually passing a const-ref (const Ptr<X>&) is the right thing, since this doesn't involve any ref-count bumping or validity checks.

floooh commented 7 years ago

...but having said that... if you prefer the std smart pointers (shared_ptr or unique_ptr), for your own classes, you can do this as well and it may be more flexible, just don't mix them with Oryol's RefCounted class and Ptr<>. Oryol only uses its Ptr class in very few places, and I intend to keep its usage in 'public APIs' as minimal as possible.

neshume commented 7 years ago

Hi F,

I understand ... and I have no intention of mixing the shared_ptr crap into the code.. but I had some very bad crashes regarding oryol::ptr handling and validating pointers ... so I could keep regular pointers passing to functions ... but I think it could be dangerous...

floooh commented 7 years ago

Can you describe what type of crashes you are getting? There are a few typical errors with C++ references in general, since under the hood they are just memory addresses.

For instance if the reference points into a dynamic array, you'll have to be aware of 'iterator invalidation': if the array grows while the reference exists, the underlying storage of the array will move somewhere else in memory, and the reference will point to memory that no longer has valid content.

Or if you erase elements from the array while a reference to an item in the array exists, the reference may point to a different item or past the end of the array.

neshume commented 7 years ago

The types you described are of course memory management 101 .. i am talking about the exotic stuff ..like

allocation on the stack of a Oryol::ptr .. and than passing to another instance of a class .. int this case the pointer gets invalidated ... before the Oryol::ptr gets out of scope.. hence the question regarding passing smart ptr's into a function ... right now they are passed by value .. but I am starting to think that passing smart ptr's around is risky ;o)

cheers,

neshume

neshume commented 7 years ago

Hi Floooh,

The issue was found .. i was partially conencted to the Oryol::PTR stuff ;o)

It seems resources were not released (too many refs hanging around) causing ResourcePool to exceed the 128 limit (current) of the number of pool resources.. causing an assert (even a justified one) ..

So .. I will minimize the usage of the Oryol::Ptr and handle the memory traditional way ;o)

Cheers,

Neshume