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

Implement IDisposable for appropriate classes in .net wrapper #753

Open
hha1501 opened this issue Mar 24, 2024 · 1 comment
Open

Implement IDisposable for appropriate classes in .net wrapper #753

hha1501 opened this issue Mar 24, 2024 · 1 comment

Comments

@hha1501
Copy link
Contributor

hha1501 commented Mar 24, 2024

Hi,

Coming along with the introduction of writer API for .net wrapper is the Image class. This class implements IDisposable as it maintains an unmanaged resource (_d member variable). I think other wrapper classes that do the same thing should implement IDisposable too.

A guideline already exists regarding how to implement the "disposable" pattern. There are 2 key behaviors I would like to point out:

  • An disposable object should be able to be disposed at anytime (i.e. without relying on GC to do the job through finalizers)
  • A Dispose method should be idempotent

Another thing to consider is how a disposable class should behave when we access its properties/methods when it is disposed. I have seen some code check for disposed state (usually indicated by a private variable) and throw an exception (preferably ObjectDisposedException). Others code would omit such checks. For zxing-cpp .net wrapper I think either way is fine. Accessing a disposed object's members without guards should lead to dereferencing a null pointer on the native side and that's a kind of (implicitly) throwing an exception.

@axxel
Copy link
Collaborator

axxel commented Mar 25, 2024

The reason I chose to implement IDisposable for the Image wrapper is not that it maintains an unmanaged resource but because of two conditions simultaneously true: a) the unmanaged memory behind _d can be large and b) there is a use case in which a lot of those Image objects can be produced in rapid succession. To some extend those two conditions might be true for the Barcode class as well, but not for any of the other. And having to deal with disposed objects is exactly an argument against introducing it in the first place. Not having to worry about it is exactly the value of a garbage collector.

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