I wanted to practice some Linked List stuff, so I set out to create a linked list. The plan was to create the following:
(1) A linked list class in Visual Basic
(2) A non-class based linked list using functions in C
(3) A linked list class in C++
I started with Visual Basic and I wrote an IList interface that I wanted my list to implement. When I had started, somehow I thought this time, I'd first use a collection as the ingredient, and so it would not really be a linked list. It would be an extended collection behaving like a (not linked, but just a) list, as in list of things. And my new agenda would then be,
(1) A list (not a linked list) class in Visual Basic by extending the Collection object.
(2) A linked list class in Visual Basic
(3) A linked list in Visual Basic that is not class-based but has a struct (Type) and global functions in a standard module (.bas).
(4) A non-class based linked list using functions in C
(5) A linked list class in C++
I don't like to create lists if they have no meaning, so I thought it would be a good idea if the list was a list of something and not just "ints". So, I made a list of my friends here; a list of JoS members. I called the list MyFriends.
I have just finished implementing a list by extending the Visual Basic's Collection object. My list has the following interface:
Code:
Public Function AddAtPos(ByRef Object As Object, _
ByVal Index As Long) As Boolean
End Function
Public Function PeekAtPos(ByVal Index As Long) As Object
End Function
Public Function RemoveAtPos(ByVal Index As Long) As Boolean
End Function
Public Property Get Count() As Long
End Property
Public Function Contains(Object As Object) As Boolean
End Function
Public Function IndexOf(Object As Object) As Long
End Function
Public Sub Serialize()
End Sub
Public Sub Deserialize()
End Sub
Public Sub Clear()
End Sub
Public Sub Sort(ByVal SortOrder As SortOrders)
End Sub
Public Sub Reverse()
End Sub
If you're interested, you can find the source code and the executable for my first experiment here.
Now, I am set to implement item number (2) in my agenda - the linked list class in Visual Basic. Once again, the semantics remain the same. I intend to keep the list as a list of friends. So each node in the list is a friend. While designing the "node" class or the "MyFriend" class, I stumbled accross this problem. I am recording two pieces of information about each friend:
(1) Name
(2) Phone Number
Both are of String type. The problem was not with these, but with the "node pointer" item. I have three data types in mind that I can use to point to the next node. I am confused as to which one would be a good choice, and I want your opinion on the same.
Here's what I have thought the node/MyFriend class as:
MyFriend Class
Code:
Implements IList
Private mName As String
Private mPhoneNumber As String
'===Which one do I choose?=======
'Private mNextFriend As MyFriend
' OR
'Private mNextFriend As Long
' OR
'Private mNextFriend() As Byte
'==================================
Let me argue each case, as I thought about them. Starting with the last, if I take the mNextFriend field as a Byte array, it would help me....do nothing, basically. So, ruled out.
Next, if took the mNextFriend field as a Long, I think it would be the ideal thing to do, because VB6 Long's are indeed 32-bit values, and then I would use the mNextFriend Long field to point to a new instance of MyFriend type, using the ObjPtr function. I would dereference the mNextFriend Long type by using RtlMoveMemory. That sounds like a nice plan. However, the problem with this is that it does not strictly confirm to a Linked List set up, because of the generic nature of this Long pointer. This pointer could be used to point not only to MyFriend types but to anything. Since I am going to be the developer audience for this class, and hence this is only dogfood, it is no problem, but in general, I don't like it as a habit and I always want my code to represent what it ought to represent. So, this would be like compromising on a trivial issue.
If I use mNextFriend as a MyFriend type, I solve the problem of the generic pointer by restricting it to the MyFriend type. So, it's more disciplined this way, but now, the field is not really a pointer. It is an object. Of course, it is still a 32-bit reference to the actual object, but it is still not a real pointer.
So, I am confused. If you were to be doing this, what option would you choose and why? To me, the Long seems like ok, although it is a little bit of a compromise on the type-checking.