template <class T>
class list
{
public:
//stuff
list(const list &cctorList); //cctor
private:
struct node
{
node *next;
node *previous;
T *info;
}
node *firstNode; //pointer to the first node (NULL if none)
node *lastNode; //pointer to the last node (NULL if none)
}
I’m now trying to define list(const list &cctorList); //cctor but I’m running into trouble.
Here’s what I have so far:
template <class T>
list<T>::list(const list &cctorList)
{
node *another = new node;
firstNode = another;
another->previous = NULL;
another->info = new T(*(cctorList->info));
// ...
}
Is everything up to this point correct? Is there a way for me to recursively assign another->next? Also, is there an easier way to accomplish this using iterators?
You should be using
std::list. In fact, you should be usingstd::vector, because it is faster for most practical purposes (list is only faster if the objects are really large or really expensive to construct) and you don’t need random access.new T(*(cctorList->info));won’t compile, becausecctorList(list&) does not haveoperator->and it does not haveinfomember either.The copy constructor is best implemented in terms of the other, more primitive operations like
push_backand iteration. So first do those and than the copy constructor becomes:In fact I’d just template that constructor:
(body remains the same). That works as copy constructor, but also allows copying from any other collection of any type that can be implicitly converted to T.
The actual data should be held by value. I.e. the
nodeshould be defined asyou are copying the value anyway, so you don’t need to do two separate allocations for
nodeandTwhen one will do.Edit: You say you want to learn concepts. But the most important concept of modern C++ is composition of algorithms. Their definitions are often trivial. Basic implementation of
std::copyis just:Now this does not appear to allocate anything. The trick lies in the
back_insertion_iterator. Insertion iterator is a trick to make this work without preallocating the sequences. It definesoperator*usingpush_backon the underlying collection and ignoresoperator++. That satisfies “output iterator” concept, because it only guarantees to work when these two calls are strictly interleaved and makes algorithms work on many things from plain old arrays to output streams.The other part is that while the trivial definitions are correct, they are not the actual definitions used in the library. The actual definitions in the library are optimized. E.g. usually
std::copywill check whether the input iterators know their distance and if the output is insert operator to sequence withreserveoperation and call it to avoid some allocations. Those are optimizations and depend on implementation details of the standard library.You can go and write down the basic implementations of things from standard library and test they work the same if you want to understand them. But you should follow the way standard library defines things by building them up from simple helper bits like
std::copy,std::swap, insertion iterator adapters and such. If you look in the standard library, most functions there are one-liners!Edit2: Also with all the genericity the standard library provides, there are still bits criticized for not being generic enough. E.g. GotW #84: Monoliths “Unstrung” discusses which methods of
std::stringcould be converted to generic algorithms.