On Oct 28, 12:50 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* ecestd:
how do you implement a copy constructor for this pointer-based ADT
queue
typedef std::queue<QueueItemType> Queue;
Otherwise, iterate through all elements and add them to the new queue.
#include <cassert> // for assert
#include <new> // for bad_alloc
using namespace std;
//private:{Queue::Queue(const Queue& Q)}
Queue::Queue() : backPtr(0), frontPtr(0)
{
} // end default constructor
Queue::Queue(const Queue& Q)
Preferentially reserve all uppercase names for macros (one exception is
the idiom of nameing a template parameter T).
throw(OutOfStorageException)
{
It's not a good idea to use exception specifications other than the
empty one, and even that is by some regarded as Not A Good Idea.
/////////// Implementation
here!!!!!!///////////////
What's the problem?
///////////
what to put here so that it copies. I left this blank coz this is
where it has to be implemented. The program runs but then it crashes
if you type a string. Also what is the significance of cerr<<"type
whatever you want" <<endl? . The prorum after it runs it breaks at
delete tempPtr; What could be the problem?
} // end copy constructor
Queue::~Queue()
{
while (!isEmpty() )
{
dequeue();
} // end while
assert ( (backPtr == 0) && (frontPtr == 0) );
} // end destructor
bool Queue::isEmpty() const
{
return backPtr == 0;
} // end isEmpty
void Queue::enqueue(const QueueItemType& newItem)
throw(OutOfStorageException)
{
try
{
QueueNode *newPtr = new QueueNode;
newPtr->item = newItem;
This requires QueueItemType to be assignable. It's an unnecessary
requirement. Instead, pass newItem to the QueueNode constructor.
newPtr->next = 0;
if (isEmpty() )
{
frontPtr = newPtr;
}
else
{
backPtr->next = newPtr;
} // end if
backPtr = newPtr;
}
catch(bad_alloc e)
Catch by reference, preferentially reference to const.
{
throw OutOfStorageException("Memory allocation failed.");
It's not a good idea to translate a standard exception to a custom one
that means the same.
} // end try/catch
} // end enqueue
void Queue::dequeue() throw(OutOfDataException)
{
if (isEmpty() )
{
throw OutOfDataException("Empty queue, cannot dequeue");
}
else
{ // queue is not empty; remove front
Generally it doesn't add any clarity to use an 'else' where it's not
needed, because its presence indicates that it is needed, hence it just
obscures.
QueueNode *tempPtr = frontPtr;
if (frontPtr == backPtr) // special case?
{ // yes, one node in queue
frontPtr = 0;
backPtr = 0;
}
else
{
frontPtr = frontPtr->next;
} // end if
tempPtr->next = 0; // defensive strategy
Don't do "defensive strategy". You're introducing something that
seemingly can be relied on but can't be relied on. It's just an
invitation to disaster.
delete tempPtr;
} // end if
} // end dequeue
void Queue::dequeue(QueueItemType& queueFront)
throw(OutOfDataException)
{
if (isEmpty() )
{
throw OutOfDataException("Empty queue, cannot dequeue");
}
else
{ // queue is not empty; retrieve front
queueFront = frontPtr->item;
dequeue(); // delete front
} // end if
} // end dequeue
This design requires the client code to declare a variable just in order
to dequeue.
Consider at least adding a wrapper that returns the front item as
function result.
void Queue::getFront(QueueItemType& queueFront) const
throw(OutOfDataException)
{
if (isEmpty() )
{
throw OutOfDataException("Empty queue, cannot getFront");
}
else
{
// queue is not empty; retrieve front
queueFront = frontPtr->item;
} // end if
} // end getFront
Ditto.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?