Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outdated documentation concerning memory model #365

Open
X-Ryl669 opened this issue Apr 26, 2018 · 0 comments
Open

Outdated documentation concerning memory model #365

X-Ryl669 opened this issue Apr 26, 2018 · 0 comments
Labels

Comments

@X-Ryl669
Copy link

X-Ryl669 commented Apr 26, 2018

On the main page, the documentation talk about using ref_ptr for memory management, but none of the code does that. It's not clear what is the current memory model expectation from globjects now it's using unique_ptr, so I guess a update of the documentation is required.

It should answer these questions:

  1. When the globject interface use a plain pointer, who is managing the pointer lifetime (is it owned by globjects or should we keep track of them ourselves) ?
  2. unique_ptr usually means that we (users) need to deal with the pointer's life (and unique_ptr is doing exactly this for us), yet some of the globjects API is using plain pointers. Do we need to reassign the pointer if we update the owned object ? For example, in Program::attach(Shader * shader), do we need to detach and attach a new Shader if it's destructed / re-allocated on our side? Or is it magically done through the listener interface?
  3. Entanglement is not clear. Program have a pointer on the Shader, but Shader also take a pointer on the Program in the attach method. Who should delete the other ?
  4. Exception safety... that's a huge question by itself
  5. Dependence on the GL context ? Is a globject::XXX instance working correctly if used in a static singleton (thus destructed after main() is done and the GL context has vanished ?
@cgcostume cgcostume added the bug label Oct 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants