|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
how to avoid inlining?I have some code which looks like that:
[DefaultValue(CornerStyle.Rounded)] public CornerStyle RectCornerMode { get { return this["RectCornerMode"].GetValue<CornerStyle>(); } set { this["RectCornerMode"].SetValue<CornerStyle>(value); } } in this[string] I get the attribute decorating the calling method, and used it to compute a default value. now it seems that sometimes (when build in release mode) the property is by passed and the calling method call this[string] and GetValue directly, thus ignoring the decorating attribute.... is there a way to avoid this inlining? any suggestion? found it: MethodImplAttribute.
Anyway I thought of a better solution... Show quote "Lloyd Dupont" <net.galador@ld> wrote in message news:ut8Yu2JiHHA.4680@TK2MSFTNGP06.phx.gbl... >I have some code which looks like that: > > [DefaultValue(CornerStyle.Rounded)] > public CornerStyle RectCornerMode > { > get { return this["RectCornerMode"].GetValue<CornerStyle>(); } > set { this["RectCornerMode"].SetValue<CornerStyle>(value); } > } > > > in this[string] I get the attribute decorating the calling method, and > used it to compute a default value. > now it seems that sometimes (when build in release mode) the property is > by passed and the calling method call this[string] and GetValue directly, > thus ignoring the decorating attribute.... > > is there a way to avoid this inlining? > any suggestion? > Make it virtual. JIT can't inline virtual calls (not quite sure if this is
"better solution" for you) Show quote "Lloyd Dupont" <net.galador@ld> wrote in message news:%23Pih%234JiHHA.872@TK2MSFTNGP03.phx.gbl... > found it: MethodImplAttribute. > Anyway I thought of a better solution... > > -- > Regards, > Lloyd Dupont > NovaMind Software > Mind Mapping at its best > www.nova-mind.com > "Lloyd Dupont" <net.galador@ld> wrote in message > news:ut8Yu2JiHHA.4680@TK2MSFTNGP06.phx.gbl... >>I have some code which looks like that: >> >> [DefaultValue(CornerStyle.Rounded)] >> public CornerStyle RectCornerMode >> { >> get { return this["RectCornerMode"].GetValue<CornerStyle>(); } >> set { this["RectCornerMode"].SetValue<CornerStyle>(value); } >> } >> >> >> in this[string] I get the attribute decorating the calling method, and >> used it to compute a default value. >> now it seems that sometimes (when build in release mode) the property is >> by passed and the calling method call this[string] and GetValue directly, >> thus ignoring the decorating attribute.... >> >> is there a way to avoid this inlining? >> any suggestion? >> > >Make it virtual. JIT can't inline virtual calls (not quite sure if this is Sounds like a horrible solution to me. Making a member virtual just to>"better solution" for you) achieve this side effect just seems wrong. You should only make a member virtual when it makes sense to do so and you're prepared to handle the fact that your code may be overridden and perhaps never run. Plus your code would break if a future version of the CLR (or some other runtime implementation) actually supported inlining virtual methods. Mattias -- Mattias Sjögren [C# MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup. Mattias,
That's exactly what I meant by stating "not quite sure if this is "better solution" for you". It's in fact a very bad "solution". Posted just to present another alternative to using the MethodImpl attribute which is the best solution to avoid inlining. Show quote "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message news:uncED8OiHHA.4984@TK2MSFTNGP06.phx.gbl... > >>Make it virtual. JIT can't inline virtual calls (not quite sure if this is >>"better solution" for you) > > Sounds like a horrible solution to me. Making a member virtual just to > achieve this side effect just seems wrong. You should only make a > member virtual when it makes sense to do so and you're prepared to > handle the fact that your code may be overridden and perhaps never > run. > > Plus your code would break if a future version of the CLR (or some > other runtime implementation) actually supported inlining virtual > methods. > > > Mattias > > -- > Mattias Sjögren [C# MVP] mattias @ mvps.org > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com > Please reply only to the newsgroup. Your class could inherit from MarshalByRefObject. This would also achive non
inlining and is the purpose of the class altogether. Regards Kjetil Kristoffer Solberg Show quote "Lloyd Dupont" <net.galador@ld> wrote in message news:ut8Yu2JiHHA.4680@TK2MSFTNGP06.phx.gbl... >I have some code which looks like that: > > [DefaultValue(CornerStyle.Rounded)] > public CornerStyle RectCornerMode > { > get { return this["RectCornerMode"].GetValue<CornerStyle>(); } > set { this["RectCornerMode"].SetValue<CornerStyle>(value); } > } > > > in this[string] I get the attribute decorating the calling method, and > used it to compute a default value. > now it seems that sometimes (when build in release mode) the property is > by passed and the calling method call this[string] and GetValue directly, > thus ignoring the decorating attribute.... > > is there a way to avoid this inlining? > any suggestion? > On May 4, 8:52 am, "KKS" <kks at synergi dot com> wrote: No, that's not the purpose of that class at all. The purpose of that> Your class could inherit from MarshalByRefObject. This would also achive non > inlining and is the purpose of the class altogether. class is to create a COM server object, which is anchored to the machine on which its running (that is, using the object from other computers will perform RPC calls to the server). Actually I'm not sure that inheriting that class will prevent inlining at all. The only good solution is the attribute mentioned above. Andy <an***@med-associates.com> wrote:
> On May 4, 8:52 am, "KKS" <kks at synergi dot com> wrote: I think that definition is too narrow as well. COM doesn't need to be > > Your class could inherit from MarshalByRefObject. This would also achive non > > inlining and is the purpose of the class altogether. > > No, that's not the purpose of that class at all. The purpose of that > class is to create a COM server object, which is anchored to the > machine on which its running (that is, using the object from other > computers will perform RPC calls to the server). involved anywhere. It just means (IMO) that when an instance needs to be marshalled across an AppDomain boundary - for whatever reason - the reference will be used, rather than creating a value copy of the object. > Actually I'm not sure that inheriting that class will prevent inlining I believe that it currently prevents inlining, but I haven't seen > at all. anything to actually specify that, or say that it will always be the case. > The only good solution is the attribute mentioned above. Agreed.-- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too On May 4, 10:01 am, Jon Skeet [C# MVP] <s***@pobox.com> wrote:
> I think that definition is too narrow as well. COM doesn't need to be Yes, you are right.> involved anywhere. It just means (IMO) that when an instance needs to > be marshalled across an AppDomain boundary - for whatever reason - the > reference will be used, rather than creating a value copy of the > object. > I believe that it currently prevents inlining, but I haven't seen Inlining is a compiler trick, isn't it? I didn't see anything on the> anything to actually specify that, or say that it will always be the > case. MBR class that would affect inlining, unless I'm missing it somewhere.. Andy <an***@med-associates.com> wrote:
<snip> > > I believe that it currently prevents inlining, but I haven't seen It's done by the JIT, not by the C# -> IL compiler. I don't know the > > anything to actually specify that, or say that it will always be the > > case. > > Inlining is a compiler trick, isn't it? I didn't see anything on the > MBR class that would affect inlining, unless I'm missing it somewhere.. details about why inlining doesn't take place, but I'm sure I've seen it in the past in other questions. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too You are mistaken.
The MarshalByRefObject has a bad name. It's primary purpose is to supress inlining by the JIT compiler so that the transparent proxy can do it's job. The JIT compiler checks to see if a class inherits from MarshalByRef object and don't inline if it does. Regards Kjetil Kristoffer Solberg Show quote "Andy" <an***@med-associates.com> wrote in message news:1178285450.176262.193190@y80g2000hsf.googlegroups.com... > On May 4, 8:52 am, "KKS" <kks at synergi dot com> wrote: >> Your class could inherit from MarshalByRefObject. This would also achive >> non >> inlining and is the purpose of the class altogether. > > No, that's not the purpose of that class at all. The purpose of that > class is to create a COM server object, which is anchored to the > machine on which its running (that is, using the object from other > computers will perform RPC calls to the server). > > Actually I'm not sure that inheriting that class will prevent inlining > at all. The only good solution is the attribute mentioned above. > On Mon, 07 May 2007 08:47:02 -0700, Kjetil
<"kjetil[ANTI-SPAM]"@kjetil.info> wrote: > You are mistaken. From the MSDN documentation for MarshalByRefObject:> > The MarshalByRefObject has a bad name. It's primary purpose is to > supress inlining by the JIT compiler so that the transparent proxy can > do it's job. Enables access to objects across application domain boundaries in applications that support remoting. There's nothing in there about inlining at all. In fact, on that page (http://msdn2.microsoft.com/en-us/library/system.marshalbyrefobject.aspx) there is no reference to inlining at all. You'd think that if the "primary purpose is to suppress inlining by the JIT compiler", some mention of inlining would show up *somewhere* in the documentation. I don't find the claim that MarshalByRefObject has as its primary purpose suppression of inlining is in any way credible. > The JIT compiler checks to see if a class inherits from MarshalByRef It may well be that the compiler special-cases the class inheritance and > object and don't inline if it does. that inlining doesn't happen for particular classes, like MarshalByRefObject. But that doesn't mean that's the purpose of inheriting from MarshalByRefObject. Pete You need to look at the broader picture. Where does MarshalByRefObject get
used? In scenarios like cross appdomain/process/machine method calls, you need a mechanism for transforming your stack based method call into some transportable format, transport the call, then transforming it back into stack based method calls in or on the target appdomain/process/machine, and the same back again. This is where the transparent proxy, real proxy and MarshalByRefObject objects come into the picture. In order for the transparent proxy to intercept all calls there needs to made sure that no inlining takes place. How could the transparent proxy transform a method call and send it to the real proxy if the JIT compiler inlined the method? It is here that MarshalByRefObject comes to the rescue. To ensure that all method calls are intercepted by the transparent proxy you inherit from MarshalByRefObject. Hope this makes things clearer. Regards Kjetil Kristoffer Solberg Show quote "Peter Duniho" <NpOeStPe***@nnowslpianmk.com> wrote in message news:op.trywqc0n8jd0ej@petes-computer.local... > On Mon, 07 May 2007 08:47:02 -0700, Kjetil > <"kjetil[ANTI-SPAM]"@kjetil.info> wrote: > >> You are mistaken. >> >> The MarshalByRefObject has a bad name. It's primary purpose is to >> supress inlining by the JIT compiler so that the transparent proxy can >> do it's job. > > From the MSDN documentation for MarshalByRefObject: > > Enables access to objects across application domain > boundaries in applications that support remoting. > > There's nothing in there about inlining at all. In fact, on that page > (http://msdn2.microsoft.com/en-us/library/system.marshalbyrefobject.aspx) > there is no reference to inlining at all. > > You'd think that if the "primary purpose is to suppress inlining by the > JIT compiler", some mention of inlining would show up *somewhere* in the > documentation. > > I don't find the claim that MarshalByRefObject has as its primary purpose > suppression of inlining is in any way credible. > >> The JIT compiler checks to see if a class inherits from MarshalByRef >> object and don't inline if it does. > > It may well be that the compiler special-cases the class inheritance and > that inlining doesn't happen for particular classes, like > MarshalByRefObject. But that doesn't mean that's the purpose of > inheriting from MarshalByRefObject. > > Pete On Mon, 07 May 2007 11:50:30 -0700, Kjetil
<"kjetil[ANTI-SPAM]"@kjetil.info> wrote: > You need to look at the broader picture. You need to read the documentation.A class derived from MarshalByRefObject inherits a LOT more than just suppression of inlining, and it's farcical to suggest that the primary purpose of deriving from that class is to suppress inlining, or even that deriving from that class is an appropriate way to suppress inlining in the general case, especially when there's a perfectly good attribute that can be applied to the function where inlining needs to be suppressed. Pete
Show quote
"Peter Duniho" <NpOeStPe***@nnowslpianmk.com> wrote in message You have to look at context. Whats the context of MarshalByRefObject? All news:op.try0dagd8jd0ej@petes-computer.local... > On Mon, 07 May 2007 11:50:30 -0700, Kjetil > <"kjetil[ANTI-SPAM]"@kjetil.info> wrote: > >> You need to look at the broader picture. > > You need to read the documentation. > > A class derived from MarshalByRefObject inherits a LOT more than just > suppression of inlining, and it's farcical to suggest that the primary > purpose of deriving from that class is to suppress inlining, or even that > deriving from that class is an appropriate way to suppress inlining in the > general case, especially when there's a perfectly good attribute that can > be applied to the function where inlining needs to be suppressed. > > Pete the members the object inherhits has to do with lifetime maintenace of the object in the context I describe, meaning that the argument that MarshalByRefObject's primary purpose is to supress inlining stands. The fact that it does not say so in MSDN is irrelevant. Again MarshalByRefObject is poorly named. Regards Kjetil Kristoffer Solberg Kjetil <kjetil[ANTI-SPAM]@kjetil.info> wrote:
> You need to look at the broader picture. Where does MarshalByRefObject get That says that preventing inlining is (currently) required in order to > used? In scenarios like cross appdomain/process/machine method calls, you > need a mechanism for transforming your stack based method call into some > transportable format, transport the call, then transforming it back into > stack based method calls in or on the target appdomain/process/machine, and > the same back again. This is where the transparent proxy, real proxy and > MarshalByRefObject objects come into the picture. In order for the > transparent proxy to intercept all calls there needs to made sure that no > inlining takes place. How could the transparent proxy transform a method > call and send it to the real proxy if the JIT compiler inlined the method? > It is here that MarshalByRefObject comes to the rescue. To ensure that all > method calls are intercepted by the transparent proxy you inherit from > MarshalByRefObject. Hope this makes things clearer. meet the primary purpose of MarshalByRefObject. That's *very* different from justifying your claim that the primary purpose of MarshalByRefObject *is* to prevent inlining. To make a comparison, imagine we were talking about ref parameters - it's necessary for the types to match exactly (instead of being able to pass a string for an object parameter, for example) - but it would be laugable to state that the primary purpose of ref parameters was to force people to use an argument of the *exact* type. Put it this way - consider someone who has decided to derive from MarshalByRefObject. When you ask them why they did so, do you think it's likely that they'll reply "To prevent inlining" or "To enable remoting/cross-app-domain calls (etc)"? -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too
Show quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message I do not see the comparison here at all. You have to look at this object news:MPG.20a98caf128e6f7d86@msnews.microsoft.com... > Kjetil <kjetil[ANTI-SPAM]@kjetil.info> wrote: >> You need to look at the broader picture. Where does MarshalByRefObject >> get >> used? In scenarios like cross appdomain/process/machine method calls, you >> need a mechanism for transforming your stack based method call into some >> transportable format, transport the call, then transforming it back into >> stack based method calls in or on the target appdomain/process/machine, >> and >> the same back again. This is where the transparent proxy, real proxy and >> MarshalByRefObject objects come into the picture. In order for the >> transparent proxy to intercept all calls there needs to made sure that no >> inlining takes place. How could the transparent proxy transform a method >> call and send it to the real proxy if the JIT compiler inlined the >> method? >> It is here that MarshalByRefObject comes to the rescue. To ensure that >> all >> method calls are intercepted by the transparent proxy you inherit from >> MarshalByRefObject. Hope this makes things clearer. > > That says that preventing inlining is (currently) required in order to > meet the primary purpose of MarshalByRefObject. That's *very* different > from justifying your claim that the primary purpose of > MarshalByRefObject *is* to prevent inlining. > > To make a comparison, imagine we were talking about ref parameters - > it's necessary for the types to match exactly (instead of being able to > pass a string for an object parameter, for example) - but it would be > laugable to state that the primary purpose of ref parameters was to > force people to use an argument of the *exact* type. > > > Put it this way - consider someone who has decided to derive from > MarshalByRefObject. When you ask them why they did so, do you think > it's likely that they'll reply "To prevent inlining" or "To enable > remoting/cross-app-domain calls (etc)"? > from the context in which it is to be used. You need an object that can supress inlining for the communications model to work. This is what MarshalByRefObject is all about. The lifetime services is secondary. Regards Kjetil Kristoffer Solberg Kjetil <kjetil[ANTI-SPAM]@kjetil.info> wrote:
> > Put it this way - consider someone who has decided to derive from Yes, you need to suppress inlining - but more importantly, you need the > > MarshalByRefObject. When you ask them why they did so, do you think > > it's likely that they'll reply "To prevent inlining" or "To enable > > remoting/cross-app-domain calls (etc)"? > I do not see the comparison here at all. You have to look at this object > from the context in which it is to be used. You need an object that can > supress inlining for the communications model to work. This is what > MarshalByRefObject is all about. The lifetime services is secondary. reference to be marshalled rather than the value. Surely *that* is the primary purpose of the type. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message Again it comes down to context. If your context is I have an object and I news:MPG.20a997ae520df4ac89@msnews.microsoft.com... > Yes, you need to suppress inlining - but more importantly, you need the > reference to be marshalled rather than the value. Surely *that* is the > primary purpose of the type. > need to marshall it across an appdomain, then you will think that is the primary purpose of the type. If your context is how that architecture works then you will think in terms of why that class is there in that context. Regards Kjetil Kristoffer Solberg I think it's much more simple.
MarshalByRef subclass's method might not be implemented at all, but this is an unintended side effect. Something that cannot be relied on because it might change without notice. If you use it for this purpose your code might break again in the future, for some 'apparently mysterious' reason.... (i.e. upgrading to .NET 4/5/6/other...) Whereas with the attribute: this is the purpose of it and won't be changed. Show quote "Kjetil" <kjetil[ANTI-SPAM]@kjetil.info> wrote in message news:u7MmhrTkHHA.4852@TK2MSFTNGP03.phx.gbl... > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message > news:MPG.20a997ae520df4ac89@msnews.microsoft.com... >> Yes, you need to suppress inlining - but more importantly, you need the >> reference to be marshalled rather than the value. Surely *that* is the >> primary purpose of the type. >> > Again it comes down to context. If your context is I have an object and I > need to marshall it across an appdomain, then you will think that is the > primary purpose of the type. If your context is how that architecture > works then you will think in terms of why that class is there in that > context. > > Regards > Kjetil Kristoffer Solberg > Kjetil <kjetil[ANTI-SPAM]@kjetil.info> wrote:
> "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message I don't think that really makes sense as a way of thinking about the > news:MPG.20a997ae520df4ac89@msnews.microsoft.com... > > Yes, you need to suppress inlining - but more importantly, you need the > > reference to be marshalled rather than the value. Surely *that* is the > > primary purpose of the type. > > Again it comes down to context. If your context is I have an object and I > need to marshall it across an appdomain, then you will think that is the > primary purpose of the type. If your context is how that architecture works > then you will think in terms of why that class is there in that context. primary purpose of a type. "How it works" (i.e. the implementation) isn't the *reason* for a type existing. Surely a good test for the primary purpose of a type is to see whether or not it would still be worth having if that purpose weren't required. Let's test that theory: Suppose marshalling by reference didn't require inlining to be avoided - for example if the CLR didn't do any inlining anyway. Would MarshalByRefObject still be worth having? Absolutely. Admittedly in this case it could be replaced by an attribute, potentially, as described in http://blogs.thinktecture.com/ingo/archive/2003/01/24/413866.aspx You'd still need something to indicate that you wanted marshalling by reference though, and deriving from MarshalByRefObject is currently *the* way of doing that. Now suppose instead that no-one ever needed to marshal by reference, but occasionally did want to prevent inlining. Would MarshalByRefObject still be worth having? Nope - MethodImplOptions already has that functionality. For these reasons, I still think it makes little sense to claim that the primary purpose of the MarshalByRefObject type is to prevent inlining. That may well be a very important part of its implementation, but that's not the same thing at all. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message If the transparent proxy can be bypassed by inlining then there would be no news:MPG.20aac7e0b7be44af9a@msnews.microsoft.com... > I don't think that really makes sense as a way of thinking about the > primary purpose of a type. "How it works" (i.e. the implementation) > isn't the *reason* for a type existing. way for this communications architecture to work. Don't you think ensuring this architecture works is the primary purpose behind MarshalByRefObject? Show quote > Please lets argue based on the facts.> Surely a good test for the primary purpose of a type is to see whether > or not it would still be worth having if that purpose weren't required. > Let's test that theory: > > Suppose marshalling by reference didn't require inlining to be avoided > - for example if the CLR didn't do any inlining anyway. Would > MarshalByRefObject still be worth having? Absolutely. Admittedly in > this case it could be replaced by an attribute, potentially, as > described in > http://blogs.thinktecture.com/ingo/archive/2003/01/24/413866.aspx > You'd still need something to indicate that you wanted marshalling by > reference though, and deriving from MarshalByRefObject is currently > *the* way of doing that. > > The problem with MethodImplOptions is that anyone relying on all the methods > Now suppose instead that no-one ever needed to marshal by reference, > but occasionally did want to prevent inlining. Would MarshalByRefObject > still be worth having? Nope - MethodImplOptions already has that > functionality. > of a class to be inlined is now dependent upon the developer of the type to actually set this attribute on all the methods. A descent architecture in my opinion should not be dependent in this way upon the individual programmer. MarshalByRefObject solves this problem and as such still worth having. > I disagree. The most important reason behind MarshalByRefObject is > For these reasons, I still think it makes little sense to claim that > the primary purpose of the MarshalByRefObject type is to prevent > inlining. That may well be a very important part of its implementation, > but that's not the same thing at all. > suppression of inlining. Lifetime management is also important but secondary. Regards Kjetil Kristoffer Solberg "KKS" <kks at synergi dot com> wrote in message This should read like this:news:eKLxtyhkHHA.3452@TK2MSFTNGP04.phx.gbl... > The problem with MethodImplOptions is that anyone relying on all the > methods of a class to be inlined is now dependent upon the developer of > the type to actually set this attribute on all the methods. A descent > architecture in my opinion should not be dependent in this way upon the > individual programmer. MarshalByRefObject solves this problem and as such > still worth having. > The problem with MethodImplOptions is that anyone relying on all the methods of a class *not* to be inlined is now dependent upon the developer of the type to actually set this attribute on all the methods. A descent architecture in my opinion should not be dependent in this way upon the individual programmer. MarshalByRefObject solves this problem and as such still worth having. Sorry for the typo. Regards Kjetil Kristoffer Solberg <"KKS" <kks at synergi dot com>> wrote: Making sure that the architecture works is what MarshalByRefObject has > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message > news:MPG.20aac7e0b7be44af9a@msnews.microsoft.com... > > I don't think that really makes sense as a way of thinking about the > > primary purpose of a type. "How it works" (i.e. the implementation) > > isn't the *reason* for a type existing. > If the transparent proxy can be bypassed by inlining then there would be no > way for this communications architecture to work. Don't you think ensuring > this architecture works is the primary purpose behind MarshalByRefObject? to do in order to fulfil its primary purpose of making it possible to marshal objects by reference Show quote > > Surely a good test for the primary purpose of a type is to see whether What exactly are you taking issue with? I don't see what's wrong with > > or not it would still be worth having if that purpose weren't required. > > Let's test that theory: > > > > Suppose marshalling by reference didn't require inlining to be avoided > > - for example if the CLR didn't do any inlining anyway. Would > > MarshalByRefObject still be worth having? Absolutely. Admittedly in > > this case it could be replaced by an attribute, potentially, as > > described in > > http://blogs.thinktecture.com/ingo/archive/2003/01/24/413866.aspx > > You'd still need something to indicate that you wanted marshalling by > > reference though, and deriving from MarshalByRefObject is currently > > *the* way of doing that. > Please lets argue based on the facts. considering a hypothetical situation. > > Now suppose instead that no-one ever needed to marshal by reference, If preventing inlining weren't necessary for marshalling by reference, > > but occasionally did want to prevent inlining. Would MarshalByRefObject > > still be worth having? Nope - MethodImplOptions already has that > > functionality. > The problem with MethodImplOptions is that anyone relying on all the methods > of a class to be inlined is now dependent upon the developer of the type to > actually set this attribute on all the methods. A descent architecture in my > opinion should not be dependent in this way upon the individual programmer. > MarshalByRefObject solves this problem and as such still worth having. can you think of any other examples where you would really want to prevent *all* methods in a type from being inlined? > > For these reasons, I still think it makes little sense to claim that The most important *implementation detail* of MarshalByRefObject may > > the primary purpose of the MarshalByRefObject type is to prevent > > inlining. That may well be a very important part of its implementation, > > but that's not the same thing at all. > > I disagree. The most important reason behind MarshalByRefObject is > suppression of inlining. Lifetime management is also important but > secondary. well be suppression of inlining, but that's not the same as it being the reason it exists in the first place. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too On May 7, 11:47 am, "Kjetil" <kjetil[ANTI-SPAM]@kjetil.info> wrote: Interesting how nowhere in the MarshalByRefObject MSDN pages does it> You are mistaken. > > The MarshalByRefObject has a bad name. It's primary purpose is to supress > inlining by the JIT compiler so that the transparent proxy can do it's job. > The JIT compiler checks to see if a class inherits from MarshalByRef object > and don't inline if it does. state this. In fact, it directly supports what Jon says.  |
|||||||||||||||||||||||
Other interesting topics