Re: alloca / _alloca / dynamic stack memory
Michael Crawley <MichaelCrawley@discussions.microsoft.com> wrote:
The factory model will not work as you suggested. The developer has
to know the difference between allocating on the stack from
allocating on the heap. Dynamic stack allocation is scoped to a
specific stack frame. I am opperating under the assumption our
developers have taken CIS101 Introduction to Programming after
graduating from a graduate-level masters program or better ;-)
Well, the developers have all taken that CIS101 class, where they were
taught that an object allocated with new lives until explicitly
destroyed with delete. You then go behind their backs and change this
assumption without any clue in the syntax. Now they can't rely on the
most basic features of the language, without inspecting the source code
of every single class they use. Do you really believe it's a good idea?
If the developer needs to be intimately familiar with the internal
details of the class, so as to know that 'new' behaves in this special
way with this class, why would he or she use 'new' in the first place,
rather than simply declaring a local variable?
Lets say a class is to be allocated dynamically all of the
time...perhaps it has a private/protected destructor, it would be
nice to pick and choose which memory allocator to use at runtime to
best suite your needs.
But you can't: an operator new has to be baked into the class at compile
time, hasn't it? So why would the author go to some lengths to disable
creating the object on the stack (by making destructor
private/protected), only to then turn around and go to even greater
lengths to enable it back (by making operator new use alloca, assuming
for the sake of argument that it's possible)? It doesn't make any sense
to me, sorry.
If you need to use this class for a good
while or need to be able to pass the object between threads, then the
standard operator new or a new operator that takes a memory pool of
some sort as an argument would do. If we only need to use it within
the current function and we are sure there is enough room on the
stack, then lets not compete for a lock in malloc or a shared
heap...lets allocate it on the stack if each thread does not have
their own heap.
So if allocating this object on the stack is a good idea, why make its
destructor private/protected?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925