By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,490 Members | 1,398 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,490 IT Pros & Developers. It's quick & easy.

functions

P: n/a
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.

Jul 22 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
"I. Dancay" <ha****@msn.com> wrote in message
news:64**************************@posting.google.c om...
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.

Wow! I am afraid not every C++ expert can help you with this complex task.
Looks like you need to ask for somebody from top10 world C++ programmers
http://www.top10cpp.com

Regards,
Slava

Jul 22 '05 #2

P: n/a
"I. Dancay" <ha****@msn.com> wrote in message
news:64**************************@posting.google.c om...
Can someone help me work out this project?
Yes we can help you. But what we will not do is
do your work for you. As soon as you have some
code, post it here and ask specific questions.
I need someone who is a
C++ expert to help me work this one out.
Your assignment does not require expert level C++
knowledge, but does require that you've paid attention
in class, taken notes, studied and practiced.
Here it is below.


[snip homework assignment].

-Mike
Jul 22 '05 #3

P: n/a
On 28 Sep 2004 09:48:39 -0700 in comp.lang.c++, ha****@msn.com (I.
Dancay) wrote,
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.


There are many C++ experts reading this group who will help you.
What results do you have so far? What specific questions do you have?

This issue is covered in Marshall Cline's C++ FAQ. See the topic
"[5.2] How do I get other people to do my homework problem for me?"
It is always good to check the FAQ before posting. You can get the FAQ
at:
http://www.parashift.com/c++-faq-lite/
Jul 22 '05 #4

P: n/a
"I. Dancay" wrote:

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


Not really. In fact it is a typical homework assignment with
moderate complexity.

But it is this complexity which drives you nuts. This is because
you look at this assignment and say to yourself: Wow, I thats so
much work to do. I even don't know where to start!

Well. Start with the things you can do! The first thing you need
to do, is to derive a plan in which order you want to implement
(and test) things.

You certainly start with

int main()
{
}

That's always a good start :-)

Then you look t the assignment and discover that everything turns
around a 'student'. So you may ask yourself, what denotes a student?
Studying the assignment you figure out, that the description of a student
consists of
first name
last name
credits
grade points

and thats it.

Thus you can start to write (as requested by the assignment) in
a new file called student.h:

class student
{
private:
string first_name;
string last_name;
int credits;
double grade;
};

and you modify your main program to look like this:

#include "student.h"

int main()
{
}

When you try to compile this, you will notice that the compiler will
emit errors on the data type string. It dosn't know what a string
is, you have to tell it:

#include <string>

class student
{
private:
std::string first_name;
std::string last_name;
int credits;
double grade;
};

Compiling again, shows that this fixed the error.

You then continue with what you can write!
Looking through the assignment you see that there has
to be a function 'output()' that should output the
student information to cout. Well write it! I'll wait

To test this function you modify main()

#include <iostream>
#include "student.h"

int main()
{
student MyStudent;

MyStudent.output();
}

Does it compile? Does it run?
No. Then fix any errors you get and try again.

You then continue in this way
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.

You should work the same way. For now ignore seom details in the
assignment and concentrate on what you can implement. Use those
pieces to implement other pieces from the assignment until ...
well ... until the whole assignment is done.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #5

P: n/a

"I. Dancay" <ha****@msn.com> wrote in message
news:64**************************@posting.google.c om...
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.


I would like to do it all for you. Please tell me the name of your teacher
so I can give it directly to him (with your name on it of course.)
Jul 22 '05 #6

P: n/a
Karl Heinz Buchegger wrote:
"I. Dancay" wrote:
Can someone help me work out this project? I need someone who is a
C++ expert to help me work this one out.

Not really. In fact it is a typical homework assignment with
moderate complexity.

But it is this complexity which drives you nuts. This is because
you look at this assignment and say to yourself: Wow, I thats so
much work to do. I even don't know where to start!

Well. Start with the things you can do! The first thing you need
to do, is to derive a plan in which order you want to implement
(and test) things.

You certainly start with

int main()
{
}


Great post Karl!
I really like how you show the newbee to write a test program
first. I also liked the part where you wait for the OP to
write the output() method.

Nice job. I just wish I had the time to write like you.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

Jul 22 '05 #7

P: n/a
>
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.

Great post.

John
Jul 22 '05 #8

P: n/a
Karl Heinz Buchegger 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.
That's pretty much the way that I do it.
The truth is: nobody works that way.


Please speak for yourself.
Jul 22 '05 #9

P: n/a

"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? :-)
Jul 22 '05 #10

P: n/a
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
Jul 22 '05 #11

P: n/a

"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
Jul 22 '05 #12

P: n/a

"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 :-)
Jul 22 '05 #13

P: n/a
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.

Jul 22 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.