Yeah, I think most people are using some sort of automator, and I don't see
many variations on what the gen'd code should look like, so it seems ripe
for formalization - unless there would be side effects. Another option would
be to have blank get/set methods automatically insert that code, kind
Simon Robinson's 'Advanced .NET Programming' begins with a few very good
chapters on IL.
Mike.
--
Michael Iles
Deploy and Manage Enterprise-class Windows Forms Apps with Kinitos
-Original Message-
From: Jeff Varszegi
Sent: October 21, 2003 10:40 AM
To: [EMAIL PROTECTED]
Subject: Re:
This is a repost from the CLR/CX list, perhaps it is a better place for
it, since no one was able to comment...
Hi Listers,
I was wondering if anyone has created a Shared Add-In that is loaded by
Excel in which you can input a function into a cell (i.e.
=SomeFunction( A1, A2 ) ). That function
Simple get/set properties are (almost) always inlined-- use windbg with
SOS and disassemble a method with a property access vs. a field access
to observe this. That is why replacing simple properties with fields is
probably of marginal performance benefit.
Dominic Cooney
Jeff Varszegi wrote:
You're mostly smoking crack. The JIT compiler knows how to inline
trivial get/set methods.
However, there's nothing wrong with this approach. In the future,
optimizers may be able to make better use of readonly hints, to reduce
pointer dereferencing, etc. But for now, yeah, there is no real
Provide performance data that backs this up, before saying there can be
quite a performance penalty.
Speculation is not data. Debug builds are not release builds.
-- arlie
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Urs
Jeff,
[...] Also, what's the relative cost of a property
get/set versus a method invocation?
There is no such cost, i.e. the notion of properties only exists on the
metadata level --- runtime there is no difference between method
invocation and calling a property's getter or setter.
P.S. I
There are questions about whether Remoting should ever cross machine
boundaries. This questions about this are amplified when the use of
Remoting events.
Clemens Vasters has a great set of slides on how to make the kinds of
decisions and how to organize your code here:
Hi All,
I am getting the following error on my App Server in COM+ :
Error Details:
The system has called a custom component and that component has failed and
generated an exception. This indicates a problem with the custom component.
Notify the developer of this component that a
The only advice I have Is don't use events in dotnet remoting..
Check out this website for more info..
http://www.ingorammer.com/RemotingFAQ/RemotingUseCases.html
Regards
Daniel
-Original Message-
From: Colesy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 21 October 2003 2:37 p.m.
To:
Many thanks for your reply Mark. I can avoid callbacks using
begin/endinvoke and polling for returned messages but I definitely need
events, even if I scale down the app would events and remoting still cause
problems for me? would you recommend working with sockets directly or
looking at say MSMQ
Thanks for the link Ernest - I am definitely discarding web services as an
option here but would you recommend remoting, working with the sockets,
Message Queueing or using EnterpriseServices? What experiences have you had
with any of these?
Cheers
===
This list is
I know that when using properties there are a lot of read only (get
accessor only) properties which would be useful to have auto-generated
for me. Think of the Count property in a collection. Internally it's
read/write but externally the property has a get accessor only.
Having a short-hand way
Rule 01 only in the rarest of occasions should you use public fields in any
object..
It breaks the rules of encapsulation and data hiding,
It also does not allow any data validation entering the object.
I know it can be tedious writing properties for all fields but a good habit
to get into.
I
Actually I think it's a good rule of thumb full stop.
There is no performance penalty between calling public member variables and
accessing them through properties.
The only performance penalty is on your fingers, writing properties can be
very tedious work.
Enclosed is my example of the IL
I have a windows service that acts as a .NET Remoting listener for incoming
requests from remote clients. I verified that the listener does actually use
the thread pool to service client requests. Now, given the fact that there are
(by default) only 25 threads available in each CPU's thread pool,
Actually there is no performance penalty using property vs using public
field
Enclosed is my example of il code produced first using property, and next
using public variable.
Regards
Daniel
// using property
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
Timeto step in.
No, first Ingo Rammer :-)
What he says in his document about Events in Removting is right, or
utter bullshit, depending on how you look at it.
It is absoltuly correct - they scale bad, have a ton of intrinsic
problems etc., but this is not so much a remoting problem, but a
Look at how ASP.NET works.
ASP.NET also has only a limited number of threads, and still it manages
to handl way more connnected clients.
The same principles apply with remoting.
Thomas Tomiczek
THONA Software Consulting Ltd.
(Microsoft MVP C#/.NET
-Original Message-
From: Moderated
It breaks the rules of encapsulation and data hiding,
If all you are doing is setting a private field and reading it and it is the
same type (as per the example posted) you are not hiding or encapsulating
anything but instead compromising for the fact the .NET environment will
break binary
in both 1.0 and 1.1 if you have 1 Processor:
- method execution is serialized at server side
- you only have concurrency if the server thread associated with the
remote call gets into a sleeping stage.
to solve the problem you can dispatch the execution to a second thread
with
Yazan
If you haven't read Ingo Rammer's book on remoting by all means you'll want
to get it.
What we found in our stress testing was that for a SAO object the
implementor only sees a single thread. The remoting framework handles the
connection/socket threads. Try as we might we could not swamp
Sorry my previous post may have been incorrect. I think i got confused with
something i read. I think it goes that there is no performance penality
using proporties over methods to set member fields because internally the
complier turns them into methods anyway.
However in saying that i tried
Here is a more in-depth discussion of using Remoting events across machine
boundaries from another source that was linked to earlier:
No matter which category your application belongs to, I heavily recommend
NOT to use events, callbacks or client-side sponsors for networked
applications. Yes,
Hey folks,
Can anyone think of a reason why the constraints syntax is this:
public class DictionaryKeyType, ValType where KeyType : IComparable
rather than this:
public class DictionaryKeyType : IComparable, ValType
?
The former adds an additional (unreserved?) keyword to the language and
Because you can't represent multiple constraints in the one-liner since
commas are already used to separate KeyType and ValType:
public class DictionaryKeyType, ValType
where KeyType: IComparable, IEnumerable, ISomethingElse
adam..
-Original Message-
From: Moderated discussion of
I'd say readability first, personally. It'd be alot easier to read
public class DictionaryKeyType,ValType where KeyType : IComparable,
ICollection, IAnotherThing, ValueType : IComparable, IDictionaryValue,
IAnotherRestriction
than
public class DictionaryKeyType : IComparable, ICollection,
27 matches
Mail list logo
