Airplane Program with Linked Lists. The linked list portion is very confusing to me.
jawdoc
and I totally appretiate all of the help I received from everyone. Now
I have this program and we are instructed to use Linked Lists. I
understand that in my struct I need a struct that is a pointer that is
in the struct. In mine it is called *next. In my updated code passing
through some of the functions with the plane struct causes errors on
the clearPlane function. The Linked list version has an array of bools
showing if the seat is taken or not instead of having the bool in the
array. I just need some direction for using the linked lists instead
of the 2 dimensional arrays. Both versions are provided. Any help is
greatly appretiated.
Thanks
Jawdoc
2 Dimensional Airplane
http://www.chiefgamer.com/tman/cpp/airplanearray.cpp
Linked List Airplane
http://www.chiefgamer.com/tman/cpp/airplanelist.cpp
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Mikosz
> through some of the functions with the plane struct causes errors on
> the clearPlane function.
Jawdoc,
The reason for the compilation error is that in your code, clearPlane
is declared as follows:
void clearPlane(SEAT *&p , bool o[][COLS]);
But you try to call the function like that:
SEAT plane;
[...]
clearPlane( plane, occupied);
You should either change the parameter type of p in clearPlane to a
reference, as in:
void clearPlane(SEAT& p, bool o[][COLS]);
or just drop the parameter, as you don't use it anyway.
I understand, that the program is not complete yet? You never actually
do anything with the list.
Regards,
Mikolaj
Michael....@gmail.com
> Earlier I posted up an Airplane Program using 2 dimensional arrays,
> and I totally appretiate all of the help I received from everyone. Now
> I have this program and we are instructed to use Linked Lists.
I had a look at both your programs and I would like to encourage you
to dump them and start anew. I assume this is a C++ course, and I
would give you low marks for your solution even if everything works
because you essentially designed them ancient C style not object
oriented C++ style.
Consider making "Seat" a class, making data members private and add
public accessor methods (separate implementation details from
interface!). Everything in your program that acts on a single seat
should become a member function.
Same applies to plane: create a class "Plane" and give it a container
for Seats and methods that operate on the container. The array was
fine but if you like lists, you may consider using a standard class
that is part of C++ language definition - do not invent the wheel
again, use what is offered.
This would make your program much so more in the spirit of C++...
Inline functions used only for keeping it short, better make
separate .cpp files:
#include <list>
class Seat {
public:
Seat() : occupied( false ) {} // Constructor for initialization
bool IsOccupied() const { return occupied; }
void Occupy() { occupied = true; }
void Free() { occupied = false; }
// ...
private:
bool occupied;
};
class Plane {
public:
Plane() { /* initialize cabin */ }
void Clear() { /* ... */ }
/* ... */
private:
std::list<Seat> cabin;
// no need to make it 2-dimensional.
// If you need to address a seat by row/column you can
// add a function that maps r/c to position in list.
// I'd do it using an 2D array, as before, or a
// std::vector< std::vector<Seat> >.
// Note also, this container is private! The rest of
// the app should not need to know how the Plane class
// organizes itself internally!
/* ... */
};
Add more classes for your user interface and so on and then put
together your application from the macroscopic building blocks and not
from the details. I'm sure this will get you much closer to an "A"...
best,
Michael
pandemonium
On Mar 8, 2:21 am, jawdoc <drbro...@msoms.com> wrote:
> Earlier I posted up an Airplane Program using 2 dimensional arrays,
> and I totally appretiate all of the help I received from everyone. Now
> I have this program and we are instructed to use Linked Lists. I
> understand that in my struct I need a struct that is a pointer that is
> in the struct. In mine it is called *next. In my updated code passing
> through some of the functions with the plane struct causes errors on
> the clearPlane function. The Linked list version has an array of bools
> showing if the seat is taken or not instead of having the bool in the
> array. I just need some direction for using the linked lists instead
> of the 2 dimensional arrays. Both versions are provided. Any help is
> greatly appretiated.
>
> Thanks
> Jawdoc
>
> 2 Dimensional Airplane
>
> http://www.chiefgamer.com/tman/cpp/airplanearray.cpp
>
> Linked List Airplane
>
> http://www.chiefgamer.com/tman/cpp/airplanelist.cpp
Some suggestions,
If you choose to program in object oriented language then use all
advantage that they have. Use encapsulation, make class plane and then
implement needed method.
Truly says code on http://www.chiefgamer.com/tman/cpp/airplanelist.cpp
have many thinks that can be called bad programing. But after some
experience that will be good.
Why you use *&someType , use &someType or *someType.
& is reference,
* works with pointers
try with:
http://www.fortunecity.com/skyscraper/false/780/linklist.html
http://cslibrary.stanford.edu/105/LinkedListProblems.pdf
Regard
Seungbeom Kim
>
> I had a look at both your programs and I would like to encourage you
> to dump them and start anew. I assume this is a C++ course, and I
> would give you low marks for your solution even if everything works
> because you essentially designed them ancient C style not object
> oriented C++ style.
Just because the program is not in a object-oriented style doesn't mean
it is in a bad C++ style.
>
> Consider making "Seat" a class, making data members private and add
> public accessor methods (separate implementation details from
> interface!). Everything in your program that acts on a single seat
> should become a member function.
I agree that it should probably be a class at some point in the future,
but what invariants should be enforce by the class at this time?
struct SEAT {
bool occupied; // initially, false
string first,last; // passenger name
int numBags; // max of 4
char mealType; // (r)egular, (v)egetaria, (o)ther
};
I don't see any. (Except that the restrictions upon numBags and mealType
could be enforced by separate classes.) Therefore I don't see an
immediate need to make this into a real "class" (i.e. with private
parts), though adding a constructor would certainly help.
> // I'd do it using an 2D array, as before, or a
> // std::vector< std::vector<Seat> >.
A std::vector of std::vector is hardly a 2D array; it's rather a
hierarchy than a table.
I haven't found an easy way to handle multidimensional arrays (with
dynamic sizes, of course) in C++ yet; to beginners, I would just
recommend to stick to built-in arrays.
And I agree that a linked list is hardly a good data structure for this
problem.
--
Seungbeom Kim
Carl Barron
<musi...@bawi.org> wrote:
The questions I have are
1) is this supposed to be a programming exercise or
2) an exercise in writing classical containers, or ,,
3) and how much is the student supposed to know?
Last one is extremely important since no one studies calculus before
elementary algebra.:)
>
> And I agree that a linked list is hardly a good data structure for this
> problem.
Agreed as I see random access or at least O(log N) access of a plane
or seat.
I might have a class/struct for planes since then I could add
members and other things to integrate the solution with the C++
standard library, Even
struct Plane
{
static const int n_seats = 256;
SEAT seats[n_seats];
SEAT & operator [] (std::ptrdiff_t n)
{ return seats[n];}
const SEAT & operator [] (std::ptrdiff_t) const
{ return seats[n];}
SEAT * begin() {return &seats[0];}
const SEAT * begin() const {return &seats[0];}
// similiar for end();
};
then we can access the k-th seat on j-th plane with the usual
planes[k][j], from a 1D array of Plane, and provide easy iterator
access to use with <algorithm>
Is this too much, maybe, but it makes the coding using standard
library especially since <algorithm> provides search algorithms and
these are to be used extensively in this type of program.
we can have a variable # of planes with fixed seats, and other combos
using std::vector instead of C style arrays if desired now or in the
future, requiring at most a recompile of much of the code.
--
Francis Glassborow
> Some suggestions,
> If you choose to program in object oriented language then use all
> advantage that they have. Use encapsulation, make class plane and then
> implement needed method.
But C++ is NOT an OOPL; it is a language with built in support for OOP
along with support for a number of other programming styles. Note that
the STL is NOT properly OO, its power comes from generic programming.
Francis Glassborow
> Michael....@gmail.com wrote:
>>
>> I had a look at both your programs and I would like to encourage you
>> to dump them and start anew. I assume this is a C++ course, and I
>> would give you low marks for your solution even if everything works
>> because you essentially designed them ancient C style not object
>> oriented C++ style.
>
> Just because the program is not in a object-oriented style doesn't mean
> it is in a bad C++ style.
go either.
>
>>
>> Consider making "Seat" a class, making data members private and add
>> public accessor methods (separate implementation details from
>> interface!). Everything in your program that acts on a single seat
>> should become a member function.
>
> I agree that it should probably be a class at some point in the future,
> but what invariants should be enforce by the class at this time?
>
> struct SEAT {
> bool occupied; // initially, false
> string first,last; // passenger name
> int numBags; // max of 4
> char mealType; // (r)egular, (v)egetaria, (o)ther
> };
>
> I don't see any. (Except that the restrictions upon numBags and mealType
> could be enforced by separate classes.) Therefore I don't see an
> immediate need to make this into a real "class" (i.e. with private
> parts), though adding a constructor would certainly help.
I think you are missing the reason for making data private. It isn't
just to enforce invariants but to reduce the opportunity for accidental
change. And there is an obvious (to me) invariant in that occupied and
the passenger name are linked. (and so is the meal type when I think
about it)
Once you have made data public it becomes extremely difficult to change
the decision for anything more than a toy program.
>
>> // I'd do it using an 2D array, as before, or a
>> // std::vector< std::vector<Seat> >.
>
> A std::vector of std::vector is hardly a 2D array; it's rather a
> hierarchy than a table.
It isn't a rectangular array but it is a table with potentially
different lengths for the second dimension.
>
> I haven't found an easy way to handle multidimensional arrays (with
> dynamic sizes, of course) in C++ yet; to beginners, I would just
> recommend to stick to built-in arrays.
Very definitely not the way I would go. Ray arrays introduce a multitude
of problems with argument passing.
>
> And I agree that a linked list is hardly a good data structure for this
> problem.
Yes, but it does depend what you want. I suspect my option would be some
form of map but as I would want the data differently organised for
different purposes I suspect that I would eventually look at something
which used a container of seats + other containers of (smart) pointers
into that. However this would be a nice item for discussing design with
students.
>
--
Note that robinton.demon.co.uk addresses are no longer valid.
pandemonium
<francis.glassbo...@btinternet.com> wrote:
> But C++ is NOT an OOPL; it is a language with built in support for OOP
> along with support for a number of other programming styles. Note that
> the STL is NOT properly OO, its power comes from generic programming.
>
Yes, I agree with You that C++(C with Classes) is hybrid language(java
is pure OOPL).
But if it had a OO support, it's good to be used.
Regards.
peter koch larsen
> On Mar 9, 6:40 pm, Francis Glassborow
>
> <francis.glassbo...@btinternet.com> wrote:
> > But C++ is NOT an OOPL; it is a language with built in support for OOP
> > along with support for a number of other programming styles. Note that
> > the STL is NOT properly OO, its power comes from generic programming.
>
> Yes, I agree with You that C++(C with Classes) is hybrid language(java
> is pure OOPL).
> But if it had a OO support, it's good to be used.
> Regards.
>
It is good to use OO when it is needed: OO is a tool. Sometimes OO
does not fit the bill and in that case, it is better to not use it.
/Peter
Alex
> Yes, I agree with You that C++(C with Classes) is hybrid language(java
> is pure OOPL).
Java is not pure OOPL because it has basic types (which are not
objects) as well as basic arithmetic implemented as operators (rather
than as "messages"). Smalltalk is pure OOPL.
> But if it had a OO support, it's good to be used.
Object orientation, although good in many scenarios, is not a
universal synonym for "good".
As for the airplane homework, since the original poster was concerned
with linked lists, if the main goal is to make program do it's task
and do it efficiently, I'd redo it using STL facilities. If one of the
goals is to master linked lists, then implementing his own may be a
worthwhile effort.
Alex
Carl Barron
<5393fda1-6234-49d3...@34g2000hsz.googlegroups.com>,
pandemonium <plava...@gmail.com> wrote:
> On Mar 9, 6:40 pm, Francis Glassborow
> <francis.glassbo...@btinternet.com> wrote:
>
> > But C++ is NOT an OOPL; it is a language with built in support for OOP
> > along with support for a number of other programming styles. Note that
> > the STL is NOT properly OO, its power comes from generic programming.
> >
>
> Yes, I agree with You that C++(C with Classes) is hybrid language(java
> is pure OOPL).
> But if it had a OO support, it's good to be used.
> Regards.
Not if doing so makes it more complicated:) In this case I see
searching for an empty seat, and seats reserved for a person, This
wants essentially a 2D array for a small course exercise. and that might
be done dynamically with a struct Seat with a couple of test member
functions to be able to use std. lib. routines, and a struct Plane
providing operator [] , begin(),end() refering to the contained vector
so that Planes planes[1000];
planes[i][j]; 'points to a Seat.
and [ planes[i],begin(),planes[i].end() ) is an stl sequence of
Seats in plane i. Now all the searches can be preformed using stl
algorithms in linear time.
Chris Thomasson
news:5de059fc-1d43-47a8...@b1g2000hsg.googlegroups.com...
> On Mar 9, 7:12 pm, pandemonium <plavapi...@gmail.com> wrote:
>> Yes, I agree with You that C++(C with Classes) is hybrid language(java
>> is pure OOPL).
>
> Java is not pure OOPL because it has basic types (which are not
> objects) as well as basic arithmetic implemented as operators (rather
> than as "messages"). Smalltalk is pure OOPL.
>
>> But if it had a OO support, it's good to be used.
>
> Object orientation, although good in many scenarios, is not a
> universal synonym for "good".
>
> As for the airplane homework, since the original poster was concerned
> with linked lists, if the main goal is to make program do it's task
> and do it efficiently, I'd redo it using STL facilities. If one of the
> goals is to master linked lists, then implementing his own may be a
> worthwhile effort.
Humm, IMHO, if I were teaching a course on C++, it would be all about
implementing various parts of the STL under some other namespace like
'std_course'. For instance, you could teach them how to implement
'std_course::list' and use it in a couple of scenarios... After that, you
could teach them how to implement 'std_course::vector', and so on... This
course would be on C++ and data-structures mainly. What do you think, would
that be a worthwhile course of action for a professor to take? If all goes
well, you should end up with students who will be able to use the STL _and_
implement various parts of it...
Seungbeom Kim
> Seungbeom Kim wrote:
>>
>> I agree that it should probably be a class at some point in the future,
>> but what invariants should be enforce by the class at this time?
>>
>> struct SEAT {
>> bool occupied; // initially, false
>> string first,last; // passenger name
>> int numBags; // max of 4
>> char mealType; // (r)egular, (v)egetaria, (o)ther
>> };
>>
>> I don't see any. (Except that the restrictions upon numBags and mealType
>> could be enforced by separate classes.) Therefore I don't see an
>> immediate need to make this into a real "class" (i.e. with private
>> parts), though adding a constructor would certainly help.
>
> I think you are missing the reason for making data private. It isn't
> just to enforce invariants but to reduce the opportunity for accidental
> change.
How does seat.set_last("Kim") make the opportunity for accidental change
lower than seat.last = "Kim" ?
> And there is an obvious (to me) invariant in that occupied and
> the passenger name are linked.
It's not specified what values the other fields should have when occupied
is false. I just assumed that they are meaningless and ignored.
Of course, the corresponding member functions could enforce that they
cannot be read nor written when occupied is false. But I assumed such
a simple example would not go that far.
> (and so is the meal type when I think about it)
Of course, I would make it an enum rather than an unconstrained char.
> Once you have made data public it becomes extremely difficult to change
> the decision for anything more than a toy program.
That's true. But it's also true that a literal translation of a struct
into a class doesn't automatically make it much more flexible. For
example, the decision of what data type each member should be of, or
whether the passenger name should be stored as a single string or a
first/last pair or a title/first/middle/last tuple, for example,
should be made beforehand, and using a class doesn't relieve you
of that design process nor makes such a change much easier.
And this is a toy program with minimal functionality, after all. :)
I understand the value of exercises where you're supposed to pretend
to be working on something serious while you're actually working on
a toy program, but the educational purpose is achieved only when
subsequent assignments involving the changes are tried so that it is
learned how much easier a proper encapsulation makes such changes.
A toy program in which each field is just expanded into three lines
(variable+accessor+mutator) without a specific purpose is not only
weird, but also pointless.
What I'd like to emphasize is that the class interface design should
not be a mere reflection of, nor a mere translation from, an underlying
data structure, but should be the other way round, a higher-level
process that the corresponding data structure is derived from. Too
often, class interface design is presented or taught in the wrong
direction, just to show the formalities of encapsulation.
>> I haven't found an easy way to handle multidimensional arrays (with
>> dynamic sizes, of course) in C++ yet; to beginners, I would just
>> recommend to stick to built-in arrays.
"with fixed sizes", I meant but forgot to add.
>
> Very definitely not the way I would go. Ray arrays introduce a multitude
> of problems with argument passing.
I may need better memory or imagination, but what problems?
Not much more than a single-dimensional built-in array, I guess, when
the style "SEAT s[][COLS]" is consistently used, as the OP already did.
--
Seungbeom Kim
Lance Diduck
>
> Humm, IMHO, if I were teaching a course on C++, it would be all about
> implementing various parts of the STL under some other namespace like
> 'std_course'.
programmers as well. I present seminars on choosing stl containers,
which basically explains that "the properties you want in a data
structure are not solely determined by the syntax expressing its
interface" and "std:: containers are not fundamental types." You would
be amazed at how much confusion exists about these common sense facts.
And this is not restricted to just novice developers.
For example --One way to confuse people is to appeal to "intuitive
syntax":
T x,y = v;//T is any stl container of any type Y that supports
operator==
y=foo(y); //any operation
x=foo(x); //same thing !!
assert(x==y);// x and y are the same!!!
This looks perfectly reasonable in a short little presentation like
this, until you actually try to make this pretty syntax (and that is
ALL it is) into a large scalable system. (e.g. make Y a float, and
make foo an operation that applies cos to each element 100 times --
and foo actually dispatches y and x to different machines for
computation) Then you will see that there really isn't any fundamental
truth to be discovered in a convenence functions like operator== and
operator=.
At least the STL is smart enough to provide ways to parameterize
comparator functions, so that I can at least build a correctly
operating system irregarless of whether it uses syntatic sugar.
And confusion about syntax is just the tip of the misunderstandings,
but that is enough for now. I hope to soon turn my presentation into a
paper -- the really good stuff is in the misassumptions about
compleity measures, which I often have to remind myself of.
Lance
Roman.Pe...@gmail.com
> Humm, IMHO, if I were teaching a course on C++, it would be all about
> implementing various parts of the STL under some other namespace like
> 'std_course'. For instance, you could teach them how to implement
> 'std_course::list' and use it in a couple of scenarios... After that, you
> could teach them how to implement 'std_course::vector', and so on... This
> course would be on C++ and data-structures mainly. What do you think, would
> that be a worthwhile course of action for a professor to take? If all goes
> well, you should end up with students who will be able to use the STL _and_
> implement various parts of it...
Take a look at Alex Stepanov programming course notes:
http://www.stepanovpapers.com/notes.pdf. It's awesome.
Roman Perepelitsa.