Hashtable without keys?

[Gerry O'Brien [MVP]]

Absolutely.

--
Gerry O'Brien
Visual Developer .NET MVP
Visual Basic

Ahh, I see. This same basic class could be written in C# without any
substantial changes(outside of syntax of course).

 

[Gerry O'Brien [MVP]]

You're getting picky about words.

So, let me rephrase.

VB.NET can do Linked Lists.

Better??

--
Gerry O'Brien
Visual Developer .NET MVP
Visual Basic

 

[Jon Skeet [C# MVP]]

You're getting picky about words.

So, let me rephrase.

VB.NET can do Linked Lists.

Better??

No, because you went on to say:

<quote>
I know that VB has them because the course I developed for CompuCollege
here in Moncton teaches linked lists, stacks and queues.

I'm not sure why C# doesn't have them.
</quote>

.... which means you think (or thought) there's something in VB.NET
which isn't in C# with regards to linked lists. There isn't. Just as
you can create them in VB.NET, you can create them in C#. As this
"difference" is a main point of discussion in this thread, I hardly
think it's "picky" to get it right.

 

[cody]

"VB has them" is my way of saying you can do linked lists in VB. I did
not

mean to state that VB has a class for implementing them.

I cannot imagine a programming language in which you cannot implement a
LinkedList.

 

[Gerry O'Brien [MVP]]

"I'm not sure why C# doesn't have them", is simply my way of saying I do not
know if C# has or does not have them. I am merely relying on the other
poster's reference to the fact that they may or may not.

I do not program in C# yet therefore I cannot make reference to what it has
or does not have for support of features.

"VB has them" is my way of saying you can do linked lists in VB. I did not
mean to state that VB has a class for implementing them.

So, take from it what you will. I believe I answered the original poster's
question to at least his satisfaction even it not to yours.

Such is life on Usenet.

--
Gerry O'Brien
Visual Developer .NET MVP
Visual Basic

 

[Jon Skeet [C# MVP]]

I cannot imagine a programming language in which you cannot implement a
LinkedList.

One without pointers of some description, for a start. I can't remember
much about Spectrum Basic, but I don't think it would be feasible in
that.

I agree that it's pretty unlikely to happen in any useful and modern
language/platform, and so saying that a language/platform "has"
something when it's just possible to implement it on that platform
certainly leaves a lot of room for misinterpretation (as is evident in
this thread).

 

[cody]

"VB has them" is my way of saying you can do linked lists in VB. I
did

One without pointers of some description, for a start. I can't remember
much about Spectrum Basic, but I don't think it would be feasible in
that.

Never heard about Spectrum Basic.

I agree that it's pretty unlikely to happen in any useful and modern
language/platform, and so saying that a language/platform "has"
something when it's just possible to implement it on that platform
certainly leaves a lot of room for misinterpretation (as is evident in
this thread).

Indeed.

 

[Gerry O'Brien [MVP]]

My apologies, I'll try to be as perfect as you next time Jon.

--
Gerry O'Brien
Visual Developer .NET MVP
Visual Basic

 

[Jon Skeet [C# MVP]]

Never heard about Spectrum Basic.

The ZX Spectrum was one of the earliest home computers in the UK. With
a massive 48K of memory and - wait for it - colour - it took the UK by
storm. It was my first introduction to computers. I can still running
up to tell my Dad when I first wrote a program which moved an arrow up
and down the screen when you pressed appropriate keys.

Basic was interpreted, slow, extremely restrictive, and generally nasty
in those days.

 

[cody]

One without pointers of some description, for a start. I can't
remember

The ZX Spectrum was one of the earliest home computers in the UK. With
a massive 48K of memory and - wait for it - colour - it took the UK by
storm. It was my first introduction to computers. I can still running
up to tell my Dad when I first wrote a program which moved an arrow up
and down the screen when you pressed appropriate keys.

Basic was interpreted, slow, extremely restrictive, and generally nasty
in those days.

The good old days. My first was a textadventure in QBasic (Windows 95)
Is is still available on my hp..

 

[Daniel O'Connell [C# MVP]]

Therefore you should not use InsertAt or IndexOf, instead you should
remember the Nodes where you want to insert so
you don't have to traverse the list every time. Inserting at head or tail
is
cheap as well because theses Nodes are always available.

Inserting at the tail is *adding* and is cheap in all natural collections.
Inserting at the head is probably the most expensive add in an array
however. By directly exposing your underlying nodes, you turn LinkedList
into a more complated and more dificult class. Code using it is going to be
*far* less clear than code using almost any other structure(except perhaps a
non-balanced tree or other such things). It would effectivly remove the most
common known method(Add, Remove, indexer\Item() property) because they don't
make sense when you are effectivly just working over a set of Nodes you need
to work with.

Very often.

Oddly, maybe 5-8% of my code actually uses inserts and removals to the
extent that a LinkedList *might* have an effect.

Often. Already 40 elements can be a lot when removing and inserting in an
arraylist vs linkedlist.

That may be, but personally I think you're thinking that a LinkedList is a
pancea in all cases, where it is actually a bad idea in most. Either you are
stuck with big performance issues or more complicated code(you start having
to manage the list directly). Outside of extreme performance situations I
would probably argue that using a LinkedList is something to be forbidden in
most situations.

LinkedLists are certainly not useful for int values, but they are for
larger
objects or structs (with generics using structs instead of objects in
LinkedLists can improve performance a lot).

I still doubt it will be a good thing for a large number of structs. For one
thing, a struct shouldn't exceed 16 bytes or so, by using a linked list you
are guarenteeing that the struct *WILL* take up atleast 13 and at most
28bytes while in use. For large amounts of data I would avoid a linked list
like the plauge, instead opting to figure out how to insert it into the
ArrayList structure in the correct order(as always, algorithm beats
structure optimiztions). For classes, you are in the same situation as an
int as the size of a reference is the same as an int32 on 32 bit hardware.
You can't consider the object size when you consider the linked list size
because only the reference matters in either the linked list or the
ArrayList. The number of nodes matters a great deal more than the size of
the node, in reality.

The only problem with LinkedList in .NET is that the whole bunch of
references in a LinkedList slows GC down thats one of the reasons why they
left it out, I suppose.

I suppose it could compliate the GC a bit, but I don't know if thats for
sure or not. The GC has to travel down huge object graphs as it is, while a
linked list is a decent object graph I don't suspect that it will be used in
situations where the graph will be big enough to matter. The memory overhead
really makes it a problem for large numbers of nodes.

 

[Daniel Billingsley]

But that's the problem. "Language X has feature A" would generally be taken
to mean feature A can be used out of the box, regardless of how you meant
it. If anything, you did the OP a disservice. Not a big deal - honest
mistake - but don't get all uppity when someone points out how your message
would likely be misinterpreted.

Surely you wouldn't say VB "has" Warehouse Management or Payroll , would
you?

 

[Jerry Pisk]

No, payroll is definitely Java language feature

Jerry