Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #6156 > unrolled thread
| Started by | Mark Bluemel <mark_bluemel@pobox.com> |
|---|---|
| First post | 2011-06-16 15:05 +0100 |
| Last post | 2011-06-16 22:43 +0100 |
| Articles | 15 on this page of 75 — 23 participants |
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.
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-06-18 11:05 +0100 |
| Message-ID | <87mxhfh2ti.fsf@temporary-address.org.uk> |
| In reply to | #6305 |
Ralf Damaschke <rwspam@gmx.de> writes: > Keith Thompson <kst-u@mib.org> wrote: > >> Because after you extend the stack, you have to put *something* >> in the top slot. Requiring the user to provide a value means >> you don't have to complicate the semantics by inventing >> something to put there. > > That's thought too short. You could also first supply a value to > be placed on the stack with the next push operation. Even better, you could have a structure to allow you to queue up a list of items that will be put on the stack one per push operation. You'd need an operation to push an item onto the queue of course. But I have an idea: why not instead first supply a value to be placed on the queue with the next queue-push operation. Even better, you could ... -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-06-18 09:55 +0000 |
| Message-ID | <slrnivotg5.2vnc.willem@toad.stack.nl> |
| In reply to | #6302 |
Keith Thompson wrote:
) Willem <willem@toad.stack.nl> writes:
)> Kleuskes & Moos wrote:
)> ) Hmmm... Usually i like pop to just pop things off the stack, no more,
)> ) no less. I developed a strong dislike for 'two-for-one' operations. I
)> ) developed an even stronger dislike for all kinds of renaming schemes
)> ) which only obfuscate basically very simple operations. And 'dup' is a
)> ) commonly used stack primitive in it's own right, which exists neatly
)> ) alongside push, pop and top.
)>
)> Then why should push() do two things at once ?
)> It extends the stack, and then places something in the top slot.
)> I have a strong dislike for inconsistent operations.
)
) Because after you extend the stack, you have to put *something* in the
) top slot. Requiring the user to provide a value means you don't have to
) complicate the semantics by inventing something to put there.
For the record: this is comp.lang.c.
If you extend the stack you don't have to put *anything* in the top slot.
) push() and pop() are two different operations. They don't have to
) be consistent if that consistency comes at the cost of convenience.
What is inconvenient about pop() returning whatever it takes off
the stack ? push() takes two values for convenience,
pop() returns a value for convenience. And it's consistent to boot.
So, I stay by my statement, that pop() returns a value for the same
reason as push() takes two values, without stating what that reason is.
You seem to think it's convenience, fine by me.
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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-18 11:49 -0700 |
| Message-ID | <lnpqmbx9e3.fsf@nuthaus.mib.org> |
| In reply to | #6343 |
Willem <willem@toad.stack.nl> writes:
> Keith Thompson wrote:
> ) Willem <willem@toad.stack.nl> writes:
> )> Kleuskes & Moos wrote:
> )> ) Hmmm... Usually i like pop to just pop things off the stack, no more,
> )> ) no less. I developed a strong dislike for 'two-for-one' operations. I
> )> ) developed an even stronger dislike for all kinds of renaming schemes
> )> ) which only obfuscate basically very simple operations. And 'dup' is a
> )> ) commonly used stack primitive in it's own right, which exists neatly
> )> ) alongside push, pop and top.
> )>
> )> Then why should push() do two things at once ?
> )> It extends the stack, and then places something in the top slot.
> )> I have a strong dislike for inconsistent operations.
> )
> ) Because after you extend the stack, you have to put *something* in the
> ) top slot. Requiring the user to provide a value means you don't have to
> ) complicate the semantics by inventing something to put there.
>
> For the record: this is comp.lang.c.
I'm aware of that.
> If you extend the stack you don't have to put *anything* in the top slot.
Ok, you don't *have* to, but there's no reason not to do so.
> ) push() and pop() are two different operations. They don't have to
> ) be consistent if that consistency comes at the cost of convenience.
>
> What is inconvenient about pop() returning whatever it takes off
> the stack ? push() takes two values for convenience,
> pop() returns a value for convenience. And it's consistent to boot.
I never said that pop() shouldn't return the top value -- but it
doesn't really need to.
Extending the stack and storing a value in the new top element are
logically tied together. I can't think of a scenario where it would
make sense to extend the stack *without* storing a value. Because of
that, I don't think it makes sense to have a push() operation that
doesn't take an argument specifying the new value to be stored.
Accessing the top element and shrinking the stack by one element
are not tied together in the same way. I might want to access the
same top element multiple times, or I might want to discard the
top element without caring what it was; either leaves the stack in
a well defined state.
If I want a conceptually pure stack implementation (perhaps in a
classroom setting), I might just provide a push() that takes an
element value and pop() that returns an element value. If I want
something more convenient for real-world use, I might provide those
operations *plus* a top() function that returns the top element
value, an function that returns the Nth element from the top, and
a pop()-like function that discards the result. (The latter isn't
necessary in C, since the caller can easily discard the result.)
> So, I stay by my statement, that pop() returns a value for the same
> reason as push() takes two values, without stating what that reason is.
>
> You seem to think it's convenience, fine by me.
Did you have some other reason in mind? I'm not even entirely sure
what you're arguing.
--
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]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-22 10:22 -0700 |
| Message-ID | <e03bf2f5-6fac-4ccc-bc7d-13143f2925c0@d1g2000yqm.googlegroups.com> |
| In reply to | #6369 |
On Jun 18, 8:49 pm, Keith Thompson <ks...@mib.org> wrote: > Willem <wil...@toad.stack.nl> writes: > > Keith Thompson wrote: > > ) Willem <wil...@toad.stack.nl> writes: > > )> Kleuskes & Moos wrote: > > )> ) Hmmm... Usually i like pop to just pop things off the stack, no more, > > )> ) no less. I developed a strong dislike for 'two-for-one' operations. I > > )> ) developed an even stronger dislike for all kinds of renaming schemes > > )> ) which only obfuscate basically very simple operations. And 'dup' is a > > )> ) commonly used stack primitive in it's own right, which exists neatly > > )> ) alongside push, pop and top. > > )> > > )> Then why should push() do two things at once ? > > )> It extends the stack, and then places something in the top slot. > > )> I have a strong dislike for inconsistent operations. > > ) > > ) Because after you extend the stack, you have to put *something* in the > > ) top slot. Requiring the user to provide a value means you don't have to > > ) complicate the semantics by inventing something to put there. > > > For the record: this is comp.lang.c. > > I'm aware of that. > > > If you extend the stack you don't have to put *anything* in the top slot. > > Ok, you don't *have* to, but there's no reason not to do so. > > > ) push() and pop() are two different operations. They don't have to > > ) be consistent if that consistency comes at the cost of convenience. > > > What is inconvenient about pop() returning whatever it takes off > > the stack ? push() takes two values for convenience, > > pop() returns a value for convenience. And it's consistent to boot. > > I never said that pop() shouldn't return the top value -- but it > doesn't really need to. > > Extending the stack and storing a value in the new top element are > logically tied together. I can't think of a scenario where it would > make sense to extend the stack *without* storing a value. Because of > that, I don't think it makes sense to have a push() operation that > doesn't take an argument specifying the new value to be stored. > > Accessing the top element and shrinking the stack by one element > are not tied together in the same way. I might want to access the > same top element multiple times, or I might want to discard the > top element without caring what it was; either leaves the stack in > a well defined state. > > If I want a conceptually pure stack implementation (perhaps in a > classroom setting), I might just provide a push() that takes an > element value and pop() that returns an element value. If I want > something more convenient for real-world use, I might provide those > operations *plus* a top() function that returns the top element > value, an function that returns the Nth element from the top, and > a pop()-like function that discards the result. (The latter isn't > necessary in C, since the caller can easily discard the result.) Nitpick to an otherwise excellent expose: That works fine if the content of your stack consists of simple values (int, floats and such), you get into trouble when the stack consists of structures. You can't just return a pointer, since the structure will b ''destroyed'' with a pop operation.
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-06-23 09:02 +0200 |
| Message-ID | <4e02e4bd$0$15669$4fafbaef@reader2.news.tin.it> |
| In reply to | #6631 |
"Kleuskes & Moos" <kleuske@xs4all.nl> ha scritto nel messaggio news:e03bf2f5-6fac-4ccc-bc7d-13143f2925c0@d1g2000yqm.googlegroups.com... #io_x Nitpick to an otherwise excellent expose: That works fine if the content of your stack consists of simple values (int, floats and such), you get into trouble when the stack consists of structures. You can't just return a pointer, since the structure will b ''destroyed'' with a pop operation. --------------- #yes for stack of structures, not for stack of pointers to structs # #char *a; #... #a=pop(stack); if(a==0) error(); #// a point to the struct or 0 #free(a); #
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-06-23 09:57 +0200 |
| Message-ID | <4e02f193$0$44200$4fafbaef@reader1.news.tin.it> |
| In reply to | #6699 |
"io_x" <a@b.c.invalid> ha scritto nel messaggio news:4e02e4bd$0$15669$4fafbaef@reader2.news.tin.it... > > "Kleuskes & Moos" <kleuske@xs4all.nl> ha scritto nel messaggio > news:e03bf2f5-6fac-4ccc-bc7d-13143f2925c0@d1g2000yqm.googlegroups.com... > #io_x > > Nitpick to an otherwise excellent expose: > > That works fine if the content of your stack consists of simple values > (int, floats and such), you get into trouble when the stack consists > of structures. You can't just return a pointer, since the structure > will b ''destroyed'' with a pop operation. > --------------- > #yes for stack of structures, not for stack of pointers to structs > # > #char *a; > #... > #a=pop(stack); if(a==0) error(); ^^^^^^^^^^^^^^^^^ a=pop(&stack); > #// a point to the struct or 0 > #free(a); > #
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-24 03:00 -0700 |
| Message-ID | <98ad62af-9b35-498e-9715-0cdb82de641a@y13g2000yqy.googlegroups.com> |
| In reply to | #6699 |
On Jun 23, 9:02 am, "io_x" <a...@b.c.invalid> wrote:
> "Kleuskes & Moos" <kleu...@xs4all.nl> ha scritto nel messaggionews:e03bf2f5-6fac-4ccc-bc7d-13143f2925c0@d1g2000yqm.googlegroups.com...
> #io_x
>
> Nitpick to an otherwise excellent expose:
>
> That works fine if the content of your stack consists of simple values
> (int, floats and such), you get into trouble when the stack consists
> of structures. You can't just return a pointer, since the structure
> will b ''destroyed'' with a pop operation.
> ---------------
> #yes for stack of structures, not for stack of pointers to structs
> #
> #char *a;
> #...
> #a=pop(stack); if(a==0) error();
> #// a point to the struct or 0
> #free(a);
> #
Having noted your corrigendum, and noting that a pointer is a "simple"
value, i still have a few problems with the above code. So let's
pretend to do a code review.
1) NULL might be stored quite legally on the stack, thus generating an
error when popping it off does not seem appropriate.
2) Assuming the code above is intended to fail on an empty stack, it
should fail _in_ the pop(stack) call, triggered by an inspection of
ToS. not afterwards.
3) If the code is supposed to fail _in_ pop, returning a proper error
code ('ERROR_STACK_EMPTY' or somesuch), seems to be appropriate, thus
preventing the pop-implementation to return any content.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-06-24 00:16 -0700 |
| Message-ID | <7c70cef0-5d51-49b4-88bb-de87e13e9851@l18g2000yql.googlegroups.com> |
| In reply to | #6246 |
On Jun 17, 4:12 pm, Keith Thompson <ks...@mib.org> wrote: > Willem <wil...@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. for instance C++'s STL does it taht way > push() without an argument would have to push an indeterminate or > default value onto the stack.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <cristom@charter.net> |
|---|---|
| Date | 2011-06-16 13:35 -0700 |
| Message-ID | <pOtKp.147$Md1.55@newsfe19.iad> |
| In reply to | #6178 |
"Rui Maciel" <rui.maciel@gmail.com> wrote in message news:4dfa55b3$0$23522$a729d347@news.telepac.pt... > 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? Because you can use the return value of the function itself as a predicate for a condition? Perhaps a better name would be `try_pop()'; humm...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-06-17 08:50 +1200 |
| Message-ID | <95v8ljFd2pU12@mid.individual.net> |
| In reply to | #6183 |
On 06/17/11 08:35 AM, Chris M. Thomasson wrote: > "Rui Maciel"<rui.maciel@gmail.com> wrote in message > news:4dfa55b3$0$23522$a729d347@news.telepac.pt... >> 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? > > Because you can use the return value of the function itself as a predicate > for a condition? Perhaps a better name would be `try_pop()'; humm... Or simply use top() to read and pop() to pop. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <cristom@charter.net> |
|---|---|
| Date | 2011-06-16 14:15 -0700 |
| Message-ID | <unuKp.7810$_I7.7793@newsfe08.iad> |
| In reply to | #6185 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:95v8ljFd2pU12@mid.individual.net... > On 06/17/11 08:35 AM, Chris M. Thomasson wrote: >> "Rui Maciel"<rui.maciel@gmail.com> wrote in message >> news:4dfa55b3$0$23522$a729d347@news.telepac.pt... >>> 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? >> >> Because you can use the return value of the function itself as a >> predicate >> for a condition? Perhaps a better name would be `try_pop()'; humm... > > Or simply use top() to read and pop() to pop. That does create a "gap" between `top()' and `pop()'; no problem for single-threaded access...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <cristom@charter.net> |
|---|---|
| Date | 2011-06-16 14:19 -0700 |
| Message-ID | <jruKp.19489$F25.44@newsfe04.iad> |
| In reply to | #6186 |
"Chris M. Thomasson" <cristom@charter.net> wrote in message news:unuKp.7810$_I7.7793@newsfe08.iad... > "Ian Collins" <ian-news@hotmail.com> wrote in message > news:95v8ljFd2pU12@mid.individual.net... >> On 06/17/11 08:35 AM, Chris M. Thomasson wrote: >>> "Rui Maciel"<rui.maciel@gmail.com> wrote in message >>> news:4dfa55b3$0$23522$a729d347@news.telepac.pt... >>>> 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? >>> >>> Because you can use the return value of the function itself as a >>> predicate >>> for a condition? Perhaps a better name would be `try_pop()'; humm... >> >> Or simply use top() to read and pop() to pop. > > That does create a "gap" between `top()' and `pop()'; no problem for > single-threaded access... WRT multi-threaded access it seems like the combined success to a call to `top()' and a call to `pop()' would be analogous to a committed transactional memory operation. Or simply lock the whole damn thing! ;^)
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-06-16 22:51 +0100 |
| Message-ID | <4dfa7ac7$0$23523$a729d347@news.telepac.pt> |
| In reply to | #6186 |
Chris M. Thomasson wrote: > That does create a "gap" between `top()' and `pop()'; no problem for > single-threaded access... And what leads you to believe that writing pop() so that it returns a value will make the code immune to concurrency issues, or at least more vulnerable than the version which doesn't return a value? Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <cristom@charter.net> |
|---|---|
| Date | 2011-06-16 15:27 -0700 |
| Message-ID | <orvKp.42434$Vp.14639@newsfe14.iad> |
| In reply to | #6190 |
"Rui Maciel" <rui.maciel@gmail.com> wrote in message news:4dfa7ac7$0$23523$a729d347@news.telepac.pt... > Chris M. Thomasson wrote: > >> That does create a "gap" between `top()' and `pop()'; no problem for >> single-threaded access... > > And what leads you to believe that writing pop() so that it returns a > value > will make the code immune to concurrency issues, or at least more > vulnerable > than the version which doesn't return a value? NO IMMUNITY! I simply prefer the conditional `try_pop()' function because it can be so easily used by the inherent pattern contained within the almighty "eventcount" algorithm: http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6cf4655c4e0b7c95 ;^)
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-06-16 22:43 +0100 |
| Message-ID | <4dfa7910$0$23529$a729d347@news.telepac.pt> |
| In reply to | #6183 |
Chris M. Thomasson wrote: > Because you can use the return value of the function itself as a predicate > for a condition? Perhaps a better name would be `try_pop()'; humm... You have top for that, which, from that code, you can get with: stack->arr[stack->top_index] In this case, if you write your pop() to return the value then at worse you perform a set of instructions which more often than not you don't even need and at best end up needlessly using more code to perform a task that you already get with a simple, single LoC. Rui Maciel
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web