spinoza1111 said:Hi, my name is Corazon Rosa Princess MacArthur Mirador de los Angeles,
and I am an IT and nursing student in Manila. My teacher uses the word
"stack". What does she mean?
Why did you respond to the obvious fakepost from Nilges?
Admittedly, yours was funny in a way that hers wasn't.
a stack is a common array of memory where is defined the functions push()
and pop() [and descrive what the functions do]
a stack is a common array of memory where is defined the functions push()
and pop() [and descrive what the functions do]
Pretty good, not bad, but could be better
First of all, you shouldn't the meaning so to fetter
To a "common" region of allocation
To do so is itself common, and and instance of inanition.
A stack can be a private thing and not for the public eye
Like when you're hungry and eat a whole pizza pie.
Nor 'tis it by necessity
An array...ain't pretty.
It can be a list what is linked
Just don't mess it up as does Heathfield whose tool, stinked.
And your worst error was that you left the interesting part
Subject to the student's random brain fart.
You do not define push and you don't define pull
That is how you look like, well, sort of a fool.
A stack is a data set,
A collection of items without predefined order,
Which can be accessed only at one end.
It's not a mouth and an anus
Nor is it a moon or Uranus,
But the top element can be removed by means of an operation called
onomatopoeiatistically , pop
And an element can be added by another operation called push, and push
and pop can be used in principle and sub specie aeternitatis, without
stop.
Managers do not love stacks
Great programmers like them
Managers fear that a sort of collection of hacks
Or, a Communist conspiracy, ahem,
Lurks in the very idea of separation of concerns
It gives managers heart burns.
A stack says, get back to later,
Alligator,
Once I've solved another problem.
"spinoza1111" <[email protected]> ha scritto nel messaggionews:7aaa1f88-4d0b-4c81-8da8-8e03fe8faf2e@n37g2000prc.googlegroups.com...
a stack is a common array of memory where is defined the functions push()
and pop() [and descrive what the functions do]Pretty good, not bad, but could be better
First of all, you shouldn't the meaning so to fetter
To a "common" region of allocation
To do so is itself common, and and instance of inanition.
A stack can be a private thing and not for the public eye
Like when you're hungry and eat a whole pizza pie.Nor 'tis it by necessity
An array...ain't pretty.
It can be a list what is linked
Just don't mess it up as does Heathfield whose tool, stinked.And your worst error was that you left the interesting part
Subject to the student's random brain fart.
You do not define push and you don't define pull
That is how you look like, well, sort of a fool.A stack is a data set,
A collection of items without predefined order,
Which can be accessed only at one end.
It's not a mouth and an anus
Nor is it a moon or Uranus,
But the top element can be removed by means of an operation called
onomatopoeiatistically , pop
And an element can be added by another operation called push, and push
and pop can be used in principle and sub specie aeternitatis, without
stop.Managers do not love stacks
Great programmers like them
Managers fear that a sort of collection of hacks
Or, a Communist conspiracy, ahem,
Lurks in the very idea of separation of concerns
It gives managers heart burns.
A stack says, get back to later,
Alligator,
Once I've solved another problem.
Revised Poem about Stacks
Pretty good, not bad, but could be better
First of all, you shouldn't the meaning so to fetter
To a "common" region of allocation
To do so is itself common, and and instance of inanition.
A stack can be a private thing and not for the public eye
Like when you're hungry and eat a whole pizza pie.
Nor 'tis it by necessity
An array...ain't pretty.
It can be a list what is linked
Just don't mess it up as does Heathfield whose tool, stinked.
And your worst error was that you left the interesting part
Subject to the student's random brain fart.
You do not define push and you don't define pull
That is how you look like, well, sort of a fool.
A stack is a data set,
A collection of items without predefined order,
Which can be accessed only at one end.
It's not a mouth and an anus
Nor is it a moon of Uranus,
But the top element can be removed by means of an operation called
onomatopoeiatistically , pop
And an element can be added by another operation called push, and
push
and pop can be used in principle and sub specie aeternitatis, without
stop.
Managers do not love stacks
Great programmers like them
Managers fear that a sort of collection of hacks
Or, a Communist conspiracy, ahem,
Lurks in the very idea of separation of concerns
It gives managers heart burns.
A stack says, get back to ya later,
Alligator,
Once I've solved another problem.
The stack is a scandal, and the stack is a shame
For those who think that programming is a child's game
Who get a job as a senior software engineer,
And sneer,
At Schildt because they think he's queer,
Without having the guts to take computer science
Lest Mommy's little darling have to suffer the defiance
Of some prof who doesn't think he's a genius
Who think in fact he's a weirdo and a wuss.
You see, the American university
Teaches the little darlings that anything expressed parenthetically
Can be disregarded by the high level hotshots they aspire to be.
Whereas the stack declares that God is in the details
Inside those cute little parentheses with their funny little tails
Even as Mies von der Rohe
Said, take care of everything thoroughly.
Well, princess, only your teacher knows what she means when she uses a word.
Here are two possible meanings:
o A stack, as in a stack of pancakes.
o A woman, often young, with appealing mammary glands. Unfortunately, due to
one warped old man (Hugh Hefner) and his impact on the culture, appealing is
oftentimes equated to "large".
a stack is a common array of memory where is defined the functions push()
and pop() [and descrive what the functions do]
Chad said:a stack is a common array of memory where is defined the functions push()
and pop() [and descrive what the functions do]
And what happens if someone changes the array to say a singly linked
list?
Chad said:a stack is a common array of memory where is defined the functions push()
and pop() [and descrive what the functions do]And what happens if someone changes the array to say a singly linked
list?
I didn't respond to the original question because it was an obvious
troll, but I think you're actually trying to learn something, so ...
The term "stack" has two distinct but related meanings. (Actually it
has more than that, but only two are relevant here.)
In computer science terms, a stack is a data structure with last-in
first-out behavior. In other words, the available operations are
"push', which adds a new element to the stack, and "pop", which
removes the most recently added element (and either gives you its
value or discards it). The first element added to an empty stack
is at the "bottom" of the stack; the most recently added element
is at the "top".
There are a number of ways to implement a stack. One is as a
contiguous chunk of memory, an array, with an index variable that
indicates where the current "top" of the stack is (the bottom is
fixed and doesn't need an index variable). If the array is of a
fixed size, then the stack can only hold at most a fixed number of
elements; pushing an additional element causes an overflow error,
which must be handled somehow; conversely, if you use only a small
portion of the array, the rest is wasted. Another way to implement
a stack is as a linked list, which avoids the overflow and waste
problems (until you run out of memory), but is a bit more complex
and probably slower.
The other common meaning of "stack", usually referred to as "the
stack", is in computer systems architecture. It's a contiguous
region of memory where the index variable indicating the current
"top" of the stack is typically a CPU register, the stack pointer
(often called the "SP" register). Many systems use such a stack to
implement function calls: all the information needed for a function
call, including local data, possibly parameters, and housekeeping
data such as the return address, is pushed onto "the stack" when a
function is called, and popped when the function returns. The stack
may grow either up or down in memory, depending on the system.
Most current systems use this kind of stack, but not all do, and the
C standard doesn't refer to it at all. There are systems that use a
linked list of activation records, rather than a contiguous stack,
to manage function calls. There have been systems that don't use
any kind of stack for function calls; such systems cannot directly
support recursion, and therefore cannot support a C implementation.
Even on systems that do use a contiguous hardware stack, the details
vary from one system to another. Unless you're dealing with very
low-level details, you don't need to know about how the hardware
stack works to understand how a C program works.
I'm going into all this gory detail because some people in this
newsgroup have (perhaps deliberately) confused the two concepts,
and others have refused to acknowledge that a C implementation can
possibly use anything other than contiguous hardware stack.
Don't let them confuse you..
Even on systems that do use a contiguous hardware stack, the details
vary from one system to another. Unless you're dealing with very
low-level details, you don't need to know about how the hardware
stack works to understand how a C program works.
While this is theoretically true, I think it is still useful for C
programmers to have some idea about how the stack is implemented on their
system/compiler; especially for stacks that are effectively continuous
arrays whether hardware implemented or not.
2. It can improve security. Many buffer overflow vulnerabilities are
based on trying to overwrite the pointer used to return to
the previous function. Understanding this attack can help a
programmer take extra security precautions in their code.
It can be. However, it's important to get it right -- if you know how the
stack was implemented on something else, it can be extremely bad, because
it can lead to you *mistakenly* thinking it has provided any of these
benefits... And it's surprising just how often these things can change.
There are cases where a compiler option can result in different behavior
for the same compiler, same operating system, and same hardware...
I don't buy this one. You don't have to know anything about a stack to
understand the basics of why buffer overruns are a big deal.
A buffer overflow itself causes currupt memory which is likely to crash the
program and/or cause any number of issues; but, while this is effectively a
denial of service attack, simple explotation of a buffer overflows does not
provide a hacker with access to the system. Buffer overflows on the stack
are the traditional method for gaining access to the system and there are
many of them available, they are often easier to implement, and they are
fairly reliable. If you know what exploits are possible on your platform,
there may be ways to help aleviate them.
Buffer overflows on the heap are generally more difficult to implement,
they are less exact do to the more or less random nature of heap layout at
any given point, and they less known. Heap expoits in the wild didn't
become a major issue until mechanisms designed at stopping stack overflow
exploits started to become more common. It is also somewhat easier to
impliment checks for heap based exploits directly within your code while
many stack protection mechanisms require compiler, operating system, or
even hardware support. Therefore, it makes some sense, if you have a
section of code that is in a likely position for encountering exploit
attempts and (such as network communication buffers) and your
compiler/system uses a hardware based stack, that you might prefer to
allocate memory for them on the heap even if their size is small and
predetermined.
I thought that being correct went without saying. Using mistaken
information always puts you at risk of doing the wrong thing. (I could make
a political statement here; but, I will refrain.)
Most people need a concrete picture in their mind to understandUnless you're dealing with very
low-level details, you don't need to know about how the hardware
stack works to understand how a C program works.
Malcolm McLean said:Most people need a concrete picture in their mind to understand
something. Whilst theoretically using abstract definitions like
"automatic storage duration" gives someone the information required to
understand how a C program works, in fact it takes most people an
unacceptably long time to understand something described in those
terms. A description of a stack pushing variables on and popping them
off, however, will give most people a good enopugh mental picture.
Much later you can introduce the idea that some very small or very
high-level implemetations might not have harware stacks, but only
after they are already fluent C programmers.
Most people need a concrete picture in their mind to understand
something.
A description of a stack pushing variables on and popping them
off, however, will give most people a good enopugh mental picture.
Much later you can introduce the idea that some very small or very
high-level implemetations might not have harware stacks, but only
after they are already fluent C programmers.
With a linked list it is sometimes easier to implement a stack of"spinoza1111" <[email protected]> ha scritto nel messaggio
in my naive think, stack should be one array.
Where are the reasons for use a linked list?
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.