Calling a private base constructor from within a constructor in MSIL -- dotnet clr

rbyers NO[at]SPAM online.microsoft.com (
2/4/2005 9:50:34 PM

Hi Kemal,
No you cannot call a private base class constructor directly - that is
exactly what the "private" means <grin>. Also, in order for a constructor
to be verifiable, it must directly call a constructor of it's base class.
Jim Miller's annotated CLI book has an interesting discussion (page 76) of
the implications of this for languages like Eiffel that don't want this
restriction.

Assuming you only want to run in full-trust, you might be able to get away
with something unverifiable. For example, don't call any base constructor
directly, but instead use reflection to invoke the base constructor using
your existing "this" pointer. However, I'm not sure offhand whether
reflection will let you invoke a constructor on an existing object like a
regular method.

Regardless, there are larger problems with creating a true transparent
proxy class like this yourself. This is exactly why the CLR has built-in
support for transparent proxies. Is there some reason why you couldn't use
the existing TransparentProxy system to do what you want?

Rick

--------
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
[quoted text, click to view]

Kemal Erdogan
2/5/2005 5:03:32 PM

Hello Rick,

Thank you for your reply. I would need a custom solution
just because dotnet framework does not support multiple
inheritance.

I actually need to intercept method calls, so change of
method definitions at runtime would also be a possible
solution for me. Do you know a good tool, or have some
source code for that?

Kemal

[quoted text, click to view]

rbyers NO[at]SPAM online.microsoft.com (
2/7/2005 7:35:40 PM

Right, the class you are proxying would have to extend MarshalByRefObject
(or ContextBoundObject) in order to use a TransparentProxy to intercept
calls to it. When the JIT compiler sees a non-virtual method call, it
needs to have the freedom to inline it which eliminates pretty much any
dynamic interception technique (MBROs are a special case). For your
original emitted-subclass approach do you require the user to use your
proxy type directly? If it is casted to the base class, interception of
non-vrituals no longer works. If that is acceptable for you, then perhaps
you could use encapsulation instead of inheritance.

The CLR has no general-purpose run-time interception mechanism (probably
due in large part to the performance implications). If this is what you
you're trying to achieve, you're probably out of luck. The only
possibility would be to use the profiler API to replace code on the fly
when it is jitted (see [1]). However, the profiler API is intended only to
be used in a development context, so depending on your exact scenario, it
is likely to be inappropriate.

Rick
[1] http://msdn.microsoft.com/msdnmag/issues/03/09/NETProfilingAPI/

--------
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
[quoted text, click to view]

Fabian Schmied
2/8/2005 9:17:21 AM

[quoted text, click to view]

I recently found Castle Project's DynamicProxy, which is more flexible
than the built-in proxy support, maybe you'll find it useful:
http://www.castleproject.org/castle/show/dynamicproxy

It works by creating dynamic proxy classes at runtime, either deriving
from your class and overriding virtual methods, or implementing an
interface and delegating to your own implementation. The first approach
has the disadvantage of supporting virtual methods only, but it also
allows interception of intra-object calls, which is a nice thing to have.

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet clr

dotnet clr : Calling a private base constructor from within a constructor in MSIL