|
It could be that Anders said that while the underlying framework would support it, they made it so that the CLI inhibited it. I'm operating off an old memory here (I probably read this about 8 years ago).
|
|
|
|
|
I tried this in CIL :
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89)
.ver 4:0:0:0
}
.assembly CILTypes
{
.ver 1:0:0:0
}
.module CILTypes.dll
.namespace MyCompany
{
.namespace MyNameSpace
{
.class public interface IMyInterface {}
.class public MyBaseClass
{
}
.class public MyAnotherBaseClass
{
}
.class public MyDerivedClass
extends MyCompany.MyNameSpace.MyBaseClass
extends MyCompany.MyNameSpace.MyNotherBaseClass
implements MyCompany.MyNameSpace.IMyInterface
{
}
}
}
and the compiler throws this error
MyBaseClass.il(30) : error : syntax error at token 'extends' in : extends myCompany.MyNameSpace.MyBaseClass. So I guess it would be a restriction on all .Net languages.
...and I have extensive experience writing computer code, including OIC, BTW, BRB, IMHO, LMAO, ROFL, TTYL.....
|
|
|
|
|
As I just said, it could be that Anders said that they imposed this restriction in the CLI. He definitely said that they could extend it to do it if they had to, but he saw no compelling reason to do so, and about a thousand arguments against. Once I find the interview, I'll post the link.
|
|
|
|
|
|
Sounds like a homework question. It's a subjective call based on the context of the code. Both have their uses and both are better than the other within a specific context.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
If I could have only one, I'd pick interface. I won't tell you why.
|
|
|
|
|
PIEBALDconsult wrote: I won't tell you why
Let me guess, you're a concrete guy.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Me too, but I won't say why either!
|
|
|
|
|
You can answer that yourself; just take an existing app that uses both, then try and rewrite it once without using abstract classes, and once without using interfaces. I trust you will never forget the conclusions.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Tell your lecturer from me that is an imbicile question. It is like saying which is fruitiest, apples or oranges. Both are useful, both have a specific job to do.
|
|
|
|
|
Plums.
There are just some times when you have to say plums.
|
|
|
|
|
Hey how many of you don't know about LinkedList<t>?[^]
It's been available since .NET 2!! And I missed it seems like it's not been discussed a lot. In fact many discussions omitted such important class.[^]
Any specific article which discuss and compare among various .NET collection classes now in terms of fetch-by-key/insert/remove/add/memory allocation/performance (polynomial time, linear time...etc) similar to cplusplus.com[^]
Gosh how the hell did I miss such important subject.
REF 1: MSDN Chapter 5 — Improving Managed Code Performance
- no reference of LinkedList but ListDictionary[^]
REF 2: That's more like it... read this comparison.[^] My question for this article is, "Insert" -- are they refering to "insert in middle of the list"? Of "Add" which adds to end of list? But, for example, for Dictionary<x,y> only supports "Add", there's no such thing as "Insert". "Insert" is supported by "IList<t>" however. Seems like article did not distinguish between add and insert.
REF 3: This seems to be the winner!![^]
Anything else?
Anyway, seems like 99% of applications we got by with Generic List/Dictionary (reasonable performance no op exceeds polynomial time) without LinkedList (all good except lookup). Does anybody has a good scenario as an example where they'd need LinkedList?
dev
modified on Wednesday, April 13, 2011 10:31 PM
|
|
|
|
|
It looks like you are the only person who hadn't noticed - why did it take you so long?
Linked list are useful, yes. But there are other structures that are more useful, depending on your circumstances:
Queue[^]
Stack[^]
HashSet[^]
To name but three.
There is a list of all the generic collections under the System.Collections.Generic Namespace[^]
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
"It looks like you are the only person who hadn't noticed - why did it take you so long?"
> because i first started with .NET 1 and didn't have more time at work than "Deliver"
dev
|
|
|
|
|
devvvy wrote: didn't have more time at work than "Deliver"
Get used to that!
Update your skills outside work - that way you may be able to get a better job: if you never upgrade your skills you pretty definitely won't!
Some employers are interested in keeping employees current because it helps the employee and the company. Others are just out to screw everything they can from you, and then discard the dried out husk "because you don't know the technology we are moving into". Get away from the later as fast as you can!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
err... mate, if you don't have an answer, try not to answer.
dev
|
|
|
|
|
Since you didn't post a question, I didn't answer it...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
|
The LinkedList that comes with .NET is rather annoying to work with IMO - when I 'need' (= want) a linked-list-like data structure I usually end up rolling my own.
Due to excessive space wastage and pointer chasing a linked list usually a poor choice anyway (Insert operations that are not at the beginning or end (that can both be rewritten to Add) are quite rare)
As an example, I've used a linked list (the "roll-my-own" version) to implement Lex-BFS, because it requires many insertions and deletion from "anywhere" in the list.
Then after some benchmarking, I found that a normal List was faster anyway - for the sizes of the instances I was working with (a couple of dozens of nodes).
I can't remember any examples of when I used a linked list and actually kept it.
|
|
|
|
|
Excessive waste of space? Disk? Or memory you mean?
dev
|
|
|
|
|
Anywhere you put them
That's usually RAM of course
|
|
|
|
|
And you used a memory profiler and found out that LinkedList consumes a lot more RAM than, say, a Dict?
dev
|
|
|
|
|
No, just add the bytes. I'm comparing to a normal List<T> btw.
On 32bit, every linked list node is 12 bytes overhead + 3*4 for next/prev/parent-list (for the .NET implementation - you could skip that parent list node) + sizeof(T) and then aligned to a multiple of 4. That's at least 28 bytes for every item in the list - no matter how long that list is.
For a List<T>, there is 12 bytes overhead + 4*4 for size/version/items/syncRoot + capacity * sizeof(T). The overheads are only incurred once and the capacity is at most twice the number of items, as the list grows to infinity the size per element approaches 2 * sizeof(T) which is 16 bytes per element for doubles and longs but usually 8 bytes or less.
|
|
|
|
|
ah I see your argument thanks
dev
|
|
|
|
|
Never had a need for it, other Collections are better suited to what I do. What I really like is HashSet which didn't show up until V3.5.
|
|
|
|