26

My question is very simple, can one using C++, implement a link-list data structure without using pointers (next nodes)? To further qualify my question, I'm mean can one create a Linked-List data structure using only class instantiations.

A common node definition might be like so:

template<typename T>
struct node
{
   T t;
   node<T>* next;
   node<T>* prev;
};

I'm aware of std::list etc, I'm just curious to know if its possible or not - and if so how? Code examples will be greatly appreciated.

More clarifications:

  1. Insertions should be O(1).
  2. Traversal should be no more than O(n).
  3. A real node and a null node should be differentiable.
  4. The size of the linked-list should only be limited by the amount of memory available.
Ziezi
  • 6,375
  • 3
  • 39
  • 49

14 Answers14

19

Sure, if you don't mind the linked list having a maximum size, you could statically allocate an array of list nodes, and then use integer indices into the array as your "previous" and "next" values for each node, rather than pointers. I've done in this in the past to save a bit of memory (since an integer can be either 2 or 4 bytes, whereas on a 64-bit system a pointer will be 8 bytes)

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234
  • 4
    But then it's not a linked list, it's a vector. – Billy ONeal Jun 09 '10 at 02:41
  • 5
    @Jeremy: As Billy mentioned, what you describe is not a linked-list wrt the true definition of the structure. –  Jun 09 '10 at 02:43
  • 1
    It's not a vector or a linked list. It requires contiguous memory allocation, but it allows some linked list benefits (inserting and removing in anywhere in O(1)). – Matthew Flaschen Jun 09 '10 at 02:46
  • @Matthew Flaschen: vector == contiguous memory allocation. I say it's a vector because the actual container in which the objects are stored is a vector. Just because those objects have references to each other doesn't mean it magically becomes a linked list. (+1 to comment though because of mentioning benefits of such a hybrid data structure) – Billy ONeal Jun 09 '10 at 02:47
  • 6
    It is a linked list with all nodes occupying a continuous memory space. From Wikipedia: "a linked list is a data structure that consists of a sequence of data records such that in each record there is a field that contains a reference (i.e., a link) to the next record in the sequence." What @Jeremy Friesner describes satisfies this definition. – Richard Simões Jun 09 '10 at 02:49
  • @BipedalShark: No, the elements are in a vector. The fact that they hold indexes to that vector makes absolutely no difference. Array indexes are not references or links. – Billy ONeal Jun 09 '10 at 02:51
  • 2
    Nodes are in a vector (either a `std::vector` or otherwise), but it doesn't have the performance characteristics of `std::vector`. – Matthew Flaschen Jun 09 '10 at 02:53
  • 1
    @Billy ONeal: A C++ array is a pointer to the first element of the array. An array index is an offset from this pointer. How is this not a reference (in a general computer science sense, not the C++ data type) when used as a reference? – Richard Simões Jun 09 '10 at 02:57
  • In other breaking news... I've just been informed that this URL is *not* a linked list (it is, in fact, a *bitmap*!!): http://upload.wikimedia.org/wikipedia/commons/thumb/6/6d/Singly-linked-list.svg/408px-Singly-linked-list.svg.png – HostileFork says dont trust SE Jun 09 '10 at 02:58
  • @BipedalShark: Because the memory is still being managed as a vector. The elements are in a vector, and the vector controls the lifetime, etc. of the objects. It still has many of the liabilities of a vector, namely that iterators and references are invalidated after insertions, and that an insertion can require reallocation of the entire underlying array. Linked lists don't reallocate and are always consistent even after insertions or deletions. – Billy ONeal Jun 09 '10 at 03:01
  • 2
    It seems a bit silly to quibble about definitions, but I'd call it a linked list with an extremely simple custom node-allocator algorithm. @Billy, I think you are incorrect about the liabilities; this can be implemented without requiring the invalidation of iterators, and the reallocation of the entire underlying array is avoided simply by having the insertion fail if the array is full. – Jeremy Friesner Jun 09 '10 at 03:56
  • @Jeremy: Then you're just trading what I've described earlier for the liability that the container is limited in size. – Billy ONeal Jun 09 '10 at 04:13
  • 2
    @billy: by your logic a std::map using a pooled allocator would also be a vector if the pool use contiguous memory. – deft_code Jun 09 '10 at 05:36
  • 1
    @Billy ONeal: Give up already. Pointer is technically index, and index is technically pointer. If a list is stored in array AND uses indicies for parent/child, it is still a list. AND searching for a free element in such list can be easily optimized down to O(n) operation - at the cost of sizeof(int)*maximumSize of memory. – SigTerm Jun 09 '10 at 06:53
  • @Caspin: No, because a map can decide to allocate a new memory chunk which is completely unrelated to the old one. Therefore it has none of the liabilities that a vector does. @Sigterm: Yes, but the problem lies in what happens when your array runs out of space. You can't have constant time insertion with such a structure, only constant amortized time. And you can't maintain consistency after insertions either. Given that those are the only benefits of using a linked list data structure, even if it was a list there'd be no point. If you find yourself doing this, use a `std::deque`. – Billy ONeal Jun 09 '10 at 12:10
  • 2
    @Billy: Yes, I am making that tradeoff, but I said that up front in the original answer. I think the result is still a linked list in the ways that count (O(1) insertion/removal, O(N) lookup time, previous/next links, immutable/persistent node addresses) – Jeremy Friesner Jun 09 '10 at 15:33
  • @Jeremy: It's not O(1) insertion, it's O(1) *amortized* insertion. And you don't have immutable or persistent node addresses with the exception of the integers stored for first/previous node. Pointers to items in those nodes are invalidated upon insertion. – Billy ONeal Jun 09 '10 at 18:53
  • @Billy: As a fortran77 programmer who has used dynamic memory managers on implemented on `interger*4` arrays in common blocks, allow me to assure you that array offsets have *all* the characteristics of pointers. Indeed, native pointers can be though of as an array offset in the flat memory space offered by modern architectures. Certainly, mixing hardware-pointers with array-pointers when the array-store may move causes trouble, but so what? That is equivalent to the observation that you can't serialize a linked-list to disk without providing for reconstituting the links properly later. – dmckee --- ex-moderator kitten Jun 10 '10 at 02:18
  • @dmckee: I never stated that array offsets have differing characteristics. I did state that in the data structure described, the objects in the array are managed as an array, not as a list. The objects are constructed when the array is constructed, and destroyed when the array is destroyed, not the pseudo-list. The data structure described does not provide the consistency or runtime guarantees that a list provides. Does it have some of the advantages of a list? Sure. But does it provide the same semantics as a list? No. – Billy ONeal Jun 10 '10 at 02:41
  • 1
    @Billy, no, insertion definitely is O(1) always -- remember, I'm disallowing array reallocations. Therefore, insertion only requires 'popping' the first item in the free-items-list, then 'pushing' it into the in-use-items list; both operations can be done just by updating a small/fixed number of index values -- no loops of any kind are required. Also, pointers to items are never invalidated upon insertion, because the items never move to different memory locations. (Their _prevIndex and _nextIndex values might change, but the items themselves don't move) – Jeremy Friesner Jun 10 '10 at 02:44
  • @Jeremy: "I'm disallowing array reallocations" <-- Okay, so you've traded consistency for extremely limited use of space. It's still does not have the semantics of a list. – Billy ONeal Jun 10 '10 at 04:40
  • 1
    It has all of the semantics of a list, except for being arbitrarily extensible. As for being "extremely limited", that's up to the implementer. E.g. there's nothing stopping you from setting the array size (and thus, the maximum list length) to 10 million if that's what you want to do. – Jeremy Friesner Jun 10 '10 at 19:11
  • 1
    *"Okay, so you've traded consistency for extremely limited use of space. It's still does not have the semantics of a list"* No. Though we have grown used to the idea that a "link list" has access to the whole address space provided by the chip, that has historically not been the case. If you insist on it, you are claiming that no one ever implemented a "linked list" on the classic Mac OSs. Pure nonsense. Limited allocators are less useful than a machine native lists residing in a fully virtualized heap (which is still not arbitrarily extensible), but they are still linked lists. – dmckee --- ex-moderator kitten Jun 10 '10 at 20:33
11

Yes, it's possible. Use array indexes instead of pointers.

DVK
  • 126,886
  • 32
  • 213
  • 327
  • 3
    you mean something like a std::vector> ? –  Jun 09 '10 at 02:41
  • @DVK: But then it's not a linked list. – Billy ONeal Jun 09 '10 at 02:41
  • 2
    @DVK: True, then nor would your array be one either. –  Jun 09 '10 at 02:42
  • 4
    It's still a linked list, but it is also still using pointers. The term for this is "based pointer". – Ben Voigt Jun 09 '10 at 02:43
  • 8
    Billy if an entry in the list has a link to the "previous" and "next" entry in hte list then it is a linked list. The original "linked List" implementations were database structures on disk which had logical pointers for "previous' and "next" – James Anderson Jun 09 '10 at 02:59
5

From Wikipedia:

In computer science, a linked list is a data structure that consists of a sequence of data records such that in each record there is a field that contains a reference (i.e., a link) to the next record in the sequence.

Nothing in that definition specifies the manner in which the reference is stored or used. If you don't store a reference, it isn't a linked list -- it's something else.

If your goal is merely to avoid using a pointer (or object reference), then using a vector with an index is a common implementation. (One of the reasons for using the vector/index implementation is persistence: it's really hard to correctly persist pointers / object references outside of the active memory space.)

Craig Trader
  • 15,507
  • 6
  • 37
  • 55
5

Yes:

class node { 
  std::string filenameOfNextNode;
  std::string filenameOfPrevNode;
  std::string data;
  node nextNode() {
    node retVal;
    std::ifstream file(filenameOfNextNode.c_str());
    retVal.filenameOfNextNode = file.getline();
    retVal.filenameOfPrevNode = file.getline();
    retVal.data = file.getline();
    return retVal;
  }
};

Inspired by a comment about the origins of linked lists

MSalters
  • 173,980
  • 10
  • 155
  • 350
4

One could create a list of cons-cells using temporaries, const references, and inheritance. But you'd have to be very careful not to keep any references to it beyond its lifetime. And you probably couldn't get away with anything mutable.

This is based roughly on the Scala implementation of these lists (in particular the idea of using inheritance and a NilList subclass rather than using null pointers).

template<class T>
struct ConsList{
   virtual T const & car() const=0;
   virtual ConsList<T> const & cdr() const=0;
}

template<class T>
struct ConsCell:ConsList{
   ConsCell(T const & data_, ConsList<T> const & next_):
        data(data_),next(next_){}
   virtual T const & car() const{return data;}
   virtual ConstList<T> const & cdr() const{return next;}

   private:
     T data;
     ConsList<T> const & next;
}

template<class T>
struct NilList:ConsList{  
   // replace std::exception with some other kind of exception class
   virtual T const & car() const{throw std::exception;}
   virtual ConstList<T> const & cdr() const{throw std::exception;}
}

void foo(ConsList<int> const & l){
   if(l != NilList<int>()){
      //...
      foo(NilList.cdr());
   }
}

foo(ConsList<int>(1,ConsList(2,ConsList<int>(3,NilList<int>()))));
// the whole list is destructed here, so you better not have
// any references to it stored away when you reach this comment.
Ken Bloom
  • 57,498
  • 14
  • 111
  • 168
  • Actually, you can avoid the issue with temporaries by giving each node a variable with a name, and making references to those. But that could also be living dangerously. – Ken Bloom Jun 09 '10 at 02:49
  • 5
    @Ken: Your solution is no different than a static array, as the size of the structure has to be known at compile-time. Furthermore the size of the structure is entirely dependent on the compilers templating depth and not the amount of memory you have available. –  Jun 09 '10 at 02:50
  • 1
    @sonicoder, this structure is not using nested templates, so the compiler's templating depth shouldn't affect anything. Moreover, if you used a recursive function to build the list and continuation passing style to operate on it then you could build a dynamically-sized list. – Ken Bloom Jun 09 '10 at 02:53
  • 6
    @Ken: Could you please demonstrate how one would insert a node between say, nodes 2 and 3? –  Jun 09 '10 at 02:54
  • 3
    @sonicoder: that can't be done. This is a cons-list, like one would find in a functional language, and those aren't intended to support insertions in the middle. (That's the only reason I can get away with this silly example. I if you want mutability you'll have to use pointers.) – Ken Bloom Jun 09 '10 at 02:56
  • Unfortunately, you can't really use this list since you're storing references to data allocated on the stack. If the list is returned from a function, the references will no longer be valid. – Joshua Hartman May 09 '11 at 19:37
  • Thats why you return a copy of the list. Also implied by the "cons" in it's name. – Tarion Jan 02 '17 at 20:20
4

While I'm not sure just what the context behind your question is, if you do a little out of the box thinking I'm sure you can.

DVK suggested arrays, which is quite true, but arrays are simply thin wrappers around pointer arithmetic.

How about something entirely different: use the filesystem to do the storage for you!

for example, the file /linked-list/1 contains the data:

Data 1!

5

and /linked-list/5 is the next node in the list...

If you're willing to hack enough, anything is possible :-p

Note that said implementation's complexity / speed is entirely dependent on your filesystem (i.e. it's not necessarily O(1) for everything)

Community
  • 1
  • 1
Steven Schlansker
  • 37,580
  • 14
  • 81
  • 100
  • That's still not a linked list. Insertion or removal requires pushing up or down elements in your file. It's more like a vector data structure. – Billy ONeal Jun 09 '10 at 02:46
  • 4
    @Steven: Lets just assume the solution I'm looking for should not be based on anything other than standard OS memory allocation and code execution facilities. –  Jun 09 '10 at 02:47
  • 1
    @Billy: I don't see how this is anything like a vector. If you want to insert between 1 and 5, you take 1 and change its reference to 6534, and then make 6534 point at 5. No "pushing" or "popping" needed. – Steven Schlansker Jun 09 '10 at 02:50
  • @sonicoder: Your question was weird enough that I felt compelled to be a little silly with it. Clearly this does not fit your desire to only use standard memory allocation, etc... – Steven Schlansker Jun 09 '10 at 02:51
  • @Steven Schlansker: Because you had to put your new item into the array in order to update those references. You do get some of the benefits of a linked list (i.e. constant time insertion in the middle) with something like this, but the fact remains that the memory is being managed as a vector, not a list. – Billy ONeal Jun 09 '10 at 02:53
  • 2
    What is main memory but a very, very large array, then? :-p – Steven Schlansker Jun 09 '10 at 04:04
3

Yes you can, it is not necessary to use pointers for a link list. It is possible to link a list without using pointers. You can statically allocate an array for the nodes, and instead of using next and previous pointer, you can just use indexes. You can do that to save some memory, if your link list is not greater than 255 for example, you can use 'unsigned char' as index (referencing C), and save 6 bytes for next and previous indications.

You may need this kind of array in embedded programming, since memory limitations can be troublesome sometimes.

Also keep in mind that your link list nodes will not necessary be contiguous in the memory.

Let's say your link list will have 60000 nodes. Allocating a free node from the array using a linear search should be inefficient. Instead, you can just keep the next free node index everytime:

Just initialize your array as each next index shows the current array index + 1, and firstEmptyIndex = 0.

When allocating a free node from the array, grab the firstEmptyIndex node, update the firstEmptyIndex as next index of the current array index (do not forget to update the next index as Null or empty or whatever after this).

When deallocating, update the next index of the deallocating node as firstEmptyIndex, then do firstEmptyIndex = deallocating node index.

In this way you create yourself a shortcut for allocating free nodes from the array.

tozak
  • 401
  • 4
  • 12
3

I suppose using references is cheating and, technically, this causes UB, but here you go:

// Beware, un-compiled code ahead!
template< typename T >
struct node;

template< typename T >
struct links {
  node<T>& prev;
  node<T>& next;
  link(node<T>* prv, node<T>* nxt); // omitted
};

template< typename T >
struct node {
  T data;
  links<T> linked_nodes;
  node(const T& d, node* prv, node* nxt); // omitted
};

// technically, this causes UB...
template< typename T >
void my_list<T>::link_nodes(node<T>* prev, node<T>* next)
{
  node<T>* prev_prev = prev.linked_nodes.prev;
  node<T>* next_next = next.linked_nodes.next;
  prev.linked_nodes.~links<T>();
  new (prev.linked_nodes) links<T>(prev_prev, next);
  next.linked_nodes.~links<T>();
  new (next.linked_nodes) links<T>(next, next_next);
}

template< typename T >
void my_list<T>::insert(node<T>* at, const T& data)
{
  node<T>* prev = at;
  node<T>* next = at.linked_nodes.next;
  node<T>* new_node = new node<T>(data, prev, next);

  link_nodes(prev, new_node);
  link_nodes(new_node, next);
}
sbi
  • 219,715
  • 46
  • 258
  • 445
1

You could make a linked-list using references, but that would probably be more complicated than necessary. you would have to implement an immutable linked-list which would be complicated without a built in garbage collector.

luke
  • 14,518
  • 4
  • 46
  • 57
  • 1
    No you can't. The reference has to point to something that's allocated *somewhere*, and you can't have a linked list manage that memory like it can if you are using pointers. You'd still have to hold the allocated objects in your linked list somehow, and that wouldn't be a linked list. – Billy ONeal Jun 09 '10 at 02:44
  • @Billy ONeal i know, thats why it would be complicated. instead of a null pointer at the end you would create a special singleton instance for an empty list. the references would be set in constructors. if you look at Ken Blooms code this is pretty much what he is doing. – luke Jun 09 '10 at 02:46
  • @Luke: You'd still have the problem of the fact that the thing the reference points at will die when you try to put it into the list. There's no way to ensure the references remain valid. If you look at Ken Bloom's code, note that none of the structure remains after a single statement. – Billy ONeal Jun 09 '10 at 02:49
  • @Billy ONeal my C++ is a little rusty, but couldn't you just construct the object on the heap and then create a reference from the pointer and then pass these 'new'd objects to the next constructor, this would extend the lifetime of the list objects. Now obviously it would be difficult to manage all these allocations. – luke Jun 09 '10 at 03:02
  • yeah but not in the datastructure itself – luke Jun 09 '10 at 05:40
1

Languages that do not support any type of reference can still create links by replacing pointers with array indices. The approach is to keep an array of records, where each record has integer fields indicating the index of the next (and possibly previous) node in the array. Not all nodes in the array need be used. If records are also not supported, parallel arrays can often be used instead.

As an example, consider the following linked list record that uses arrays instead of pointers:

record Entry {
integer next; // index of next entry in array
string data; // can be anything a struct also. }

Creata an array with a high number. And point listHead to the first indice element at the array

integer listHead;
Entry Records[10000];

Check wiki page: http://en.wikipedia.org/wiki/Linked_list for details, search for "Linked lists using arrays of nodes"

Numenor
  • 1,686
  • 12
  • 20
0

Wow, NO? Surely you guys are not serious?

All a linked list needs is a link. Nothing says it has to be a pointer. Consider the case of wanting to store a linked list in shared mem, where the base addr is dynamic? Answer is simply, store the link as a Offset from the start of the mem block, (or some other constant) and redefine the iterator to do the actual logic of adding the base addr. Obviously, insert etc would have to be changed as well.

But fairly trivial!

Allan

Allan
  • 1
  • 1
0

A possible approach would be to use an array of Nodes where each node stores an (array) index to the prev and next Node. Thus, your Node would look something like:

struct Node 
{
    T data;
    int prev;    // index of the previous Node of the list
    int next;    // index of the next Node of the list
}

Additionally, you will probably have to dynamically allocate the Node array, implement some bookkeeping to get and free space in the array: for example a bool array that stores the unoccupied indexes in the Node array, along with two functions that will update it every time a new Node / index is added or removed (it will be fragmented as nodes won't be always contiguous); find an index of a Node in the array: for example by subtracting the address of the Node from the first address of the array.

Here is how a possible interface of a doubly linked list using the above technique would look like:

template <typename T>                          // T type Node in your case
class DList
{
    T** head;                                  // array of pointers of type Node
    int first;                                 // index of first Node
    int last;                                  // index of last Node

    bool* available;                           // array of available indexes 
    int list_size;                             // size of list

    int get_index();                           // search for index with value true in bool available
    void return_index(int i);                  // mark index as free in bool available

    std::ptrdiff_t link_index(T*& l) const;    // get index of Node

    void init();                               // initialize data members
    void create();                             // allocate arrays: head and available

    void clear();                              // delete array elements
    void destroy();                            // delete head

public:
    DList();                                   // call create() and init()
    ~DList();                                  // call clear() and destroy()

    void push_back(T* l);
    void push_front(T* l);
    void insert(T*& ref, T* l);                // insert l before ref

    T* erase(T* l);                            // erase current (i.e. l) and return next
    T* advance(T* l, int n);                   // return n-th link before or after currnet

    std::size_t size() const;
    int capacity () const { return list_size; }
};

You could use that as a benchmark and implement something on your own.

template <typename T>
void DList<T>::push_back(T* l)
{
    if (l == nullptr)
    {
        throw std::invalid_argument("Dlist::push_back()::Null pointer as argument!\n");
    }

    int index = get_index();
    head[index] = l;

    if (last != -1)
    {
        head[last]->next = index;
        head[index]->prev = last;
    }
    else
    {
        first = index;
        head[index]->prev = -1;
    }

    last = index;
    head[index]->next = -1;
}
Ziezi
  • 6,375
  • 3
  • 39
  • 49
0

As an addition to the existing answers of using a previous and a next vector/array, we could build on top of a more dynamically resizing structure, i.e. losing the amortization on the resizing operation.

Why do I think this is suitable? Well, we have gained some advantages by using vectors/arrays, but we got the amortized resizing in return. If we can rid ourselves of the latter, we may have turned the trade entirely in our favor!

Specifically, I am referring to Resizable Arrays in Optimal Time and Space. It's a very interesting data structure, particularly as the basis for other data structures such as the one we are talking about.

Note that I have linked to the technical report, which, unlike the regular paper, also includes the (highly interesting) explanation of how doubly-resizable arrays were achieved.

Timo
  • 7,992
  • 4
  • 49
  • 67
-10

Can one using C++, implment a link-list data structure without using pointers (next nodes)?
No.

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552