Thread: he we go again

I concur with Hunter, at first glance the code looks ok, with the exception of the void main().

Of course, they should really be teaching vectors and the rest of the STL.

all of those classes inherit from asset....

asset::~asset(void){ delete [] name; }
stock::~stock(void){ //not necessary at all; have tried it with executable code though }
~property and ~savings are the same as ~stock (the destructors are in the given headers)

after my initial run (which failed) i have been selected only the stock option...so that will be the only source i post here.....

Code:

//stock.h
#ifndef STOCK_H
#define STOCK_H
#include <fstream.h>
#include "asset.h"


class stock : public asset
{
	public:
	stock();
	~stock();
	double annualReturn(void) const;
	stock & setCurrentPriceShare(double);
	virtual void print(ostream &);
	virtual void kinput(void);

	private:
	long numberShares;
	double paidPricePerShare;
	double currentPricePerShare;
};

#endif

Code:

//stock.cpp
#include "stock.h"

stock::stock(void)
{
	numberShares = 0;
	paidPricePerShare = 0;
	currentPricePerShare = 0;
}

stock::~stock()
{}


/* more member functions. none of which allocate memory dynamically */

Code:

//asset.cpp
#include "asset.h"

asset::asset(void)
{
	name = NULL;
	invested = 0;
	currentValue = 0;
}

asset::~asset()
{	delete [] name; }

//more member functions

Code:

//asset.h
#ifndef ASSET_H
#define ASSET_H
#include <fstream.h>
#include "date.h"
class asset
{
	public:
	virtual double annualReturn(void) const = 0;
	double value(void) const;
	virtual void print(ostream &);
	virtual void kinput(void);

	asset();
	~asset();
	asset & setInvested(double);
	asset & setCurrentValue(double);
	asset & setCurrentDate(Date &);
	double getInvested(void) const;
	double getCurrentValue(void) const;
	long daysHeld(void) const;

	private:
	char *name;
	double invested;
	Date dateAcquired;
	double currentValue;
	Date currentDate;
};

#endif

don't worry about the Date class...i'm 99.99% it's a solid class

i guess since it's on the last page i will post this again...

Code:

#include <fstream.h>

#include "asset.h"
#include "stock.h"
#include "savings.h"
#include "property.h"

int main()
{
	int count;
	cout << "How any assets do you wish to enter? ";
	cin >> count;
	asset * * group = new asset * [count];



	for(int i = 0; i < count; i++)
	{
		char choice;
		cout << "What do you want s, v, or p? ";
		cin >> choice;
		switch(choice)
		{
			case 's': group[i] = new stock; break;
			case 'p': group[i] = new property; break;
			case 'v': group[i] = new savings; break;
			default: group[i] = NULL; break;
		}

		group[i]->kinput();
		group[i]->print(cout);
	}

	for(int j = 0; j < count; j++)
	{
		if(group[j])
			delete group[j];
	}
	delete [] group;
	return 0;
}

Originally Posted by Hunter2

As a side note, I don't see why you need fstream in there. If anything, you'd be needing iostream...

yea, i know...i don't even bother anymore

asset::~asset() really should be virtual.

*edit*
Why does 'char* name' even exist? It doesn't ever appear to be used.

>>name = NULL;
>>delete[] name;

Seems to me that since asset's constructor/destructor aren't virtual, they'll get called no matter what. That means that you'll be delete[]ing a NULL pointer, since you never allocate memory for name...

By the way, is the teacher making this code up on the fly or what, because I don't see how she can teach the same thing year after year if the code she's using doesn't work

Well, I ran your latest code, and it ran fine. I had to add some stuff myself, like a fake Date class, and some functions for the two classes. Maybe the problem's in one of those functions.

The destructor not being virtual seems like a problem, but maybe that's only if the derived class destructor does something.

Well, misplaced, try just doing:

Code:

cout << "Begin" << endl;
asset* a = new stock;
cout << "Checkpoint 1" << endl;
a->kinput();
cout << "Checkpoint 2" << endl;
a->print(cout);
cout << "Checkpoint 3" << endl;
delete a;
cout << "Finish" << endl;

See how far it makes it.

Calling delete on a NULL pointer is fine. Dereferencing a NULL pointer on the other hand, is not, and this will occur in some circumstances here:

Code:

switch(choice)
{
   case 's': group[i] = new stock; break;
   case 'p': group[i] = new property; break;
   case 'v': group[i] = new savings; break;
   default: group[i] = NULL; break; <--- Set pointer to NULL if choice != s, p, v
}

group[i]->kinput();
group[i]->print(cout); <--- Dereferencing NULL pointer if choice != s, p, v

>>What programming Class are you taking? Whats the name?<<

better yet, what school? teachers name and email address?

Originally Posted by misplaced

Code:

default: group[i] = NULL; break; //<<--break if pointer is NULL calling 
                                      //kinput and print will fail

Although I'm repeating Zack, here it goes again

Originally Posted by xErath

Code:

....
default: group[i] = NULL; continue;//<<--continue if pointer is NULL kinput and print aren't 
                                    //called because the cicle is reset

Originally Posted by Hunter2

Well, misplaced, try just doing:

Code:

cout << "Begin" << endl;
asset* a = new stock;
cout << "Checkpoint 1" << endl;
a->kinput();
cout << "Checkpoint 2" << endl;
a->print(cout);
cout << "Checkpoint 3" << endl;
delete a;
cout << "Finish" << endl;

See how far it makes it.

checkpoint 3, just as i suspected....

zach: everytime i run it use 's' and group[i] is never NULL

everyone else: name is allocated in asset::kinput

Originally Posted by axon

>>What programming Class are you taking? Whats the name?<<

better yet, what school? teachers name and email address?

We'll need geographical coordinates for the airstrike too.

misplaced, I figured you weren't running it with bad input, but that was a potential problem spot I noticed. Anyway, as far as I can tell, there is absolutely no reason that it should be crashing there.

The only thing left that I can suggest would be, since it is a small program, to clobber all of it and rewrite it the right way. Sometimes that clears up issues that are not readily visible.

Cheers