functions

[I. Dancay]

Can someone help me work out this project? I need someone who is a
C++ expert to help me work this one out. Here it is below.

implement an abstract data

type (ADT) Student as a C++ class. The project
involves writing a program
that searches for duplicates in two files with lists
of student records. The
input files must be given sorted by student name.

I. The class has to be named Student and its
definition has to be in a file
named student.h.

The class has to store the components of the student
record in private
member data fields. The components should include
first name, last name, an
integer number of credits completed, and a floating
point grade point
average.

The class has to contain the following functions:

A function input() that reads in a student record
from a file. All the data
fields will be separated by at least one space. The
order of the fields is
first name, last name, credits, and grade point.

A function output() that writes out a student record
to the screen. The
function should output last name and first name
separated with a comma (note
that the last name has to be output first.)

A function lessThan() that compares two students.
Only the names are
compared. The last name is more significant than the
first one.

A function equals() that compares two students. Only
the names are compared
as with the lessThan() function.
The bodies of the above functions should be in a
file called student.cpp.

II. The program has to search for duplicates in two
files that contain lists
of student records. The input files must be in
sorted order by student name.

This program should contain two independent
functions described below:

The main() function, which calls the checkSorted()
function twice to verify
that each of the input files is sorted in strictly
ascending order. It then
performs the search operation. When a duplicate is
found the student record
from both files should be displayed, because
although the names will match
the other fields may be different. The output is to
be displayed on the
screen.

A function called checkSorted(), which accepts the
input stream as a parameter. This function should prompt the user for
the name of the input file. If the file cannot be opened, it should
continue to reprompt the user for the correct name, until the file can be opened.
The file should be read and it should verify that the file is in ascending
order. If it is not, an appropriate error message should be displayed and
the program should terminate. Otherwise, after the file has been
completely read, it should be closed and reopened to position it at the beginning of the file.

[Karl Heinz Buchegger]

John Harrison wrote:

The problem with newbies is, that they always think that
programmers write a program in one big rush. They think
we sit down at the computer and are typing for hours, then
the compiler runs through the code, maybe one or two syntax
errors which are easily fixed and, hey, we have a working
program.

The truth is: nobody works that way.
Programmers work by implementing small pieces of the assignment
and testing those pieces. Only after one piece works, the next
piece gets implemented. This way we know, if a problem occours it
is most likely the last implemented piece which gives the problem.

When I was at Uni our accounts where limited to running the compiler six
times only in one day.

He he.
When I started in 1982 we had only *one* compiler run per day
on a IBM 360, batch system using PL/1 (but we used punching cards
also at that time. Austrian universities don't have that much
money :-). Assignments were due in 14 days. Boy we quickly
developed skills to identify silly syntax errors.
Today I work much different then at this time. I use the compiler
in a much more 'creative' way. Eg. I seldome care about defining
variables immediatly. I just write the code down straightforward .
A quick compiler run then shows me which variables need to be defined.
Or I just fire up the compiler to see if the code typed so far compiles
while I am thinking about the next code section.
The reason given was that if we spent enough time
planning our programs we would only need a couple of compiles to fix the
typos and then we would have a working program.

The problem I see with that approach is: It assumes that newbies already
have the ability to predict how multiple functions interact with each other.
When helping newbies I learned that this isn't the case. It takes a lot
of practice to devlop that skill.
To be honest: The programs in my first uni year weren't that complicated. They
could be done with the batch system. The next year we got accounts to the time
sharing system (GUTS) and had unlimited runs per day (but the problem was to get a
terminal. 10 terminals for 250 students isn't that much :-)

--
Karl Heinz Buchegger
kb******@gascad .at

[John Harrison]

"Method Man" <a@b.c> wrote in message
news:s_******** ********@read1. cgocable.net...

"John Harrison" <jo************ *@hotmail.com> wrote in message
news:2r******** *****@uni-berlin.de...

The problem with newbies is, that they always think that
programmers write a program in one big rush. They think
we sit down at the computer and are typing for hours, then
the compiler runs through the code, maybe one or two syntax
errors which are easily fixed and, hey, we have a working
program.

The truth is: nobody works that way.
Programmers work by implementing small pieces of the assignment
and testing those pieces. Only after one piece works, the next
piece gets implemented. This way we know, if a problem occours it
is most likely the last implemented piece which gives the problem.

When I was at Uni our accounts where limited to running the compiler six
times only in one day. The reason given was that if we spent enough time
planning our programs we would only need a couple of compiles to fix the
typos and then we would have a working program. This was said, as far as I could tell, in all seriousness. My Uni was rubbish.

Wow. Did they also tell you that you can only use the backspace/delete key

6 times per file so you can have all your code perfect on paper first? :-)

IIRC they had the keyboards wired up to give an increasing electric shock if
you hit backspace or delete more than six times. Sure improved my typing
skills!

john

[Sharad Kala]

"John Harrison" <jo************ *@hotmail.com> wrote in message
news:2r******** *****@uni-berlin.de...

IIRC they had the keyboards wired up to give an increasing electric shock if you hit backspace or delete more than six times. Sure improved my typing
skills!

Seems you missed a smiley above :-)

[Rolf Magnus]

Karl Heinz Buchegger wrote:

When I was at Uni our accounts where limited to running the compiler six
times only in one day.
He he.
When I started in 1982 we had only *one* compiler run per day
on a IBM 360, batch system using PL/1 (but we used punching cards
also at that time. Austrian universities don't have that much
money :-). Assignments were due in 14 days. Boy we quickly
developed skills to identify silly syntax errors.

Heh, those were the days. But that was before my time.
Today I work much different then at this time. I use the compiler
in a much more 'creative' way. Eg. I seldome care about defining
variables immediatly. I just write the code down straightforward .
A quick compiler run then shows me which variables need to be defined.
Hmm, I don't do that.
Or I just fire up the compiler to see if the code typed so far compiles
while I am thinking about the next code section.

But this, I do a lot. If I typed in code for an hour without trying to
compile it, I'd need two ours of fixing all the typos and other errors to
make it work. I hate that, therefore I only do few changes, then try to
compile it and go on adding things while the compiler is working so I don't
have to wait for the compiler all the time.

The reason given was that if we spent enough time
planning our programs we would only need a couple of compiles to fix the
typos and then we would have a working program.

The problem I see with that approach is: It assumes that newbies already
have the ability to predict how multiple functions interact with each
other. When helping newbies I learned that this isn't the case. It takes a
lot of practice to devlop that skill.
To be honest: The programs in my first uni year weren't that complicated.
They could be done with the batch system. The next year we got accounts to
the time sharing system (GUTS) and had unlimited runs per day (but the
problem was to get a terminal. 10 terminals for 250 students isn't that
much :-)

Well, nowadays you have similar problems but for a different reason. The PC
pools are always filled with students surfing the web or leeching mp3z or
whatever. But OTOH, one can do many things at home now, as long as it
doesn't require special software that is only installed on the Uni
computers.