«

is it possible not to decrement the top variable after we remove(or
retreive) a file from a stack
>MY IDEA is:> if top is not decremented the stack is like it has some files existing in it with the top most file empty
>i.e, something like hiding the files by one step (or one position of stack)
>i.e,if someone tries to extract the top most file he see's that it is empty thus assumes the stack to be empty.
>can this view be applied effectively
NOTE :HERE file can be regarded as an entity (a NO. or a character or
an operator)stored in the stack.
>top is inbuilt var. used in stacks

srikanth wrote:

> is it possible not to decrement the top variable after we remove(or
> retreive) a file from a stack
>>MY IDEA is:> if top is not decremented the stack is like it has some
>>files existing in it with the top most file empty i.e, something like
>>hiding the files by one step (or one position of stack) i.e,if someone
>>tries to extract the top most file he see's that it is empty thus assumes
>>the stack to be empty.
>>can this view be applied effectively
> NOTE :HERE file can be regarded as an entity (a NO. or a character or
> an operator)stored in the stack.
>>top is inbuilt var. used in stacks

This is not an (ISO/ANSI) C question. Try comp.programming (and give
concrete examples for what you're asking).

--
Chris "sparqling" Dollin
"Who do you serve, and who do you trust?"

"srikanth" <> writes:
> is it possible not to decrement the top variable after we remove(or
> retreive) a file from a stack
>>MY IDEA is:> if top is not decremented the stack is like it has some files existing in it with the top most file empty
>>i.e, something like hiding the files by one step (or one position of stack)
>>i.e,if someone tries to extract the top most file he see's that it is empty thus assumes the stack to be empty.
>>can this view be applied effectively
> NOTE :HERE file can be regarded as an entity (a NO. or a character or
> an operator)stored in the stack.
>>top is inbuilt var. used in stacks

This doesn't seem to be a C question.

You seem to be misusing the term "file".

">" characters at the beginning of a line are used to quote material
from previous articles.

Please read <http://cfaj.freeshell.org/google/>.

--
Keith Thompson (The_Other_Keith) kst- <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.

sir i will make it simpler
>eg: let the stack be made of blocks i each block say i store one number
>eg: a stack containing
6
5
1
>now i retrieve 6 from the stack (so i have to DEC the top variable) to point to block containing 5
>****now,if i dont decrement the top the stack is like
/*empty*/
5
1
>i.e, it is like hiding 5 and 1 by one block in the stack
>my Q was can this be applied effectively

please leave some conext in your posts. Learn to quote properly. Listen
to what
people tell you. You have already been told '>' characters mark
previous posts.

Your post should have looked something like this
***


srikanth wrote:
> someone replied to srikanth
> > srikanth wrote:

> > > is it possible not to decrement the top variable after we remove(or
> > > retreive) a file from a stack
> > > MY IDEA is: if top is not decremented the stack is like it has some
> > > files existing in it with the top most file empty i.e, something like
> > > hiding the files by one step (or one position of stack) i.e,if someone
> > > tries to extract the top most file he see's that it is empty thus assumes
> > > the stack to be empty.
> > > can this view be applied effectively
> > > NOTE :HERE file can be regarded as an entity (a NO. or a character or
> > > an operator)stored in the stack.
> > > top is inbuilt var. used in stacks

you need to explain why you are trying to do this. You seem to want (?)
a
stack from which you can remove items and leave an empty item at the
top.
Why?

Are you describing a bug in a stack implementation or do you really
want to
do this?

Stacks normally remove the "slot" from the stack when the item is
removed.
So if you don't want empty "slots" then don't leave them on the stack.
And
if you do want them you'll need some way to indicate the slot is empty
(special value or flag).


> > This is not an (ISO/ANSI) C question. Try comp.programming (and give
> > concrete examples for what you're asking).

he's indicating this isn't a C language problem but a problem in
program design.
You can't think about writing code until you have a clear idea of what
is required
from this data structure.

> sir i will make it simpler
> eg: let the stack be made of blocks i each block say i store one number
> eg: a stack containing
>
> 6
> 5
> 1
>
> now i retrieve 6 from the stack (so i have to DEC the top variable) to point to
> block containing 5 ****now,if i dont decrement the top...

WHY would you do that?

> ...the stack is like
>
> /*empty*/
> 5
> 1
>
> i.e, it is like hiding 5 and 1 by one block in the stack
> my [question] was[,] can this be applied effectively[?]

that's your choice. If I had a good reason for hiding things from users
of the
data structure I might provide special is_empty() predicates. *You*
have to
decide what semantics your DS must have. Is a stack empty when its
top slot is empty? Can you remove from a pseudo-empty stack?
Can you add? How do you restore the stack to its usual semantics?

By all means play around with these things but if you provide DSs with
poorly defined semantics your program will behave badly. ie. crash,
destroy data, detonate the cruise missile etc.


--
Nick Keighley

Nick Keighley wrote:

(in replying to srikanth)
>
> please leave some conext in your posts. Learn to quote properly.
> Listen to what people tell you. You have already been told '>'
> characters mark previous posts.

He has been told this many times, and just ignores it. The only
thing left is to plonk and ignore him.

--
"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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>