C# Stack item reversal

[RobertEstelle]

Hello everyone,
I encountered an interesting bug in a program I was writing that was
caused by the following unexpected behaviour. Basically, creating a
new Stack object from another results in a reversal of the item
ordering.
Example:

Stack<stringa = new Stack<string>() ;
a.Push("a"); a.Push("b"); a.Push("c"); a.Push("d");
// a has "d","c","b" ,"a"

Stack<stringb = new Stack<string>(a );
// b has "a","b","c" ,"d"

Does anyone know why this happens? Is it a bug in the class library,
or some mistaken assumption on my part?
For background, I was using a stack for a recursive function wherein
each function call required its own copy of the initial stack to pop
items off. Needless to say, having the stack reverse itself at each
depth caused some interesting behaviour.

Looking forward to your comments;
- Robert Estelle

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Ro***********@g mail.com wrote:

Hello everyone,
I encountered an interesting bug in a program I was writing that was
caused by the following unexpected behaviour. Basically, creating a
new Stack object from another results in a reversal of the item
ordering.
Example:

Stack<stringa = new Stack<string>() ;
a.Push("a"); a.Push("b"); a.Push("c"); a.Push("d");
// a has "d","c","b" ,"a"

Stack<stringb = new Stack<string>(a );
// b has "a","b","c" ,"d"

Does anyone know why this happens? Is it a bug in the class library,
or some mistaken assumption on my part?
For background, I was using a stack for a recursive function wherein
each function call required its own copy of the initial stack to pop
items off. Needless to say, having the stack reverse itself at each
depth caused some interesting behaviour.

Looking forward to your comments;
- Robert Estelle

It's a mistaken assumption on your part. There is no constructor for the
Stack class that takes a Stack as parameter and copies it.

You are using the constructor that takes an IEnumerable. That means that
it's using a Stack.Enumerato r to get the elements in the original stack.
The enumerator reads the elements in the same order as if they were
poped from the stack, and the constructor pushes them in that order. The
result is of course that the new stack is a reversed copy of the original.

--
Göran Andersson
_____
http://www.guffa.com

[RobertEstelle]

Thanks -- you are correct of course, but it seems odd that the library
would choose not to overload its own constructor to allow for
"correct" functionality. Does anyone know what went into this design
decision?

[Luc E. Mistiaen]

Maybe Stack<stringb = a.Clone(); suits you?

/LM
<Ro***********@ gmail.comwrote in message
news:11******** **************@ v33g2000cwv.goo glegroups.com.. .

Hello everyone,
I encountered an interesting bug in a program I was writing that was
caused by the following unexpected behaviour. Basically, creating a
new Stack object from another results in a reversal of the item
ordering.
Example:

Stack<stringa = new Stack<string>() ;
a.Push("a"); a.Push("b"); a.Push("c"); a.Push("d");
// a has "d","c","b" ,"a"

Stack<stringb = new Stack<string>(a );
// b has "a","b","c" ,"d"

Does anyone know why this happens? Is it a bug in the class library,
or some mistaken assumption on my part?
For background, I was using a stack for a recursive function wherein
each function call required its own copy of the initial stack to pop
items off. Needless to say, having the stack reverse itself at each
depth caused some interesting behaviour.

Looking forward to your comments;
- Robert Estelle

[Tom Spink]

Ro***********@g mail.com wrote:

Thanks -- you are correct of course, but it seems odd that the library
would choose not to overload its own constructor to allow for
"correct" functionality. Does anyone know what went into this design
decision?

Because, if they did alter that particular overload to work in reverse, it
wouldn't work as expected if you did give it something you wanted to
iterate over in the correct direction. It makes more sense to have it
working as you expect it to, for the type you are giving it, in this case a
class that implements IEnumerable.

Perhaps the clone method (as noted by LM, in the adjacent reply) is more
suited to your needs.

--
Hope this helps,
Tom Spink

Google first, ask later.

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Ro***********@g mail.com wrote:

Thanks -- you are correct of course, but it seems odd that the library
would choose not to overload its own constructor to allow for
"correct" functionality. Does anyone know what went into this design
decision?

I guess that copying a stack is not something that you would usually do,
and if you do, you should probably duplicate all the items in the stack,
not just copy the reference. In your special case where you are using
strings, you can safely copy the references as strings are immutable,
but remember that the Stack<Tclass is designed for any kind of objects.

--
Göran Andersson
_____
http://www.guffa.com