Thread: Circular Lists

You haven't beat the challenge. You implemented a buggy and effectively unusable linked list. The challenge was to beat my feat, however.

Buggy how? it compiles on my system just fine. I even made modification's to make it portable, even though that wasnt part of the original challenge. Since noone bothered ot point out the one really obvious bug (caused by a bad copy/past) I can only assume that noone bothered to even attempt to compile it.

I may be mistaken but the Heap functions appear also to come from <windows.h>. Why don't you just stick with malloc and free?

Not sure what this challenge is all about, but your List class only allows you to Create, Insert, Delete and Remove things. As a class it is useless: it doesn't take care of anything behind the back, it is entirely up to the user to provide all functionality and encapsulation to make this even remotely useful. Basically it is up to the user to manage the internals of the list class.

This class design is not really acceptable in C++. You might start by getting acquainted with the private keyword if you want to write anything but plain and messy C with some C++ keywords here and there.

Come on, you are not the only one here who could easily implement a linked list, but you are bragging about a class that has virtually no interface at all. While it may-be took you 20-30 minutes to write, trying to use it in practical programs will inevitably lead to hours of bug-chasing (unless someone takes a few hours and hides the mess behind a nice wrapper).

what anon was hinting about private was this:

In a hypothetical template linked-list class you would make your node struct private, and next (and previous pointers if applicable) private as well. typically the iterator class is part of the public interface. The whole point of the iterators are to provide the user with random access to the list. Lists should (as templates) should not provide any indexing features (like insert at position 6), that's what the iterators are for. The user should decide how they want to use the list, the creator of the list should only provide being able to get to that node by pointing to it through the use of iterators. This is the whole idea in OOP behind encapsulation and information hiding. Like anon or CornedBee (not sure who exactly) pointed out that they shouldn't have to manipulate next and prev pointers to iterate the list (hence the point of iterators).

I don't want to put your effort down however, you know what you're doing, however your attempt simply fails to meet the requirements of a generic solution.

Since noone bothered ot point out the one really obvious bug (caused by a bad copy/past) I can only assume that noone bothered to even attempt to compile it.

I did point out that it would not compile (at least from my visual inspection, which could be wrong), but I did not notice that you had corrected it soon after.

The reason why I said this is not "templates versus code" is that my point is:

However, it is much better and easier to use the interface of an existing container than implement such a container yourself.