|
P: n/a
|
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?
| |
Share this Question
|
P: n/a
|
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@ldwrote in message
news:ut**************@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?
| |
|
P: n/a
|
Make it virtual. JIT can't inline virtual calls (not quite sure if this is
"better solution" for you)
"Lloyd Dupont" <net.galador@ldwrote in message
news:%2*****************@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@ldwrote in message
news:ut**************@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?
| |
|
P: n/a
|
>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. | |
|
P: n/a
|
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.
"Mattias Sjögren" <ma********************@mvps.orgwrote in message
news:un**************@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.
| |
|
P: n/a
|
Your class could inherit from MarshalByRefObject. This would also achive non
inlining and is the purpose of the class altogether.
Regards
Kjetil Kristoffer Solberg
"Lloyd Dupont" <net.galador@ldwrote in message
news:ut**************@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?
| |
|
P: n/a
|
On May 4, 8:52 am, "KKS" <kks at synergi dot comwrote:
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. | |
|
P: n/a
|
Andy <an***@med-associates.comwrote:
On May 4, 8:52 am, "KKS" <kks at synergi dot comwrote:
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).
I think that definition is too narrow as well. COM doesn't need to be
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
at all.
I believe that it currently prevents inlining, but I haven't seen
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 | |
|
P: n/a
|
On May 4, 10:01 am, Jon Skeet [C# MVP] <s...@pobox.comwrote:
I think that definition is too narrow as well. COM doesn't need to be
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.
Yes, you are right.
I believe that it currently prevents inlining, but I haven't seen
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.. | |
|
P: n/a
|
Andy <an***@med-associates.comwrote:
<snip>
I believe that it currently prevents inlining, but I haven't seen
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..
It's done by the JIT, not by the C# -IL compiler. I don't know the
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 | |
|
P: n/a
|
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
"Andy" <an***@med-associates.comwrote in message
news:11**********************@y80g2000hsf.googlegr oups.com...
On May 4, 8:52 am, "KKS" <kks at synergi dot comwrote:
>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.
| |
|
P: n/a
|
On Mon, 07 May 2007 08:47:02 -0700, Kjetil
<"kjetil[ANTI-SPAM]"@kjetil.infowrote:
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/lib...refobject.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 | |
|
P: n/a
|
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
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Mon, 07 May 2007 08:47:02 -0700, Kjetil
<"kjetil[ANTI-SPAM]"@kjetil.infowrote:
>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/lib...refobject.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
| |
|
P: n/a
|
On Mon, 07 May 2007 11:50:30 -0700, Kjetil
<"kjetil[ANTI-SPAM]"@kjetil.infowrote:
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 | |
|
P: n/a
|
Kjetil <kjetil[ANTI-SPAM]@kjetil.infowrote:
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)"?
--
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 | |
|
P: n/a
|
On May 7, 11:47 am, "Kjetil" <kjetil[ANTI-SPAM]@kjetil.infowrote:
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.
Interesting how nowhere in the MarshalByRefObject MSDN pages does it
state this. In fact, it directly supports what Jon says. | | This discussion thread is closed Replies have been disabled for this discussion. | |  Question stats - viewed: 2363
- replies: 15
- date asked: Apr 27 '07
|
