Return to Answer

###Additions

Additions

Bringing everything from std into the global namespace causes more issues than it is worth. I know every book on the subject does it. But they do it because of size limitations in their medium. You should never do this in real code.

See: Why is “using namespace std” considered bad practice?

Make it a private member class of SLinkedList. Then it gets smaller. You can make it struct you don't need the friend declaration or the <E> sprinkled everywhere.

Why would somebody want to create a linked list with a node? Why does Why are you passing a pointer to the node? What is the ownership semantics of the pointer? So many unanswerable questions. Just get rid of this constructor.

I don't see any of the normal construcotrs I would expect for a container that is doing memory management (and you are doing memory management). Please look up the rule of three.

Yeahh. Stop using NULL that's an old hangover for C (we don't like C here). C++ has a better identifier. Use nullptr it has better type information associated with it (so it will not be converted to int type accidentally).

But do you really want too?

I am an expert user and will always check that list is not empty before calling front(). But you are making me pay a penalty (the extra check (I just checked)) because there are idiots out there that don't check. Why are you penalizing me (the good guy) when the bad guys are the ones you should be penalizing.

Prefer '\n' to std::endl. The only difference between the two is that std::endl forces a stream to flush. This is never the correct thing to do (unless you are an expert and understand stream flushing to byte level (or you are debugging in which case you should be using an unbuffered stream like std::cerr)).

Incorrect flushing the buffer is the MAIN cause of inefficiency in C++ I/O application. The standard streams are quite good at correctly flushing for efficiency use the code somebody else has spent hours perfecting for your system.

see: How to overload the operator++ in two different ways for postfix a++ and prefix ++a?

I have to create a constructor that allows a new linked list to be populated with ten consecutive values, starting at 0

A special constructor for adding ten items is a bit strange. But we can do it. Lets create a merker enum. Then it

Bringing everything from std into the global namespace causes more issues than it is worth. I know every book on the subject does it. But they do it because of size limitations in their medium. You should never do this in real code.

See: Why is “using namespace std” considered bad practice?

Make it a private member class of SLinkedList. Then it gets smaller. You can make it struct, and you won't need the friend declaration or the <E> sprinkled everywhere.

Why would somebody want to create a linked list with a node? Why are you passing a pointer to the node? What is the ownership semantics of the pointer? So many unanswerable questions. Just get rid of this constructor.

I don't see any of the normal constructors I would expect for a container that is doing memory management (and you are doing memory management). Please look up the rule of three.

Yeahh. Stop using NULL; that's an old hangover for C (we don't like C here). C++ has a better identifier. Use nullptr; it has better type information associated with it (so it will not be converted to a integer type accidentally).

But do you really want to?

I am an expert user and will always check that list is not empty before calling front(). But you are making me pay a penalty (the extra check (I just checked)) because there are idiots out there that don't check. Why are you penalizing me (the good guy) when the bad guys are the ones you should be penalizing?

Prefer '\n' to std::endl. The only difference between the two is that std::endl forces a stream to flush. This is never the correct thing to do (unless you are an expert and understand stream flushing to byte level (or you are debugging - in which case you should be using an unbuffered stream like std::cerr)).

Incorrectly flushing the buffer is the MAIN cause of inefficiency in C++ I/O application. The standard streams are quite good at correctly flushing for efficiency; use the code somebody else has spent hours perfecting for your system.

See: How to overload the operator++ in two different ways for postfix a++ and prefix ++a?

I have to create a constructor that allows a new linked list to be populated with ten consecutive values, starting at 0.

A special constructor for adding ten items is a bit strange. But we can do it. Let's create a marker enum:

###Additions

I have to create a constructor that allows a new linked list to be populated with ten consecutive values, starting at 0

A special constructor for adding ten items is a bit strange. But we can do it. Lets create a merker enum. Then it

enum Marker { MakeTenItems };
SLinkedList(Marker)
    : head(nullptr)
{
    for(int loop = 0; loop < 10; ++loop)
    {
        addFront(10 - 1 - loop);  // This will construct an E with an int
                                  // So E must have an appropriate constructor.
    }
}

Then to use it:

SLinkedList<int>  list(MakeTenItems);