Access modifiers do not affect destructor visibility in ref class?

[Guest]

This compiles and runs successfully in VS2005:

ref class A
{
private:
~A() { this->!A(); } // private!
!A() { } // private!
};

....

A^ a1 = gcnew A();
a1->~A(); // I would expect this to signal a compile
// error regarding accessibility
delete a1; // As well as this.

A a2; // As well as this.
a2.~A(); // And as well as this.

So, given that access modifiers don't have any effect on the visibility on
destructors in ref classes, how would one prevent a client from
deterministically cleaning up a managed reference object?

Another thing I find peculiar is that you can call the destructor on an
interface class, even though the compiler enforces the fact that an interface
class cannot have a destructor.

interface class B { };
ref class C : B { };

....

B^ b = gcnew C();
b->~B(); // Compiles fine???
delete b; // this too?

I have a situation where I want to prevent clients from deterministic
destruction of certain objects. For example, let's say I return a special
"read-only" interface to an internal object. I shouldn't be able to destroy
the object via the interface (by calling "delete" or explicitly calling the
destructor as demonstrated above) as this would break encapsulation. I also
don't want to return a copy of the internal object as it might incur a major
performance penalty. I would enforce this in standard C++ by returning a
reference to a const object. How would one recommend I do it in CLI?

 

[Tamas Demjen]

So, given that access modifiers don't have any effect on the visibility on
destructors in ref classes, how would one prevent a client from
deterministically cleaning up a managed reference object?

There is no such thing as a destructor in .NET. When you define a
destructor in your class, it compiles to something like this (not valid
C++/CLI code, just to illustrate what's going on inside):

ref class A : public System::Object, public IDisposable
{
public:
virtual void Dispose() override
{
}
};

As you see, it's a public function, and even if you tried to make it
private, it would be available via the IDisposable interface. You can't
hide that.

Also, the call to delete does nothing more than calls Dipose(). It
doesn't deallocate any memory.

The solution to your problem is to not define a destructor at all. If
you don't want the d'tor to be called, just don't define it. Then your
class won't be disposable, and no one will be able to call Dispose on
it. If someone calls the delete operator on it, it will do absolutely
nothing.

ref class A
{
private:
!A() { CloseMyResources(); } // you still need a finalizer
};

A^ a = new A;
delete a; // valid, but this line does absolute nothing, it's a NOP

Tom

 

[Guest]

Thanks for your reply, Tom.

I'm familiar how destructors and finalizers map to the .NET Dispose pattern.
What I'm attempting to illustrate is that the compiler does not prevent me
from putting a destructor and finalizer under a private block, which mislead
me into thinking that I could limit deterministic destruction by limiting
access to the destructor. I feel that if the compiler allows me to do it,
then it should enforce visibility rules regardless of what IL it produces in
the back end.

Having said that, I just took a look at the C++/CLI specification to see if
it says anything on the matter. Under section 19.13.1 reads: The
access-specifier of a destructor in a ref class is ignored. I guess that
answers that. I would suggest that the compiler present an error (or
possibly a warning) when a destructor is defined under a non-public access
modifier in a ref class. C# enforces this by not allowing you to change the
access level of an interface method:

class A
: IDisposable
{
private void IDisposable.Dispose() { } // error CS0106: The modifier
'private'
// is
not valid for this item

// or

private virtual void Dispose() { } // error CS0621: virtual or
abstract
// members
cannot be private

// or

protected virtual void Dispose() { } // error CS0536: 'B' does not
implement
// member
System.IDisposable.Dispose().
//
'B.Dispose()' is either static, not public,
// or has a
wrong return type.
}


As for the solution you presented regarding limiting the deterministic
destruction of an object... I would agree with you that if I wanted to
prevent EVERYONE from calling Dispose() on my object, I should just not
define the destructor. However, I'm looking to just RESTRICT who can do it
to enforce encapsulation without having to implement a wrapper class, perform
an expensive copy, or rely on documentation to enforce a policy.

 

[Tamas Demjen]

I would agree with you that if I wanted to
prevent EVERYONE from calling Dispose() on my object, I should just not
define the destructor.

Having a strong C++ background, I understand your problem, but C++/CLI
is not exactly C++. It has to follow the rules of the CLI closely. I'm
not an authority, but I think the .NET framework insists that Dispose be
public, so you can not restrict it. Even if you could do that, that
restriction would be half baked, as Dispose would still be publicly
available via IDisposable.

I agree that the compiler should show at least a warning message
pointing out that destructors for ref classes must be public.

However, I'm looking to just RESTRICT who can do it
to enforce encapsulation without having to implement a wrapper class, perform
an expensive copy, or rely on documentation to enforce a policy.

As a workaround, you could create your own interface,
IMyRestrictedDispose, where Dispose is defined as protected, for
example. The compiler is just not going to associate that with the
concept of destructors. Deterministic destruction with the stack syntax
is only possible if the destructor is public. You can, however, still
use the RAII concept with a helper class to call your restricted cleanup
in a deterministic way:

ref class Guard
{
public:
Guard(A^ source) : a(source) { }
~Guard() { a->MyRestrictedCleanup(); }
private:
A^ a;
};

Tom