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

Should nlopt_opt be finalized? #11

Closed
ivan-pi opened this issue Nov 23, 2021 · 4 comments
Closed

Should nlopt_opt be finalized? #11

ivan-pi opened this issue Nov 23, 2021 · 4 comments

Comments

@ivan-pi
Copy link
Collaborator

ivan-pi commented Nov 23, 2021

I'm interested in the rationale behind preserving explicit destruction of the optimization object instance instead of wrapping this within a finalizer.

I can see a few reasons why'd you keep this as the user's responsibility, primarily to avoid dealing with the odd behavior prescribed by the Fortran standard.

@awvwgk
Copy link
Member

awvwgk commented Nov 23, 2021

Actually, the nlopt_opt will destroy the handle automatically using a final procedure:

final :: destroy

The destroy procedure is additionally exposed to allow the user to perform this operation manually, since the procedure will check whether the handle is actually associated:

nlopt-f/src/nlopt_wrap.f90

Lines 239 to 243 in 696b0e2

subroutine destroy(self)
type(nlopt_opt), intent(inout) :: self
if (c_associated(self%handle)) call nlopt_destroy(self%handle)
self%handle = c_null_ptr
end subroutine destroy

The rationale for having both is that it can be inconvenient to not have a way to manually destroy an object and require it to go out of scope for proper finalization (either by using block or by assignment).

@ivan-pi
Copy link
Collaborator Author

ivan-pi commented Nov 23, 2021

Right, I missed that, sorry. I was only looking at the example in the readme.

I fully agree with your reasoning.

@ivan-pi ivan-pi closed this as completed Nov 23, 2021
@awvwgk
Copy link
Member

awvwgk commented Nov 23, 2021

Maybe we could update the documentation for this and add a code comment in the example? However, I think that this example might be a bit special, because we are in a program scope which doesn't necessarily call the final procedure on exit but leaves it to the kernel to clean up the used memory after the process terminates. To avoid false positive memory leaks from the C side, manual deconstruction seems like the right thing to do.

@ivan-pi
Copy link
Collaborator Author

ivan-pi commented Nov 23, 2021

By documentation do you mean the Readme? If so, I can I create a PR. Yes, the explicit destruction in the main program scope is a good rule to avoid the false positive when using an application like valgrind.

My question was motivated by my two recent threads:

An artificial example for the auto-finalization in the associate statement, would be a constraint object with a pointer component, that was created using the default structure-constructor directly in the associate statement, instead of declaring at as a (static) target in the main program scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants