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

[mohd hisham]

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.

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

[infobahn]

mohd hisham wrote:

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.
Which do you mean? Queues are generally LIFO. Stacks are generally FIFO.

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

I can get you started, but you'll need to fill in the blanks.

#include <stdio.h>

int insert(void *p)
{
return 0;
}

int delete(void *p)
{
return 0;
}

int display(void *p)
{
return 0;
}

int main(void)
{
insert(NULL);
delete(NULL);
display(NULL);
return 0;
}

[John Valko]

mohd hisham wrote:

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.

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

It appears you've forgotten to post the code you've written so far to
ask about. Post it and then perhaps you can get some help.

[Mike Wahler]

"mohd hisham" <sh*******@yahoo.com> wrote in message
news:41********@news.tm.net.my...

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.

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

If you contact me privately and agree upon a pay
rate, I'll certainly write it for you (if you can
convince me this isn't a homework assignment).

However, if you try to write it yourself, but get stuck,
and post your code along with specific questions,
I (and I suspect many others) will help you for free.

-Mike

[Keith Thompson]

"mohd hisham" <sh*******@yahoo.com> writes:

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.

Give us your instructor's e-mail address; we'll just send it to him
directly.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[dandelion]

"infobahn" <in******@btinternet.com> wrote in message
news:41**************@btinternet.com...

mohd hisham wrote:

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.

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

Leave out "generally" and i'd agree. Insertions and deletions (at the
appropriate places) are legitimate operations in both.

I like your "skeleton" code. Should not be a problem to fill in the blanks.

[Keith Thompson]

"osmium" <r1********@comcast.net> writes:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Randy Howard]

In article <41********@news.tm.net.my>, sh*******@yahoo.com says...

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.

--
Randy Howard (2reply remove FOOBAR)
"For some reason most people seem to be born without the part
of the brain that understands pointers." -- Joel Spolsky

[Chris Croughton]

On Tue, 1 Feb 2005 08:23:29 -0800, osmium
<r1********@comcast.net> wrote:

"dandelion" writes:

"osmium" <r1********@comcast.net> wrote in message
news:36*************@individual.net...

Why does a double ended queue have overflow? As I said, you can run out of

hardware, but an application programmer doesn't usually consider this.

As the storage for the queue, you would normally use a predimensioned
array,
which can be full adn hence, overflowed.

eg

int dequeue[Q_SIZE];

would overflow if more than Q_SIZE elements have been inserted.

Well, that strikes me as plain silly. You just flushed one of the main
advantages of the data structure right down the drain.

It depends why and how you want to use it. A deque using a circular
fixed-size buffer can be very useful in some circumstances (a
flow-controlled input buffer where a character can be "pushed back", for
instance). Or a queue of processes to be run where the number of
processes in the system is fixed.
I have often modeled lists and stacks by use of an array. But I consider
those very light duty, not fit for general consumption.
Perhaps yours were. I've seen plenty in embedded real-time systems in
the Real World(tm). 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).
In my experience an array is an especially easy way to make a stack, I
usually have a handle on the upper limit. For lists, in general, I
have no decent guess to work with.

Plenty of applications do have more than a "decent guess" to work with,
especially in embedded systems where resources are strictly limited so
that the behaviour is known (limited number of tasks and message queues,
for example).

Chris C

[ozbear]

On Tue, 1 Feb 2005 05:25:16 -0800, "osmium" <r1********@comcast.net>
wrote:
<snip>

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
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Michael Mair]

Lew Pitcher wrote:

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

Michael Mair wrote:

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/fo...&action=Search
and
http://wombat.doc.ic.ac.uk/foldoc/fo...&action=Search

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

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Lew Pitcher]

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

Michael Mair wrote:

Lew Pitcher wrote:

Michael Mair wrote:

Lew Pitcher wrote:
infobahn wrote:
> 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?

[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]

On Wed, 02 Feb 2005 02:37:30 +0000, ozbear wrote:

On Tue, 1 Feb 2005 05:25:16 -0800, "osmium" <r1********@comcast.net>
wrote:
<snip>

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.

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

Lawrence

[Lawrence Kirby]

On Tue, 01 Feb 2005 18:24:36 +0000, Chris Croughton wrote:

On Tue, 1 Feb 2005 08:23:29 -0800, osmium
<r1********@comcast.net> wrote:
....

I have often modeled lists and stacks by use of an array. But I consider
those very light duty, not fit for general consumption.

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]

On Wed, 02 Feb 2005 11:06:44 +0000, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Tue, 01 Feb 2005 18:24:36 +0000, Chris Croughton wrote:

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.

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]

In article <sl******************@ccserver.keris.net>, Chris Croughton <ch***@keristor.net> writes:

On Tue, 1 Feb 2005 08:23:29 -0800, osmium
<r1********@comcast.net> wrote:

I have often modeled lists and stacks by use of an array. But I consider
those very light duty, not fit for general consumption.

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 mi************@microfocus.com

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]

On 2 Feb 2005 21:59:02 GMT, Michael Wojcik
<mw*****@newsguy.com> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes:

On Tue, 1 Feb 2005 08:23:29 -0800, osmium
<r1********@comcast.net> wrote:

> I have often modeled lists and stacks by use of an array. But I consider
> those very light duty, not fit for general consumption.
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.

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]

Chris Croughton wrote:

.... 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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Michael Wojcik]

In article <sl******************@ccserver.keris.net>, Chris Croughton <ch***@keristor.net> writes:

On 2 Feb 2005 21:59:02 GMT, Michael Wojcik
<mw*****@newsguy.com> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes:

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.

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.

--
Michael Wojcik mi************@microfocus.com

See who I'm! -- Jackie Chan and unknown subtitler, _Dragons Forever_

[Keith Thompson]

mw*****@newsguy.com (Michael Wojcik) writes:

In article <sl******************@ccserver.keris.net>, Chris
Croughton <ch***@keristor.net> writes:

On 2 Feb 2005 21:59:02 GMT, Michael Wojcik
<mw*****@newsguy.com> wrote:

> In article <sl******************@ccserver.keris.net>, Chris Croughton
> <ch***@keristor.net> writes:
>>
>> 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.

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.

Yes, it is.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Croughton]

On 4 Feb 2005 13:27:00 GMT, Michael Wojcik
<mw*****@newsguy.com> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton <ch***@keristor.net> writes:

On 2 Feb 2005 21:59:02 GMT, Michael Wojcik
<mw*****@newsguy.com> wrote:

> In article <sl******************@ccserver.keris.net>, Chris Croughton
> <ch***@keristor.net> writes:
>>
>> 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.
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.

Apologies for that, I misread your post.
Not every Usenet followup is a contradiction.

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

Chris C