Customer Records Problem

[lkdodd]

I am doing a project where a user can enter new customer records using a dynamically allocated array of structures. I keep getting errors in the NewCustomerRecord function (like lines 101 and 103) saying "expression must have pointer type". I know I am not formatting it correctly, but I've tried several ways and can't seem to figure it out. Also, in the main function, I am getting errors on lines 40 and 41, when I try to save information from a file into the array.

struct CustomerAccountRecords
{
	string fullName;
	string streetAddress, city, state;
	int zipCode, phoneNumber, lastPaymentDate;
	double accountBalance;
};

  int main()
{
	CustomerAccountRecords *recordPtr = nullptr;
	recordPtr = new CustomerAccountRecords[100];
	int choice = 0, numRecords = 0;
	fstream RecordFile;
	
	RecordFile.open("CustomerRecords.dat", ios::in | ios::binary);

	if (RecordFile) {
		while (!RecordFile.eof()) {
			RecordFile.read(reinterpret_cast<char*>(recordPtr), sizeof(*recordPtr));
			getline(cin, recordPtr[numRecords].fullName);
		40	cin.getline(recordPtr[numRecords].streetAddress, '\n');
		41	cin.getline(recordPtr[numRecords].state, '\n');
			cin >> recordPtr[numRecords].zipCode;		
			cin >> recordPtr[numRecords].phoneNumber;
			cin >> recordPtr[numRecords].accountBalance;
			cin >> recordPtr[numRecords].lastPaymentDate;
			numRecords++;
		}
		SortRecords(numRecords);
		RecordFile.open("CustomerRecords.dat", ios::out | ios::app | ios::binary);
	}
	else {
		RecordFile.open("CustomerRecords.dat", ios::out | ios::binary);
	}

	do {
		choice = Menu();
		switch (choice) {
		case 1: NewCustomerRecord(recordPtr, numRecords);
			break;
		case 2: DisplayCustomerRecord(recordPtr, numRecords);
			break;
		case 3: DeleteCustomerRecord();
			break;
		case 4: EditCustomerRecord();
			break;
		case 5: DisplayAllRecords();
			break;
		case 6: SaveCustomerRecords();
			break;
		}
	} while (choice > 6 || choice < 1);

	delete[] recordPtr;
	RecordFile.close();

	return 0;
}

void NewCustomerRecord(CustomerAccountRecords *ptr, int recordNum)
{
	string firstName, lastName, space = " ";

	cout << "Enter New Customer Account Information Below: " << endl;
	cout << "Full Name: ";
101	cin.getline(ptr[recordNum]->fullName, '\n');
	cout << "Street Address: ";
103	cin.getline(ptr[recordNum]->streetAddress, '\n');
	cout << "City: ";
	getline(cin, ptr[recordNum]->city);
	cout << "State: ";
	cin.getline(ptr[recordNum]->state, '\n');
	do {
		cout << "ZIP Code: ";
		cin >> ptr[recordNum]->zipCode;
	} while (ptr[recordNum]->zipCode > 99999 || ptr->zipCode < 10000);
	do {
		cout << "Telephone Number: ";
		cin >> ptr[recordNum]->phoneNumber;
	} while (ptr[recordNum]->phoneNumber > 9999999999 || ptr[recordNum]->phoneNumber < 1000000000);
	do {
		cout << "Account Balance: ";
		cin >> ptr[recordNum]->accountBalance;
	} while (ptr[recordNum]->accountBalance < 0);
	do {
		cout << "Date of Last Payment (MMDDYYYY): ";
		cin >> ptr[recordNum]->lastPaymentDate;
	} while (ptr[recordNum]->lastPaymentDate > 99999999 || ptr[recordNum]->lastPaymentDate < 10000000);

	SortRecords(recordNum);

	recordNum++;
}

[salem c]

The first lesson here is you NEED to compile your code more often.

It's plainly obvious that you've typed in 100's of lines of code without bothering to press compile even once. Never write more code than you're prepared to deal with the compiler just throwing it back at you as being a mess.

Otherwise you would have spotted all those mistakes long ago.

The same goes for testing. Every time it compiles, RUN the code to see if your new bit of functionality works.

Every single one of those ptr[recordNum]->member mistakes should have been nipped in the bud after the first compilation attempt. Try it with ptr[recordNum].member instead.

Also, drop the | ios::binary mode when you're using text files.

[Albatross]

Also also, std::cin.getline is not what you want for reading into an std::string. That would be std::getline(std::cin, your_string); instead.

-Albatross

[dhayden]

When you get to the testing part, try using the zipcode where I grew up - 08505.

[dutch]

@dhayden, an int can work for a value that starts with 0 if you always print it in the proper length field width with '0' as the fill character. Still, I agree that it should really be a string.

Another problem is that 9999999999 is larger than the max 32-bit int, so the phone number either needs to be a long long or a string. Again, a string is probably best.

[dhayden]

Dutch, I was actually thinking about line 77:
} while (ptr[recordNum]->zipCode > 99999 || ptr->zipCode < 10000);

[dutch]

Great point.
Even more reason to use a string.
Sometimes things that look like numbers aren't really numbers.

[George P]

US postal zip codes now are no longer a simple 5 digits in length. They are "Zip + 4."

012345-6789 should be the field requirements, more and more people are using the extra digits since it targets a specific address and not an area that an older zip code does.

[dutch]

It gets more complicated all the time! Using a string also allows the same field to hold other countries "zip" codes, which may contain alphabetic characters.

Wikepedia wrote:

ZIP+4

In 1983, the U.S. Postal Service introduced an expanded ZIP Code system that it called ZIP+4, often called "plus-four codes", "add-on codes", or "add-ons". A ZIP+4 Code uses the basic five-digit code plus four additional digits to identify a geographic segment within the five-digit delivery area, such as a city block, a group of apartments, an individual high-volume receiver of mail, a post office box, or any other unit that could use an extra identifier to aid in efficient mail sorting and delivery. However, initial attempts to promote universal use of the new format met with public resistance and today the plus-four code is not required.[8] In general, mail is read by a multiline optical character reader (MLOCR) that almost instantly determines the correct ZIP+4 Code from the address—along with the even more specific delivery point—and sprays an Intelligent Mail barcode (IM) on the face of the mail piece that corresponds to 11 digits—nine for the ZIP+4 Code and two for the delivery point.

For Post Office Boxes, the general (but not invariable) rule is that each box has its own ZIP+4 code. The add-on code is often one of the following: the last four digits of the box number (e.g. PO Box 107050, Albany, NY 12201-7050), zero plus the last three digits of the box number (e.g., PO Box 17727, Eagle River, AK 99577-0727), or, if the box number consists of fewer than four digits, enough zeros are attached to the front of the box number to produce a four-digit number (e.g., PO Box 77, Juneau, AK 99750-0077). However, there is no uniform rule, so the ZIP+4 Code must be looked up individually for each box

[George P]

It gets more complicated all the time!

More often than not the simplistic lesson plans used in CS classes in schools and unis clearly show how old and divorced from reality they are.

The C++ standard keeps moving on, while the instructors are teaching years and decades old material that can seriously cripple a student's ability to work in a modern programming environment.