Metaprogramming

[Jon Harrop]

If you do metaprogramming in C#, is the generated code garbage collected or
does it leak indefinitely?

 

[Mads Bondo Dydensborg]

If you do metaprogramming in C#, is the generated code garbage collected
or does it leak indefinitely?

Can you give an example?

Regards,

Mads

--
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo
Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77
34

 

[Marc Gravell]

Regardless of how they come to be (Reflection.Emit, etc), dynamic
assemblies are treated the same as regular assemblies; there is no
good way to unload an assembly from an active appdomain. You can,
however, load it into a second app-domain and then kill the app-
domain. A good bet is to (for instance) use a static cache so that you
don't end up creating the same code over and over, but simply re-use
the assembly you emitted earlier.

Executing code is treated as normal; instances will be collected (or
not) using the same rules.

Marc

 

[Ben Schwehn]

If you do metaprogramming in C#, is the generated code garbage collected
or does it leak indefinitely?

Without providing more detail, I find it difficult to be sure what you're
really trying to do.

If you dynamically create and load assemblies, you should probably load
them into a new appdomain. You cannot unload an assembly, but you can
discard an appdomain and discarding the appdomain will discard all the
assemblies loaded into it with it.

Ben

 

[Jon Skeet [C# MVP]]

Without providing more detail, I find it difficult to be sure what you're
really trying to do.

I think he's trying to prove that F# is superior to C#. That's Jon
Harrop's usual purpose on this group

Jon

 

[Marc Gravell]

I think he's trying to prove that F# is superior to C#. That's Jon

Harrop's usual purpose on this group

Interstingly, I think it is a valid discussion - but the important
context is: "at what?". Functional languages do have advantages,
especially in areas such as science / modelling - however, it isn't
necessarily a great fit for the typical business application.

It is *certainly* a much more meaningful discussion than the far-too-
regular VB vs C# ;-p

Marc

 

[Jon Skeet [C# MVP]]

Interstingly, I think it is a valid discussion - but the important
context is: "at what?". Functional languages do have advantages,
especially in areas such as science / modelling - however, it isn't
necessarily a great fit for the typical business application.
Absolutely.

It is *certainly* a much more meaningful discussion than the far-too-
regular VB vs C# ;-p

True. I just wish Jon would get into it properly rather than just
asking leading questions: "If you do X does C# behave badly", "Is C#
going to give way to F#" etc.

Jon

 

[Laura T.]

True. I just wish Jon would get into it properly rather than just
asking leading questions: "If you do X does C# behave badly", "Is C#
going to give way to F#" etc.

Jon

Agree. In this way he's actually doing more harm than good for F# community.
There are better ways to evangelize new ideas.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

True. I just wish Jon would get into it properly rather than just
asking leading questions: "If you do X does C# behave badly", "Is C#
going to give way to F#" etc.

You forget that he thinks ML is more used than C#.



Arne

 

[Jon Harrop]

Without providing more detail, I find it difficult to be sure what you're
really trying to do.

If you dynamically create and load assemblies, you should probably load
them into a new appdomain. You cannot unload an assembly, but you can
discard an appdomain and discarding the appdomain will discard all the
assemblies loaded into it with it.

Right. I think I'm getting to grips with this. So you must deallocate code
explicitly yourself, i.e. it is not garbage collected. To be able to
deallocate code there is the technical issue of wrapping your assembly in
an appdomain.

I read somewhere that types cannot be collected but that makes sense because
(I believe) the .NET platform prohibits structural subtyping. So all types
are regarded as different even if they are structurally identical, e.g. if
you define an (int, float) pair in two different assemblies then they are
considered to be different types. So types have the same place as code
in .NET from the point of view of allocation, and deallocating an appdomain
will deallocate the types it defines.

One final question: is code deallocation safe? So, if function A in assembly
A' calls function B in assembly B' and you deallocate the appdomain
containing B' before calling A, do you get a nice exception or a nasty
access violation?

 

[Jon Skeet [C# MVP]]

One final question: is code deallocation safe? So, if function A in assembly
A' calls function B in assembly B' and you deallocate the appdomain
containing B' before calling A, do you get a nice exception or a nasty
access violation?

You'll get an AppDomainUnloadException.

Jon

 

[Jon Harrop]

You'll get an AppDomainUnloadException.

Ok.

Can you garbage collect generated code by putting it in an app domain and
wrapping the app domain in a class that uses a finalizer to explicitly
deallocate the app domain?

 

[Jon Skeet [C# MVP]]

Ok.

Can you garbage collect generated code by putting it in an app domain and
wrapping the app domain in a class that uses a finalizer to explicitly
deallocate the app domain?

I guess you probably could, yes.