Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #6156 > unrolled thread

Re: Array implementation of Stack

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Array implementation of Stack Mark Bluemel <mark_bluemel@pobox.com> - 2011-06-16 15:05 +0100
    Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-16 20:12 +0100
      Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-16 19:35 +0000
        Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-16 22:44 +0100
          Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-16 15:26 -0700
          Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-17 14:10 +0000
            Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-17 08:12 -0700
              Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-17 15:16 +0000
                Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-17 10:46 -0700
                Re: Array implementation of Stack Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-17 12:22 -0600
                Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-18 02:35 +0100
                  Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-17 19:38 -0700
                  Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-18 09:45 +0000
                    Re: Array implementation of Stack Ike Naar <ike@sverige.freeshell.org> - 2011-06-18 10:18 +0000
                      Re: Array implementation of Stack Chad <cdalten@gmail.com> - 2011-06-28 21:43 -0700
                    Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-18 11:40 -0700
                    Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-22 03:46 +0100
                      Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-22 08:41 +0000
                        Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-22 08:50 -0700
                          Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-22 16:30 +0000
                            Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-23 16:37 +0100
                              Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-23 16:27 +0000
                              Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-23 10:08 -0700
                                Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-24 04:13 -0700
                                  Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-24 07:47 -0700
                                    Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-24 10:13 -0700
                                      Re: Array implementation of Stack James Kuyper <jameskuyper@verizon.net> - 2011-06-24 21:56 -0400
                                        Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-24 23:00 -0700
                                          Re: Array implementation of Stack James Kuyper <jameskuyper@verizon.net> - 2011-06-25 07:03 -0400
                                            Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-25 08:49 -0700
                            Re: Array implementation of Stack Michael Press <rubrum@pacbell.net> - 2011-06-23 20:49 -0700
                              Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-24 13:26 +0000
                                Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-24 10:25 -0700
                          Re: Array implementation of Stack gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-22 20:40 +0000
                          Re: Array implementation of Stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-06-23 01:31 -0700
                        Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-23 15:53 +0100
                          Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-23 15:02 +0000
                      Re: Array implementation of Stack Stephen Sprunk <stephen@sprunk.org> - 2011-06-22 09:06 -0500
                        Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-23 15:39 +0100
                          Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-23 14:57 +0000
                            Re: Array implementation of Stack cri@tiac.net (Richard Harter) - 2011-06-23 19:19 +0000
                              Re: Array implementation of Stack luser- -droog <mijoryx@yahoo.com> - 2011-06-24 01:44 -0700
                                Re: Array implementation of Stack cri@tiac.net (Richard Harter) - 2011-06-24 21:55 +0000
                              Re: Array implementation of Stack Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-24 05:21 -0700
                          Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-23 08:25 -0700
                            Re: Array implementation of Stack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-06-23 16:57 +0100
                              Re: Array implementation of Stack luser- -droog <mijoryx@yahoo.com> - 2011-06-23 12:49 -0700
                                Re: Array implementation of Stack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-06-23 22:19 +0100
                                  Re: Array implementation of Stack luser- -droog <mijoryx@yahoo.com> - 2011-06-24 01:35 -0700
                              Re: Array implementation of Stack Stephen Sprunk <stephen@sprunk.org> - 2011-06-23 22:03 -0500
                                Re: Array implementation of Stack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-06-24 11:47 +0100
                            Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-23 16:52 +0100
                              Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-23 10:11 -0700
              Re: Array implementation of Stack Mark Storkamp <mstorkamp@yahoo.com> - 2011-06-17 10:55 -0500
                Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-17 13:00 -0700
                  Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-17 20:24 +0000
                    Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-17 14:24 -0700
                      Re: Array implementation of Stack Ralf Damaschke <rwspam@gmx.de> - 2011-06-17 21:57 +0000
                        Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-17 16:07 -0700
                          Re: Array implementation of Stack Ralf Damaschke <rwspam@gmx.de> - 2011-06-18 16:59 +0000
                        Re: Array implementation of Stack Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-18 11:05 +0100
                      Re: Array implementation of Stack Willem <willem@toad.stack.nl> - 2011-06-18 09:55 +0000
                        Re: Array implementation of Stack Keith Thompson <kst-u@mib.org> - 2011-06-18 11:49 -0700
                          Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-22 10:22 -0700
                            Re: Array implementation of Stack "io_x" <a@b.c.invalid> - 2011-06-23 09:02 +0200
                              Re: Array implementation of Stack "io_x" <a@b.c.invalid> - 2011-06-23 09:57 +0200
                              Re: Array implementation of Stack "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-24 03:00 -0700
              Re: Array implementation of Stack Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-24 00:16 -0700
      Re: Array implementation of Stack "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 13:35 -0700
        Re: Array implementation of Stack Ian Collins <ian-news@hotmail.com> - 2011-06-17 08:50 +1200
          Re: Array implementation of Stack "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 14:15 -0700
            Re: Array implementation of Stack "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 14:19 -0700
            Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-16 22:51 +0100
              Re: Array implementation of Stack "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 15:27 -0700
        Re: Array implementation of Stack Rui Maciel <rui.maciel@gmail.com> - 2011-06-16 22:43 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#6156 — Re: Array implementation of Stack

On 06/16/2011 11:00 AM, arnuld wrote:
> WANTED:  To write an array implementation of Stack.

Really?

> void pop(struct elm_stack* );

Why would pop() not return a value?

[toc] | [next] | [standalone]

#6178

Mark Bluemel wrote:

> On 06/16/2011 11:00 AM, arnuld wrote:
>> WANTED:  To write an array implementation of Stack.
> 
> Really?
> 
>> void pop(struct elm_stack* );
> 
> Why would pop() not return a value?

Why should pop return a value?  


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#6179

Rui Maciel wrote:
) Mark Bluemel wrote:
)
)> On 06/16/2011 11:00 AM, arnuld wrote:
)>> WANTED:  To write an array implementation of Stack.
)> 
)> Really?
)> 
)>> void pop(struct elm_stack* );
)> 
)> Why would pop() not return a value?
)
) Why should pop return a value?  

For the same reason as push() takes two arguments.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#6189

Willem wrote:

> ) Why should pop return a value?
> 
> For the same reason as push() takes two arguments.
> 

And what reason is that?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#6193

Rui Maciel <rui.maciel@gmail.com> writes:
> Willem wrote:
>> ) Why should pop return a value?
>> 
>> For the same reason as push() takes two arguments.
>
> And what reason is that?

Convenience.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#6234

Rui Maciel wrote:
) Willem wrote:
)
)> ) Why should pop return a value?
)> 
)> For the same reason as push() takes two arguments.
)> 
)
) And what reason is that?

I don't know.  Ask the person who proposed the API upthread.

If you insist that pop() shouldn't return a value, then push()
should not take a value either, just a stack.  Otherwise it
is plainly inconsistent.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#6246

Willem <willem@toad.stack.nl> writes:
> Rui Maciel wrote:
> ) Willem wrote:
> )
> )> ) Why should pop return a value?
> )> 
> )> For the same reason as push() takes two arguments.
> )> 
> )
> ) And what reason is that?
>
> I don't know.  Ask the person who proposed the API upthread.
>
> If you insist that pop() shouldn't return a value, then push()
> should not take a value either, just a stack.  Otherwise it
> is plainly inconsistent.

pop() not returning a value makes some sense if you think that
shrinking the stack and retrieving the top element should be
separate operations.

push() without an argument would have to push an indeterminate or
default value onto the stack.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#6249

Keith Thompson wrote:
) pop() not returning a value makes some sense if you think that
) shrinking the stack and retrieving the top element should be
) separate operations.

push() not taking a value makes some sense if you think that
expanding the stack and setting the top element should be
separate operations.

) push() without an argument would have to push an indeterminate or
) default value onto the stack.

pop() without a return value would have to discard the value it
takes from the stack.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#6282

Willem <willem@toad.stack.nl> writes:
> Keith Thompson wrote:
> ) pop() not returning a value makes some sense if you think that
> ) shrinking the stack and retrieving the top element should be
> ) separate operations.
>
> push() not taking a value makes some sense if you think that
> expanding the stack and setting the top element should be
> separate operations.

*And* if you don't mind the new top of the stack having a meaningless
value.  The two cases are not equivalent.

> ) default value onto the stack.
>
> pop() without a return value would have to discard the value it
> takes from the stack.

Of course.  Sometimes that's what you want to do.

I'm not arguing that pop() *shouldn't* have a return value, just
that it's not entirely insane for it not to.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#6286

Willem <willem@toad.stack.nl> writes:

> Keith Thompson wrote:
> ) pop() not returning a value makes some sense if you think that
> ) shrinking the stack and retrieving the top element should be
> ) separate operations.
>
> push() not taking a value makes some sense if you think that
> expanding the stack and setting the top element should be
> separate operations.

This would be an extraordinarily idiosyncratic usage.

> ) push() without an argument would have to push an indeterminate or
> ) default value onto the stack.
>
> pop() without a return value would have to discard the value it
> takes from the stack.

pop() without a return value wouldn't actually have to take a value from
the stack; it just moves the pointer.

> SaSW, Willem

[toc] | [prev] | [next] | [standalone]

#6326

Willem wrote:

> push() not taking a value makes some sense if you think that
> expanding the stack and setting the top element should be
> separate operations.

What's the point of that, besides needlessly allocating memory that your 
program does not use?


> pop() without a return value would have to discard the value it
> takes from the stack.

Well. that's the point of pop().  You store your data with push(), you 
access the data with top() and you discard your data with pop(). 


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#6327

Rui Maciel <rui.maciel@gmail.com> writes:
> Willem wrote:
>> push() not taking a value makes some sense if you think that
>> expanding the stack and setting the top element should be
>> separate operations.
>
> What's the point of that, besides needlessly allocating memory that your 
> program does not use?
>
>
>> pop() without a return value would have to discard the value it
>> takes from the stack.
>
> Well. that's the point of pop().  You store your data with push(), you 
> access the data with top() and you discard your data with pop(). 

*Or* you use pop() to retrieve the value of the top element *and*
shorten the stack, since it's common to want to do both at once.

Or you have two different pop() operations (perhaps with different
names), one that returns the value and one that discards it.

Or pop() returns the value, but you can discard it yourself if
you like.

That's not to suggest that there shouldn't also be a top() operation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#6342

Rui Maciel wrote:
) Willem wrote:
)
)> push() not taking a value makes some sense if you think that
)> expanding the stack and setting the top element should be
)> separate operations.
)
) What's the point of that, besides needlessly allocating memory that your 
) program does not use?

What part of 'and setting the top element' do you not understand ?

But I will make it easy for you: top() returns an lvalue, which can
be used to both read and set the top element.

)> pop() without a return value would have to discard the value it
)> takes from the stack.
)
) Well. that's the point of pop().  You store your data with push(), you 
) access the data with top() and you discard your data with pop(). 

Do you know what "begging the question" means ?

Here's an example for you:

The point of pop() is to give you the top element of the stack.
So there's no point in having a separate top() operation.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#6346

On 2011-06-18, Willem <willem@toad.stack.nl> wrote:
> The point of pop() is to give you the top element of the stack.
> So there's no point in having a separate top() operation.

pop() gives you the top element, but it also has the side effect
of removing the top element from the stack.
Sometimes you want to look at the top element without modifying the stack.
If there isn't a separate top() operation, then of course

  dosomethingwith(top());

can be emulated by

  temp = pop(); push(temp); dosomethingwith(temp);

but the latter looks a bit awkward.

[toc] | [prev] | [next] | [standalone]

#7184

On Jun 18, 3:18 am, Ike Naar <i...@sverige.freeshell.org> wrote:
> On 2011-06-18, Willem <wil...@toad.stack.nl> wrote:
>
> > The point of pop() is to give you the top element of the stack.
> > So there's no point in having a separate top() operation.
>
> pop() gives you the top element, but it also has the side effect
> of removing the top element from the stack.
> Sometimes you want to look at the top element without modifying the stack.
> If there isn't a separate top() operation, then of course
>
>   dosomethingwith(top());
>
> can be emulated by
>
>   temp = pop(); push(temp); dosomethingwith(temp);
>
> but the latter looks a bit awkward.


What I've sometimess seen people do is like the following..

/*Return and remove the top element from the stack*/
int pop() {
  return elements[--size];
}

/*Return the top element from the stack*/
int peek() {
  return elmenets[size - 1];
}

[toc] | [prev] | [next] | [standalone]

#6367

Willem <willem@toad.stack.nl> writes:
> Rui Maciel wrote:
> ) Willem wrote:
> )
> )> push() not taking a value makes some sense if you think that
> )> expanding the stack and setting the top element should be
> )> separate operations.
> )
> ) What's the point of that, besides needlessly allocating memory that your 
> ) program does not use?
>
> What part of 'and setting the top element' do you not understand ?

"and setting the top element" is perfectly clear.  What's not clear is
why it should be a separate operation from expanding the stack.

Of course you *could* provide a function that extends the stack
by one element and leaves the top element with some default or
unspecified value.  But I can't think of a realistic scenario where
you'd want to do that without already knowing what value you want
to store.

> But I will make it easy for you: top() returns an lvalue, which can
> be used to both read and set the top element.

How does a function return an lvalue?  Or do you intend top() to be a
macro?

top() could return a *pointer* value, but I don't recall ever seeing a
stack implementation that does that.

Have you actually seen a stack implementation whose push() operation
extends the stack without storing a value in the new top element?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#6592

Willem wrote:

> Rui Maciel wrote:
> ) Willem wrote:
> )
> )> push() not taking a value makes some sense if you think that
> )> expanding the stack and setting the top element should be
> )> separate operations.
> )
> ) What's the point of that, besides needlessly allocating memory that your
> ) program does not use?
> 
> What part of 'and setting the top element' do you not understand ?

I don't understand how you use the word "separately" without understanding 
what it means.  If you understood what it meant then you would understand 
that, in a scenario where "expanding the stack and setting the top element" 
are separate operations, the "expanding the stack" bit involves allocating 
memory and nothing more, without having the faintest guarantee that your 
program will ever use that memory or even initialize the memory it 
allocates.

So, while the push(value) approach guarantees that whenever you call 
push(value) your program always initializes the memory which is allocated, 
if you set your push() to do nothing more than allocate memory, then you 
only gain a way to needlessly allocate memory to your stack which you may or 
may not use.  By doing this, your push() represents an excellent way to 
needlessly fill a stack with uninitialized variables, which is a frequent 
cause of countless bugs, including security vulnerabilities.


> But I will make it easy for you: top() returns an lvalue, which can
> be used to both read and set the top element.

Tweaking push() has absolutely no impacto on what top() does.  So, this is a 
non-issue.


> )> pop() without a return value would have to discard the value it
> )> takes from the stack.
> )
> ) Well. that's the point of pop().  You store your data with push(), you
> ) access the data with top() and you discard your data with pop().
> 
> Do you know what "begging the question" means ?
> 
> Here's an example for you:
> 
> The point of pop() is to give you the top element of the stack.

No, it is not.  That's what top() is designed to do.  Do you even know what 
a stack is?


> So there's no point in having a separate top() operation.

For you to make such a claim then it becomes quite clear that you never used 
a stack.  If you are interested in learning why is there a need to top() 
without pop()ing the stack then be my guest and write a small LL parser 
using a stack to store the parser states and try to do that without calling 
top().  


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#6598

Rui Maciel wrote:
) in a scenario where "expanding the stack and setting the top element" 
) are separate operations, the "expanding the stack" bit involves allocating 
) memory and nothing more, without having the faintest guarantee that your 
) program will ever use that memory or even initialize the memory it 
) allocates.

Yes, and ?

) if you set your push() to do nothing more than allocate memory, then you 
) only gain a way to needlessly allocate memory to your stack which you may or 
) may not use.

You're contradicting yourself.  It's only needless if you don't use it.

)> )> pop() without a return value would have to discard the value it
)> )> takes from the stack.
)> )
)> ) Well. that's the point of pop().  You store your data with push(), you
)> ) access the data with top() and you discard your data with pop().
)> 
)> Do you know what "begging the question" means ?
)> 
)> Here's an example for you:
   ^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you really too stupid to read properly ?

)> The point of pop() is to give you the top element of the stack.
)
) No, it is not.  That's what top() is designed to do.  Do you even know what 
) a stack is?

BEGGING THE QUESTION AGAIN.
We're arguing about what the different stack operations should do.
So using "it's defined to do that" is begging the question.

There, I hope I spelled it out for you enough.

)> So there's no point in having a separate top() operation.
)
) For you to make such a claim then it becomes quite clear that you never used 
) a stack.

You're an idiot too, dear.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#6619

Willem <willem@toad.stack.nl> writes:
> Rui Maciel wrote:
> ) in a scenario where "expanding the stack and setting the top element" 
> ) are separate operations, the "expanding the stack" bit involves allocating 
> ) memory and nothing more, without having the faintest guarantee that your 
> ) program will ever use that memory or even initialize the memory it 
> ) allocates.
>
> Yes, and ?
>
> ) if you set your push() to do nothing more than allocate memory, then you 
> ) only gain a way to needlessly allocate memory to your stack which you may or 
> ) may not use.
>
> You're contradicting yourself.  It's only needless if you don't use it.
>
[...]

> )> The point of pop() is to give you the top element of the stack.
> )
> ) No, it is not.  That's what top() is designed to do.  Do you even know what 
> ) a stack is?
>
> BEGGING THE QUESTION AGAIN.
> We're arguing about what the different stack operations should do.
> So using "it's defined to do that" is begging the question.
>
> There, I hope I spelled it out for you enough.
[...]

Willem, you have a point.  There is no One True Way to define the
set of operations available for a stack.

On the other hand, some operations make sense and some do not.

I don't believe you've demonstrated that a push() operation that
extends the stack without storing a value in the top element makes
any sense.

Under what circumstances would you want to use such an operation?
As far as I can see, extending the stack is *always* immediately
followed by storing a value in the new top element.  How would it
be advantageous to separate those operations?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#6625

Keith Thompson wrote:
) Willem, you have a point.  There is no One True Way to define the
) set of operations available for a stack.

Thank you, that was exactly the point I was trying to make.

) On the other hand, some operations make sense and some do not.
)
) I don't believe you've demonstrated that a push() operation that
) extends the stack without storing a value in the top element makes
) any sense.

I never tried to demonstrate it.  I just got very annoyed by people
claiming that thier views on stacks are the One True Way, and using
bad logic to argue their points.

Nobody tried to argue *why* it maked sense to have the stack operations
work the way they say they should work.  They just *asserted* it.

) Under what circumstances would you want to use such an operation?
) As far as I can see, extending the stack is *always* immediately
) followed by storing a value in the new top element.  How would it
) be advantageous to separate those operations?

The most obvious one would be is your application needs a way to replace
or change the top value of a stack.  Then a push() which sets the value
also would be redundant(*).

Another one would be if the 'value' on the stack is actually a large
entity, such as a struct, and passing the whole struct would be
a performance issue, especially if you're only using a part of it.

This is especially true if the stack is a way of being able to step
back to a previous saved state.

As a real-life example of that, look at a postscript interpreter, which
keeps a stack of graphics contexts.  Or a chess playing program, which
needs to save the current state of the board to be able to try different
moves.


Another example would be when growing the stack would be a very costly
operation, and putting items in slots very cheap.  In that case, it would
be very advantageous if you could grow the stack by a large step, and
then insert all the items one by one.

One could also imagine having a stack that stores char values, but using it
for different-sized objects/blobs.


Oh, and as a very real-life example, look at the way that a C compiler uses
stack frames: it allocates a whole frame in one go, and then uses the space
it created for different variables, objects, et cetera.



*) Note that I'm arguing that push()-takes-value and pop()-returns-value
   are equivalent, not that it's better or worse than no-value.
   In this case, the argument against pop() returning a value seems to
   be that it's redundant, so therefore push() taking a value is also.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web