none
Struct or class for co-ordinates? RRS feed

  • Question

  • Hi all,

    I am coding a small piece of software and need to represent co-ordinates on a (small) grid. There aren't many references to the co-ordinates in the code (though this is vital information to the working of the application).

    Should this be a struct or class? It represents atomic data (i.e. a point), but can change (is mutable). However, you can argue that the co-ordinate does not "change" per-se, but you get new co-ordinates.

    Any clarification on what to go for is much appreciated.

     

    Thanks

    Saturday, January 14, 2012 7:22 PM

Answers

  • Hello,

    You can use Tuples to do that, depends on the scenario.

    @AlijodAv, the following do not make any sense.

    There will be no overhead; in fact there will overhead if you do not pass the reference to the object (in this case, theoretically, there will be a copy first).
    What ?
    The value types are declared inside a class; therefore, there won't be any value type on the stack.

    How do you know that ? did you happen to pop in when a value type is allocated and asked the JIT where it's going to allocate it ? it's an implementation detail, not really something that is guaranteed to happen.

    P.s. You should read carefully because the above replies are really out of context, you took something he wrote and answered a part in his post. ;)


    Eyal (http://shilony.net), Regards.

    Sunday, January 15, 2012 10:52 AM
    Moderator

All replies

  • In addition to the others; Of course is using is using a Point (there are more classes with the same name  depending for what you use it but have the same content) the best approach.

    However, some have written on Internet that a struct is a lightweight class; that is only if it contains less than 16 bytes if it is more it is exactly the opposite.


    Success
    Cor
    Sunday, January 15, 2012 9:37 AM
  • Hello,

    You can use Tuples to do that, depends on the scenario.

    @AlijodAv, the following do not make any sense.

    There will be no overhead; in fact there will overhead if you do not pass the reference to the object (in this case, theoretically, there will be a copy first).
    What ?
    The value types are declared inside a class; therefore, there won't be any value type on the stack.

    How do you know that ? did you happen to pop in when a value type is allocated and asked the JIT where it's going to allocate it ? it's an implementation detail, not really something that is guaranteed to happen.

    P.s. You should read carefully because the above replies are really out of context, you took something he wrote and answered a part in his post. ;)


    Eyal (http://shilony.net), Regards.

    Sunday, January 15, 2012 10:52 AM
    Moderator
  • I know that because I know the difference between a Value type declared in a struct and a Value type declared in a class. I read the C# language specification.

    Hmm I read the spec long time ago not sure I seen it there, the point I wanted to make is that it simply doesn't matter where things are stored because you don't really get to decide anything at the allocation level.

    No, they are in the context, and I didn't take just something... . Read, carefully, my post. I pointed out 4 different parts of a post with misconceptions.
    Probably read someone else's post, I'll read carefully this time. :)

    Eyal (http://shilony.net), Regards.

    Monday, January 16, 2012 3:03 AM
    Moderator
  • @ carlighter

    ... That does not make in my idea direct everything an object in the broadest meaning of that word ...

    As you said, it's your personal idea. Also, it's not the broadest meaning; it's the shortest meaning. In OOP world, programmers deal with objects, although some programmers want to treat Value types as second class entities. Unconsciously, you recognized what I've stated clearly, when you wrote:

    ... in C# (in fact .Net) everything is deriving from the class Object. ...

    Also, a struct is not a lightweight class; this is a idea that many like you have, that shows you don't really understand how memory is set up for the objects created. People that come to this forum, must learn correct conceptions, otherwise in the (near) future they will be spreading wrong misconceptions as you are doing now. Believe me, it's very hard to change misconceptions in people that learn(?) without reading the language specification (I bet you have read it many times).

    So you want to give the OP the idea that a struct is like objects put on the managed heap. No it is not it is put on the stack.

    Also don't quote me in an opposite direction. A struct is not a lightweight class and I've never written that,  simply for the reason above. However, because that putting an object on the stack takes reference space, that space can for the same be used to store the value in a struct (therefore that 16bytes).

    I get the idea you read to much from Internet and takes everything you read the first time as the truth, try to investigate what persons write in a deeper way.  

    (Be aware that a value type is deriving from the Class Object).


    Success
    Cor


    Monday, January 16, 2012 9:13 AM
  • But, I must say that conceptually, programmers do decide about those int objects allocation. I.e., until the IL code generation, everythingis in programmers' hands.

    Sorry, I have to disagree here, conceptually ? what does it even mean ? you deal with facts not with theories, so virtually you don't, the only minor control you do have is over methods, at least currently.

    You might think that it will put something on the heap but out of optimization reason it might do the opposite or even use a register instead to push the value.

    You can't just tell it okay Mr. Jitter put it there because I want it there, you don't really have a choice, that's my point and I think that, that's the point of having a managed world to begin with.

    You can't prove it because you will have to take every processor, operating system and condition into account while turning JIT optimization on production builds.

    I'm enjoying this discussion, I'm all for learning. :)

    P.s. If a moderator can split the post into a separate discussion it will be nice.


    Eyal (http://shilony.net), Regards.


    Saturday, January 21, 2012 1:26 PM
    Moderator
  • I wrote this: In C#, everything is an object, because System.Object is the topmost base class for every type, ...


    Since you said that "People that come to this forum, must learn correct conceptions, otherwise in the (near) future they will be spreading wrong misconceptions as you are doing now." I must correct your sentence.

    The correct one is: "In C# every class derives from System.Object". Interfaces don't derive from System.Object. Pointers don't derive from System.Object. Also, the null value doesn't have a type. And methods neither. They derive from nothing.

    Monday, January 23, 2012 12:56 PM
  • @Louis, I don't think he referred to types defined by the CTS just classes/structs but yeah he did bother to add "every" so yeah. ;)
    Eyal (http://shilony.net), Regards.
    Monday, January 23, 2012 2:02 PM
    Moderator
  • Consequently, struct is an object; but it is a Value type object, therefore, it is allocated on the stack!

    That's incorrect, that's an implementation detail let's go and ask someone on the C# compiler team.

    1. The Truth About Value Types
    2. The Stack Is An Implementation Detail, Part One
    A struct is not a lightweight class; this is a idea that many like you have, that shows you don't really understand how memory is set up for the objects created. A struct is a Value type, and a class is not Value type.

    You don't need to know how things are set up in memory to know the differences between a struct and a class.

    I read C# language specification version 4.0. It's not an easy reading... I am critical enough to differentiate good from bad; considering the misconceptions you acquired, you're not the most suitable to give advices.

    I can see it's a really hard read.

    What makes you suitable ? you clearly think that Value Types goes to the stack.


    Eyal (http://shilony.net), Regards.

    Monday, January 23, 2012 3:05 PM
    Moderator
  • @Louis, I don't think he referred to types defined by the CTS just classes/structs but yeah he did bother to add "every" so yeah. ;)


    I'm referring to types as defined in the C# language specification version 4.0, which he has read.

    §13.2 Interface members: "Note that the members in class object are not, strictly speaking, members of any interface."

    Maybe the specification is where the error comes from, as it erroneously states, at the start of chapter 4 "Every type in C# directly or indirectly derives from the object class type, and object is the ultimate base class of all types." I never realised it was there, and I now understand why it is also stated in a popular C# book.

    Monday, January 23, 2012 4:46 PM
  • Yes.
    Already reported as abusive
    Monday, January 23, 2012 4:57 PM
  • @Louis, I see, that's quite vague and weird.


    Eyal (http://shilony.net), Regards.

    Monday, January 23, 2012 5:23 PM
    Moderator
  • think about this code:

    static void Main(string[] args)
    {
        IEnumerable<int> e = new int[] { 1, 2, 3, };
        Console.WriteLine(e.GetType());
        object o = e;
        Console.WriteLine(o.GetType());
    }
    

     It only proves that "the members in class object are available via member lookup in any interface type" (§13.2). The compiler knows that it is safe to call it because every object you have referenced by the 'e' variable has a concrete type. Look at the result of the GetType call, and you'll see that it is the int[] type, not IEnumerable<int>. Check typeof(IEnumerable<int>).BaseType to know if it derives from object. 



    think, also, about this code:

    unsafe static void Main(string[] args)
    {
        double d = 123.456e23;
        unsafe
        {
            byte* pb = (byte*)&d;
            Console.WriteLine(pb->GetType());
            object o = *pb;
            Console.WriteLine(o.GetType());
    
            int* pi = (int*)&d;
            Console.WriteLine(pi->GetType());
            object o2 = *pi;
            Console.WriteLine(o2.GetType());
        }
    }
    
    

    Here, you never call the GetType method on the variables 'pb' or 'pi', but on what they point to. The result of the GetType method tells you that. You can also check typeof(int*).BaseType to know if it derives from object.


    just one more to think about:

    static void Main(string[] args)
    {
        Console.WriteLine(1.ToString());
        Console.WriteLine(((int?)null).ToString());
        Console.WriteLine(3.ToString());
    }
    
    


    That's ok. Int32 derives from Object and Nullable<int> does too.
    Monday, January 30, 2012 1:23 PM
  • The documentation says that to obtain the run time type of an expression, use object.GetType() (I do).

    If you say that all types obtainable through GetType derive from Object. Then, you're right, since you cannot obtain an interface type that way. But there are other types, such as interface types or pointer types, and those don't inherit from Object.

    You can call all Object's methods through an expression statically typed as an interface as a commodity provided by the CLR and by C#. It's possible because every value resulting from the evaluation of an expression will, if not null, derive from Object. In other words, its runtime type will never be an interface.

    From the CLI documentation §8.9.4: "An interface type is a named group of methods, locations, and other contracts that shall be implemented by any object type that supports the interface contract of the same name. An interface definition is always an incomplete description of a value, and, as such, can never define a class type or an exact type, nor can it be an object type."

    Tuesday, January 31, 2012 4:36 PM
  • Look at your code: you are using typeof() which tells you about static definitions (at compile time).

    If you know another way to get the Type object for an interface, please tell me. We'll then examine its BaseClass property and see that it's null.

    The way C# implements the derivation at run time (any code only makes sense at run time), is the C# way!

    C# doesn't do anything at runtime. It's long been compiled to IL at that time, then JIT compiled.

    But you are blind to the evidences that interfaces are derived from System.Object.

    Please show me where you've seen that interfaces derive from Object. It's possible that I'm wrong, but I need some kind of proof. Up to now, you only demonstrated that objects derive from Object, and I agree with that.

    Tuesday, January 31, 2012 4:44 PM
  • I am not aware that interfaces derive from System.Object.  If anything, an interface offers you a "filtered view" of an object instance.  It is a view that offers only specific behaviors and characteristics of the object instance.  The entire object instance remains intact, unchanged.  But the appearance of an object instance "through the interface" is a filtered one.

    http://msdn.microsoft.com/en-us/library/aa288461(v=vs.71).aspx

    It is almost as if an interface variable behaves an alias variable for select portions of an object instance.  The interface defines what is selected.

    Rudy   =8^D


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/

    Wednesday, February 1, 2012 12:48 AM
    Moderator
  • The interface is always "glued" to the 1, only 1 System.Object created. In this case it's an array type.
    Look at, again, at the code above: there's only 1 System.Object created; therefore object.GetType() will return the same value for any reference to the object instantiated:

    I do not understand the term "glued" what does it mean ?

    An interface has a definition at run-time much like a class that has its own.

    I suggest you to read this article. Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects

    Read the section of MethodTable downward that should explain you how wrong you are.

    Speaking about misconceptions and accuracy I'd use a better term than 'array type' to describe it like hierarchy of types.

    C# is not a static language

    C# is definitely a statically typed language!

    But you are blind to the evidences that interfaces are derived from System.Object. Everything (in the context of types, because I'm talking about types) is derived from System.Object.

    Interfaces as defined by the CTS in the CLI that being read by the CLR are definitely not derived from System.Object!

    If you refer to types as a synonym to a class then indeed all classes are derived from System.Object.

    Here is the evidence Common Type System.


    Eyal (http://shilony.net), Regards.
    Wednesday, February 1, 2012 8:37 PM
    Moderator
  • If you know another way to get the Type object for an interface, please tell me. We'll then examine its BaseClass property and see that it's null

    You should know the basics of C#. Read the documentation for typeof() and it'll tell you what you want.

    You're funny. I used typeof and you said it wasn't good enough.

    C# doesn't do anything at runtime...

    LOL... this is the most ridiculous statement. Probably, that's the reason your C# programs don't run as you expect. LOL...

    You never compile your programs? That explains a lot.

    Please show me where you've seen that interfaces derive from Object.

    You're never gonna learm. It's already explained and you yourself found in the language specification.

    Interfaces not being derived from Object is stated in the CLR documentation and contradictory in the C# documentation. The problem is the C# documentation uses the simple word "type" alternatively for the type of a variable or expression (this type can be an interface) and for the effective type of an object (which cannot be an interface).

     Up to now, you only demonstrated that objects derive from Object, and I agree with that

    You don't know what objects are,because this word has multiple usage.

    We're talking about C#, so it doesn't have a lot of usages. System.Object is a class, base class of all other classees. object is a keyword, alias for System.Object. An object is an instance of a class.

    I have shown to you that people that comes to this forum get answers from mcc's that are completely wrong, as stated in C# language specification version 4.0. And you are one of them, and when your (mis)conception conflicts with this language specification, you say it is wrong and not you. It' a shame that in this forum the language specification is totally ignored, mainly by the mvp. You created your personal-C#-specification.

    On the contrary, I follow the Microsoft C#, described in C# language specification version 4.0 and MSDN.

    When facts contradict the documentation, either the documentation is wrong, or the implementation is wrong. Both already happened in the past. In this case, it is ambiguous in its use of the word "type". It is not however ambiguous about the inheritance of interfaces. For example, it states that members in class object are not members of any interface. What would then exactly mean the sentence "interfaces inherit from Object"?

    I did my best, but you are never gonna learn. The Intellisense is for you much more interesting than reading documents.

    Reading the documentation is a very good thing. I know, I have read it. But it's not an end. It's because I work with the language, and because I experimented with it, that I can tell you that there is something wrong in the documentation. As stated here by someone more involved than me in the specification of C#, "The way to correct this myth is to simply replace 'derives from' with 'is convertible to', and to ignore pointer types: every non-pointer type in C# is convertible to object."

    This is the end for me in this thread.

    I'm sorry if it is, because I had hope you would learn something from experience (like actually running the sample I wrote earlier) instead of playing doctus cum libro.

    Monday, February 6, 2012 3:19 PM
  • You're very funny. I keep laughing when reading your tech knowledge. Since the 1st post you show you don't follow Microsoft C#, but just your personal concept of what C# should be in your opinion. Unfortunately for you, Microsoft C# is different than what you guess. You don't know the difference between struct and class, therefore you don't know how C# treats value types declared inside one and inside the other. You hide your lack of knowledge behind the jitter. :)

    Thank you, just don't die laughing that would be a tragedy for us all.

    Only on your personal-C#-language :). You must read more; start by C# Language Specification version 4 section 3.4.5 - Interface members. In an interface, all members are implicitly abstract, and the same interface can be declared in many places inside an object with different implementations, and the definitions are not inside the interfaces. So, interfaces cannot be like a class. You are funny guy. :)

    Thank you for the advice, I'll consider that, meanwhile, you can start by reading the CLI specification.

    LOL... start explaining how Dynamic Binding can resolve types et al at compile time! :)

    Haha... dynamic binding is resolved at run-time by the DLR, never at compile-time.

    ROFL... look for 
    "The first four methods of any type will always be ToString, Equals, GetHashCode, and Finalize. These are virtual methods inherited from System.Object"
    in  Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects
    This is the link you gave me, but didn't read! You're funny guy ... ROFL
    More, I can show to you a link in MSDN that states clearly that interfaces are derived from System.Object, but I'm gonna let this for you yourself look for it. :) I assure to you that the information is there in MSDN.

    The author really sees this as a synonym to a class not just any type, unfortunately you can't/don't see it.

    ROFL.... This is a misconception that all you C#-coders-that-don't-read-language-specification have. Class is not so special as you C#-coders-that-don't-read-language-specification want it to be.
    Classe is an object, but object is not necessarily a class.
    Class is an object, but so is int, delegate, interface, struct, et al. I know this is to the chagrin of you C#-coders-that-don't-read-language-specification, but that's life.

    You're not the only one that read the specification but you're definitely the only one that probably understand it differently.

    This all started with my reply to your mvp, when he wrote once more, many misconceptions in so short space. And he wrecked this thread deleting some posts and breaking the logical sequence.
    So, this is the end for me in this thread, but if you start your own thead, we can keep the conversation over there, because you are really funny. :)  YEAH!

    Good bye, have fun and yeah people tend to say I'm funny, I have this thing, however, it's really funny that you managed to violate the DRY principle while replying by writing one time too many that I'm funny.


    Eyal (http://shilony.net), Regards.


    Thursday, February 9, 2012 3:28 AM
    Moderator
  • >> As stated here by someone...
    What a pity, your link goes nowhere...

    Sorry. Here it is: http://blogs.msdn.com/b/ericlippert/archive/2009/08/06/not-everything-derives-from-object.aspx


    I understand that you feel so shocked for being contradicted about a misconception you carry for many years. But this happens because people come to this forum and get the same wrong lessons you received in the past, from some mcc's that don't read specs/documentation, and/or do not update their knowledge. Thus, my initial statement :
    " People that come to this forum, must learn correct conceptions, otherwise in the (near) future they will be spreading wrong misconceptions as you are doing now  "
    .

    I read the C# specification long before my first visit to this forum.

    You are saying that the VC# team, MSDN team, C# book's smart authors are ignorant in C#; moreover, you say you are correct just because you are supported by your personal language spec. How much you dare! Just to remind you, this is Microsoft C# language forum. So, reconsider; your statement above is offensive to them and any other that follow Microsoft C# language.

    If interfaces derive from Object, why does the BaseType of any interface type is null? Should I consider you're being offensive to the CLR team, and also to people from Microsoft who state that interfaces don't derive from Object?

    Friday, February 10, 2012 5:20 PM
  • The moderators can split the thread, there's no need to mark it as abusive as it's not.

    I already asked them to split it, I'm not sure why they haven't.

    I understand that you feel so shocked for being contradicted about a misconception you carry for many years. But this happens because people come to this forum and get the same wrong lessons you received in the past, from some mcc's that don't read specs/documentation, and/or do not update their knowledge. Thus, my initial statement : " People that come to this forum, must learn correct conceptions, otherwise in the (near) future they will be spreading wrong misconceptions as you are doing now ".

    You arrogantly think that you're somewhat smarter whreas in fact you made an assumption that clearly states "I'm right because I know better" it's nothing but your own observation that tells you that, it's not a fact, the irony is you think that we're actually clueless about it.

    Most of us here read the CLR team blogs, we read the specifications and not just the language specification that you did so telling us that we spread misconceptions is just plain wrong because that's exactly what you sir are doing right now!

    I don't have any problems for anyone to correct me when I'm wrong and people here been correcting me occasionally and it's all good but you have the nerve to laugh at us and offend us personally like you know us, not that I'm being offended but still, I imagine you don't dare doing that outside the internet, doing that here is a bad sign to the kind of person that you are in the real world.

    You know the coin has two sides, we can say exactly the same thing about you.


    Eyal (http://shilony.net), Regards.


    Saturday, February 11, 2012 5:57 AM
    Moderator
  • @eyal shilony

    I have already tried to split the the thread as you requested.  It would appear that someone may have been editing a reply when this was done.  Instead of splitting off all replies at the bottom of the thread, several replies were removed from the middle of the thread.  It seems to appear that the "break" occured where a reply may been in the process of being edited. 

    Another attempt was made to spllit the thread, as you requested.  Another "break" occurred during the attempt to split.  A bug report was immediately filed and eventually logged.  These events are currently being examined to end the speculation and determine exactly what occurred and why.  Meanwhile, the corruption state of the thread is unknown to me and no more attempts have been made to split this thread.

    I wish to extend my apologies to the OP, GSS1, for incoveniences that this digressive discussion from the original topic may have caused.  If the participants in this thread wish to continue this discussion in a seperate thread, then I suggest that you please start a new thread. 

    The discussion has been lively, but at times it has gotten personal which is a bad thing.  Your differeing opinions offer insight into how people who didn't write it read and understand the specification.

    Rudy   =8^D


    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/


    Saturday, February 11, 2012 12:07 PM
    Moderator
  • Now, shamelessly, when you run out of technical arguments, you start to offend me, hidden behind a computer. I'm sure you are not able to that outside the internet! You know a coward has many despicable personalities. We can say exactly the same thing about you.

    Funny, throughout this thread you try your best to show that my technical knowledge is limited on the subject and laughing about it, now you're trying harder to say that I offended you, really.

    I'm not hidden behind a computer, I'm using it to communicate and help the community on my free time.

    The person that I am outside to the internet is none of your business, you can save the ridiculous assumptions that you make about me to yourself, why would you even bother to write these sort of things about a person you don't know, weird.

    (You cited the user name of another forum member in your original post; this is not my citation.) Here, you are agreeing with the other forum member on the conclusion that the MS VC# lang spec is incorrect, the MSDN is incorrect too. Not happy with that, you also agree with the conclusion that popular book's authors are incorrect too! So, all them are incorrect, but you, with your personal lang spec is correct!!! This is pure, sheer arrogance of someone that does not read documentation.

    I didn't say it's incorrect I merely said that it's vague, that's a major difference!

    It's better to keep the things that you think I'm not doing to yourself, writing them here is pointless, waste of letters and your time.

    If interface and class were alike, interface wouldn't exist. Try to explain to yourself how and when interface and class are linked to the System.Object created.

    I didn't write that they are alike I merely pointed out that interfaces and classes has their own definition at run-time because you said they are glued and they are not.

    Interface Vtable Map and Interface Map
    At offset 12 in the MethodTable is an important pointer, the IVMap. As shown in Figure 9, IVMap points to an AppDomain-level mapping table that is indexed by a process-level interface ID. The interface ID is generated when the interface typeis first loaded. Each interface implementation will have an entry in IVMap. If MyInterface1 is implemented by two classes, there will be two entries in the IVMap table. The entry will point back to the beginning of the sub-table embedded within the MyClass method table, as shown in Figure 9. This is the reference with which the interface-based method dispatching occurs. IVMap is created based on the Interface Map information embedded within the method table. Interface Map is created based on the metadata of the class during the MethodTable layout process. Once typeloading is complete, only IVMap is used in method dispatching.

    You do not program in CTS language, you do not program in CLI language, you do not program in CLR language; they are not programming languages. MS VC# is a programming language, and it defines interface as derived from System.Object. Any way, you are not able to cite the sentence in those specs that support your (wrong) assertion!

    First of all, I did not write anywhere that these are programming languages I merely pointed out that by these specifications interfaces are not dervied from System.Object.

    You are really funny and arrogant! You cannot read anyone's mind! Here, you are referring to the following sentence:

    " The first four methods of any type will always be ToString, Equals, GetHashCode, and Finalize. These are virtual methods inherited from System.Object. "

    The author, clearly writes "any type", so, your intense desire not to be contradicted, fails! I must remind you that this sentence I selected in a page you said would support your misconception; but it contradicts you, clearly! C# has many types, and class is just one of them; so, class cannot be a synonym for any type!

    The author speaks about the types that are dumped using the command !dumpheap and this one does not display any interfaces but classes and structs.

    Here is an example.

    !DumpHeap

    Statistics:
          MT    Count    TotalSize Class Name
    6e8b621c        1           12 System.Security.HostSecurityManager
    6e8b5c44        1           12 System.Collections.Generic.ObjectEqualityComparer`1[[System.Type, mscorlib]]
    6e8b4e50        1           12 System.Security.Permissions.ReflectionPermission
    6e8b4d6c        1           12 System.Security.Permissions.FileDialogPermission
    6e8b4c8c        1           12 System.Security.PolicyManager
    6e8b4ba4        1           12 System.Security.SecurityDocument
    6e8b2b08        1           12 System.Collections.Generic.GenericEqualityComparer`1[[System.String, mscorlib]]
    003238fc        1           12 Test.MyClass
    6e8b61d4        1           16 System.Security.Policy.Evidence+EvidenceLockHolder
    6e8b4f00        1           16 System.Security.Permissions.UIPermission
    6e8b494c        1           16 System.Security.Util.Parser
    6e8af81c        1           16 System.Security.Policy.AssemblyEvidenceFactory
    6e8b552c        1           20 System.Security.PermissionToken
    6e8b4d14        1           20 System.Security.Permissions.EnvironmentPermission
    6e8af75c        1           20 Microsoft.Win32.SafeHandles.SafePEFileHandle
    6e8b5fc0        1           24 System.Collections.Generic.List`1[[System.Type, mscorlib]]
    6e8b329c        1           24 System.Version
    6e8b1da4        1           28 System.SharedStatics
    6e8b55d0        1           32 System.Security.PermissionTokenFactory
    6e8b4b68        2           32 System.Security.Util.TokenizerStringBlock
    6e8b49bc        1           32 System.Security.Util.Tokenizer+StringMaker
    6e8b48ac        1           32 System.Security.SecurityElement+ToStringHelperFunc
    6e8af7c0        1           32 System.Security.Policy.PEFileEvidenceFactory
    6e8b5590        1           36 System.Security.Util.TokenBasedSet
    6e8b4ea8        3           36 System.Security.Permissions.SecurityPermission
    6e8af874        3           36 System.Object
    6e8b4cc8        1           40 System.Int32[][]
    6e8b49f8        1           40 System.Security.Util.TokenizerStream
    6e8b4280        2           40 System.SZArrayHelper+SZGenericArrayEnumerator`1[[System.Security.Policy.StrongName, mscorlib]]
    6e8b37fc        1           40 System.Security.Policy.Evidence
    6e8b6188        1           44 System.Threading.ReaderWriterLock
    6e8b5098        1           44 System.Security.FrameSecurityDescriptor
    6e8b5820        2           48 System.Collections.Generic.List`1+Enumerator[[System.String, mscorlib]]
    6e8b57c0        2           48 System.Collections.Generic.List`1[[System.String, mscorlib]]
    6e8b4a34        3           48 System.Security.Util.TokenizerShortBlock
    6e8b43bc        3           48 System.Collections.ObjectModel.ReadOnlyCollection`1[[System.Security.Policy.StrongName, mscorlib]]
    6e8b222c        1           48 System.Globalization.TextInfo
    6e8b2054        4           48 System.Char
    6e8b1794        2           48 System.Reflection.RuntimeAssembly
    6e8b0258        1           48 System.Threading.Thread
    6e8b5a64        1           52 System.Collections.Generic.Dictionary`2[[System.Type, mscorlib],[System.Security.Policy.EvidenceTypeDescriptor, mscorlib]]
    6e8b3784        1           52 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.Object, mscorlib]]
    6e8b26c4        1           52 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.String, mscorlib]]
    6e8b3ee0        3           60 System.Security.Policy.PolicyStatement
    6e8b1ea0        1           60 System.AppDomainSetup
    6e8b54b0        4           64 System.Security.Permissions.FileIOAccess
    6e8b4984        1           72 System.Security.Util.Tokenizer
    6e8b3f80        3           72 System.Collections.Generic.List`1[[System.Security.Policy.StrongName, mscorlib]]
    6e8b3a74        2           72 System.Security.Policy.ApplicationTrust
    6e8b3340        1           84 System.Globalization.CalendarData
    6e8b0074        1           84 System.ExecutionEngineException
    6e8b0028        1           84 System.StackOverflowException
    6e8affdc        1           84 System.OutOfMemoryException
    6e8afe98        1           84 System.Exception
    6e8b5444        4           96 System.Security.Util.StringExpressionSet
    00497910        7          100      Free
    6e8b4dd0        3          108 System.Security.Permissions.FileIOPermission
    6e8b5608        2          112 System.Collections.Hashtable
    6e8b1154        1          112 System.AppDomain
    6e8b4a64        3          132 System.Int16[]
    6e8b4f64        5          140 System.Collections.ArrayList+ArrayListEnumeratorSimple
    6e8b00c0        2          168 System.Threading.ThreadAbortException
    6e8b5708        2          192 System.Collections.Hashtable+bucket[]
    6e8b4414        8          224 System.Security.SecurityElement
    6e8b369c        7          224 System.IO.PathHelper
    6e8afe04       10          280 System.Text.StringBuilder
    6e8b2350        1          304 System.Globalization.CultureData
    6e8b4bd0        1          316 System.Byte[]
    6e8b38fc       11          396 System.Security.PermissionSet
    6e8b44d8       18          432 System.Collections.ArrayList
    6e8b6114        3          468 System.Collections.Generic.Dictionary`2+Entry[[System.Type, mscorlib],[System.Security.Policy.EvidenceTypeDescriptor, mscorlib]][]
    6e8af8cc       24          576 System.RuntimeType
    6e8b2014       28         2564 System.Char[]
    6e8b2bc4       23         3028 System.Int32[]
    6e8b31ac        6         5672 System.Collections.Generic.Dictionary`2+Entry[[System.String, mscorlib],[System.String, mscorlib]][]
    6e8afc38      469        14072 System.String
    6e866eb4       66        19128 System.Object[]
    Total 782 objects

    Here is what happens when you try to query the heap for interfaces.

    !DumpHeap -type IInterface
     Address       MT     Size
    total 0 objects
    Statistics:
          MT    Count    TotalSize Class Name
    Total 0 objects

    Here is the class information on the heap

    !DumpHeap -type MyClass
     Address       MT     Size
    0256b4ec 003238fc       12     
    total 0 objects
    Statistics:
          MT    Count    TotalSize Class Name
    003238fc        1           12 Test.MyClass
    Total 1 objects

    and here are the methods of the class including the four methods of the base class that is System.Object.

    !DumpMT -md 003238fc
    EEClass:      003214a0
    Module:       00322e9c
    Name:         Test.MyClass
    mdToken:      6b5755bf02000003
    File:         D:\My Projects\Projects\_Practices\Test\bin\Release\Test.exe
    BaseSize:        0xc
    ComponentSize:   0x0
    Slots in VTable: 6
    Number of IFaces in IFaceMap: 1
    --------------------------------------
    MethodDesc Table
       Entry MethodDesc      JIT Name
    6e7ba7f0   6e594934   PreJIT System.Object.ToString()
    6e7be2f0   6e59493c   PreJIT System.Object.Equals(System.Object)
    6e7be200   6e59495c   PreJIT System.Object.GetHashCode()
    6e8418f0   6e594970   PreJIT System.Object.Finalize()
    0032c059   003238ec     NONE Test.MyClass.Foo()
    003a00d0   003238f4      JIT Test.MyClass..ctor()

    Now, if interfaces were deriving from System.Object why can't I query them on the heap ? where are they ? they are nothing more than a definition.

    I've not offended you

    You're right, you didn't but surely you tried, you really want me to point the places for you ?

    Outside the internet, I'm not that mild. The talk would be inexistent, mainly now that I know what you are! Be sure of that! I know pretty well how to play in any playground.

    Haha...

    You came to this thread feeling yourself a master. Bloated your post with links, mostly, outdated, showing clear bad conceptions about current VC#. You joined another forum member and used of derision against me!

    Psychologically speaking the way you write and think of me just proves something.

    I didn't picked anyone's side but shared my own honest and professional opinion about it nor I joined the brotherhood to offend you, it's not about you it's about the content that you write, silly.

    This would be the last reply I'll ever going to post here, it's just starting to feel a bit too childish for me.

    P.s. AljodAv, don't tell me what I should or shouldn't do, it wasn't your post it was someone else's post that I replied to, comprende?


    Eyal (http://shilony.net), Regards.

    Monday, February 13, 2012 5:10 AM
    Moderator
  • You'll never find MS C# interfaces on the heap because MS C# interfaces are light, versatile and smart.

    You didn't seriously just said it.

    I wonder, where is it written ? the language specification? haha.. :)

    You should look for classes in the C# lang spec; there you'll find the specific classes that are never found on the heap.
    Can you list the kind of classes that are not on the heap ?
    they are nothing more than a definition.

    Wrong again! Interfaces are declarations; the definitions are some where else, in another type.

    I've just selected one more specific item coming from your personal lang spec, to add to the long list in my previous post.

    P.s. you should be more specific, elfunylony. את מבינה?

    Read carefully, I was writing about the run-time not the language, learn to distinguish, however, even on a language level interfaces are considered definitions, not declarations.

    The interface itself is the place where you declare your methods that creates the definition of an interface.

    It's really obvious now that your English is not as good as your professional knowledge and that the problem here is communication.

    "comprende" is actually a word used as part of the English vocabulary, not just your mother tongue. ;)

    Don't try to use Hebrew by going to Google and copy/paste words from the language because it's really out of context.

    Changing my name is not as funny as you think but if it keeps the little child in you happy and a little more confident feel free, I don't care.



    Friday, February 17, 2012 6:36 AM
    Moderator
  • comprende is not english as you asserted. You're wrong, even when doing this simple assertion, as you can see:
    http://oxforddictionaries.com/spellcheck/?region=uk&q=comprende
    and
    http://www.thefreedictionary.com/comprende.

    It's not part of the oxford dictionary, it's part of speech and the informal language. ;)

    I don't see a good reason to show you classes that never appear in the heap. I've been teaching you too many things, and all got back are some insults; you derailed from the technical field (where you were fully beaten) to try to win outside the technical field; even outside the internet... tsk... tsk... tsk...! I know to play in any playground! So, I don't see any reason to show you a list of classes that never appear in the heap!... maybe to teach you something more... (not a good reason enough)... maybe to show you don't understand MS C# as per the C# Language Specification 4... HEY! This is a reason good enough!

    Insults... it's amazing how the camel never sees its own hump.

    It's hilarious how in every single post you try your best to show off with your technical knowledge, writing again and again that you beat me and my knowledge like I was racing you... but whatever you beat me! champ.

    The example above, shows classes that never appear in the heap, even though they are derived from System.Object.

    The reason you will never find interfaces or abstract classes on the heap is because it holds only instances of the types not the types themselves.

    Types are blueprints whereas instances are products of these types, however, in your world it seems that the blueprints are deriving from the products.

    Justifying the reason interfaces are not on the heap with an argument such as "they are light, versatile and smart" doesn't contribute to the reliability of your knowledge.

    Rhetorically, why would interfaces derive from System.Object if they don't provide any implementation ? just simple common sense.

    I said it once but now I'm really done, have a nice life. :)



    Eyal (http://shilony.net), Regards.

    Tuesday, February 21, 2012 12:49 AM
    Moderator
  • maybe with some friends you can get au pair avec moi 

    You want to invite him to do housework for you? Não penso que ele vai aceitar.

    Tuesday, February 21, 2012 12:37 PM
  • Now he's going to read the Dictionary in French and teach you French :)
    Wednesday, February 22, 2012 4:35 AM
  • Haha... ;)

    Eyal (http://shilony.net), Regards.

    Wednesday, February 22, 2012 11:27 AM
    Moderator