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...

--
Regards,
Lloyd Dupont
NovaMind Software
Mind Mapping at its best
www.nova-mind.com
"Lloyd Dupont" <net.galador@ld> wrote in message
news:(E-Mail Removed)...
>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)

"Lloyd Dupont" <net.galador@ld> wrote in message
news:%23Pih%(E-Mail Removed)...
> 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:(E-Mail Removed)...
>>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)

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.

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
>>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


"Lloyd Dupont" <net.galador@ld> wrote in message
news:(E-Mail Removed)...
>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:
> 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.

Andy <(E-Mail Removed)> wrote:
> 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).

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 - <(E-Mail Removed)>
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
> 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..

Andy <(E-Mail Removed)> wrote:

<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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too