what is the prog coding for this question and what it output

[Keith Thompson]

I realize that some people use the word "queue" for a linked list, but I
would never do that. To me a queue should connote a physical queue, as a
line of people waiting for a bus. A linked list is something that doesn't
exist in the real world, it's a programmer's invention. OTOH, a queue does
have a real world manifestation.

A queue is a well-established term for a first-in first-out data
structure. A linked list is one way to implement a queue.

 

[Randy Howard]

Write a C program to construct a queue of integers and to perform the
following operations on it:
a. insert
b. delete
c. display
The program should print appropriate messages for stack overflow and stack
empty.

Someone else helped you with some starting code, and that is all you are
likely to get until long after the homework assignment is due. If you
get others to do your work for you now, who will do them for you later?
You certainly won't know how.

i hope u guys can help me,for me it is difficult question.

It is not difficult at all. That is why you are being asked to do it
now, in an early CS course, instead of later in the real world, where
the problem description would be many pages long and considerably
tougher to implement.

 

[ozbear]

I realize that some people use the word "queue" for a linked list, but I
would never do that. To me a queue should connote a physical queue, as a
line of people waiting for a bus. A linked list is something that doesn't
exist in the real world, it's a programmer's invention. OTOH, a queue does
have a real world manifestation.

A series of traffic signposts that you follow to arrive at a final
destination (or any intermediate node/city) is a perfectly good
real world example of a linked list.

Just follow the arrows on the signs.

Oz

 

[Michael Mair]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew Pitcher wrote:

infobahn wrote:

[snip]

Which do you mean? Queues are generally LIFO. Stacks are generally FIFO.

ITYM "Queues are generally FIFO (First In, First Out). Stacks are
generally LIFO (Last In, First Out)"

Think again.

I have. Why don't you?

It's not the definitive reference, but try
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=queue&action=Search
and
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=stack&action=Search

You are right -- should not have posted with fever :-/

Cheers
Michael

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have. Why don't you?

[snip]
You are right -- should not have posted with fever :-/

No harm, no foul.

Just want to make sure we're all talking the same language ;-)

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAFG5agVFX4UWr64RAl+LAJ49g/0OOh1dvgB6CGPliFLoWwPnsACg3Dbe
JYythvwcyaBwIXCmWXW+Jv4=
=lAfa
-----END PGP SIGNATURE-----

 

[Lawrence Kirby]

A series of traffic signposts that you follow to arrive at a final
destination (or any intermediate node/city) is a perfectly good
real world example of a linked list.

It is similar but signposts usually tell you about the direction towards
a place, not the location of the next signpost.

Lawrence

 

[Lawrence Kirby]

.


Perhaps yours were. I've seen plenty in embedded real-time systems in
the Real World(tm).

Yes, they are viable in well controlled environments.

For that matter a number of Unix systems have
fixed-size stacks per process (and even one which isn't thought of as
fixed size will have a limit in practice, even if it's several
gigabytes).

There are differences between a fixed sized stack and a variable stack
with a size limit. E.g. in implementations where, say, "stack" grown down
from the top of the address space and "heap" grows up from the bottom, if
a program uses less "stack" space than it is allowed it may be able to use
the extra for "heap" allocation. There there is the question of whether
memory for the fixed sized stack is pre-allocated.

Lawrence

 

[Chris Croughton]

There are differences between a fixed sized stack and a variable stack
with a size limit. E.g. in implementations where, say, "stack" grown down
from the top of the address space and "heap" grows up from the bottom, if
a program uses less "stack" space than it is allowed it may be able to use
the extra for "heap" allocation. There there is the question of whether
memory for the fixed sized stack is pre-allocated.

Yes, the stacks which share a data area are a different problem (and one
that's harder to predict, because it depends on the dynamic size of the
'heap'). The program may run fine sometimes and not others. That's why
with embedded systems the stacks are generally not shared with anything
else, so that the behaviour is predictable (the same often goes for
dynamic memory, it's allocated in fixed areas or 'pools' of fixed size,
to avoid fragmentation problems).

Chris C

 

[Michael Wojcik]

Perhaps yours were. I've seen plenty in embedded real-time systems in
the Real World(tm).

Even when memory constraints aren't the limiting factor, there may
be good reason to use a fixed-size array-based queue. Better locality
of reference, for example. Faster access. I might use a fixed-size
array queue in a producer-consumer architecture where, if the queue
fills, the producer should be suspended to give the consumer a while
to catch up; there might not be any advantage to enlarging the queue.

Many real-world applications should impose limits on how much work
they're willing to accept. That often provides for a much more
graceful failure mode than simply taking everything on until the load
becomes unsustainable. The "all data structures must be extensible"
philosophy is part of the mindset that gives us bloatware and
unstable application software.

--
Michael Wojcik (e-mail address removed)

Art is our chief means of breaking bread with the dead ... but the social
and political history of Europe would be exactly the same if Dante and
Shakespeare and Mozart had never lived. -- W. H. Auden

 

[Chris Croughton]

Even when memory constraints aren't the limiting factor, there may
be good reason to use a fixed-size array-based queue. Better locality
of reference, for example. Faster access. I might use a fixed-size
array queue in a producer-consumer architecture where, if the queue
fills, the producer should be suspended to give the consumer a while
to catch up; there might not be any advantage to enlarging the queue.

I didn't say that it was necessarily memory constraints (although all
Real World(tm) ststems do have memory constraints). An example of your
"producer-consumer" situation is the serial buffers I referred to.

Many real-world applications should impose limits on how much work
they're willing to accept. That often provides for a much more
graceful failure mode than simply taking everything on until the load
becomes unsustainable. The "all data structures must be extensible"
philosophy is part of the mindset that gives us bloatware and
unstable application software.

I have no disagreement with that. In particular, a lot of modern
systems using virtual memory can fool applications into thinking that
they have a lot of memory, but the access time for it will get far worse
above a certain point (I've done that, pushed a Unix system to the point
of uselessness by the application requesting memory until it "ran out",
at which point everything was swapped to disk and it took half an hour
just to get a shell to find out what was wrong!).

Chris C

 

[CBFalconer]

.... snip ...

I have no disagreement with that. In particular, a lot of modern
systems using virtual memory can fool applications into thinking
that they have a lot of memory, but the access time for it will
get far worse above a certain point (I've done that, pushed a Unix
system to the point of uselessness by the application requesting
memory until it "ran out", at which point everything was swapped
to disk and it took half an hour just to get a shell to find out
what was wrong!).

At least there you are expecting it as you push the algorithms.
What got me a few years ago was free() that was O(n) in the number
of allocations made, and thus O(n*n) for freeing everything. The
problem showed up with gcc on DJGPP, with VC on W98, with lcc-win32
on W98, i.e. apparently universal. That made me write nmalloc for
DJGPP, which has an O(1) free algorithm.

The problem generally became obnoxious at between 40,000 and
250,000 allocations, IIRC.

 

[Michael Wojcik]

I didn't say that it was necessarily memory constraints (although all
Real World(tm) ststems do have memory constraints).

I didn't say you did. I was providing an additional argument which
supported your general thesis, in fact.

Not every Usenet followup is a contradiction.

 

[Keith Thompson]

I didn't say you did. I was providing an additional argument which
supported your general thesis, in fact.

Not every Usenet followup is a contradiction.

Yes, it is.

 

[Chris Croughton]

I didn't say you did. I was providing an additional argument which
supported your general thesis, in fact.

Apologies for that, I misread your post.

Not every Usenet followup is a contradiction.

I think the pantomime season is over <g>...

Chris C