Greg Comeau wrote:
>
> Anyway, as I recall the reason the C committee
> didn't put alloca() in standard C was portability, in that it was not
> considered that it could always be implemented efficiently.  This ties
> into why some compilers don't guarantee certain aspects about it,
> and differently so.

If all that's required by alloca is that it allocate memory that
automatically gets freed when a function returns, then it would be
easier to guarantee this in C++. Any implementation that couldn't
cleanly allocate the space on the stack could allocate it on the heap
and put a hidden auto_ptr to it (or vector<auto_ptr>, to handle loops)
on the stack.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35F182D8.EDF54709@ix.netcom.com> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
>Steven Correll wrote:
>> Editorial digression: I don't understand why, having freed C from the
>> notion that syntactic functions must be implemented as actual function
>> calls, the C committee didn't put alloca() into the standard...
>
>Since casts from void* are un-C++-like, even malloc() is in some sense
>deprecated, so alloca() shouldn't be encouraged. But I've heard that
>variable-sized local arrays are a feature of the latest C spec, and may
>be incorporated into C++ in the distant future. I think this would cover
>most of the uses people find for alloca().

Probably most of them, except that many alloca's allow multiple
calls per function.  Anyway, as I recall the reason the C committee
didn't put alloca() in standard C was portability, in that it was not
considered that it could always be implemented efficiently.  This ties
into why some compilers don't guarantee certain aspects about it,
and differently so.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
                       Producers of Comeau C/C++ 4.2.38 -- New Release!
 Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                  ***WEB: http://www.comeaucomputing.com***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco<pderocco@ix.netcom.com> wrote:
>... But I've heard that
>variable-sized local arrays are a feature of the latest C spec, and may
>be incorporated into C++ in the distant future. I think this would cover
>most of the uses people find for alloca().

The most interesting use for alloca() is to allocate list or graph
nodes in a loop.  I haven't seen any alternative proposed which
allows that.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco wrote:
>
> I advise you to put alloca into the same category as setjmp and longjmp,
> or realloc.

I wouldn't put realloc in this category. It doesn't mess with stack
frames at all.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Of course, if the compiler vendor chooses to implement alloca(), it
> will futz with the stack in ways that the vendor (should) guarantee
> to work with "normal" C++ code.

Borland, for instance, warns that the program may crash if the function
makes no references to local variables (since it won't have a valid
stack frame). In other words, they didn't bother making their compiler
smart enough so that use of alloca() would prevent optimizing away the
stack frame.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steven Correll wrote:
>
> Four different Unix C++ compilers available to me for testing ... all
> recognize "alloca" as much more than an ordinary function...
>
> Microsoft Visual C++ 4.2 maps "alloca" to "_alloca" in "malloc.h" and
> then emits special code, unless you disable extensions to the
> standard.

At least when compiling Windows code, Borland keeps this as a plain
function call, and warns about its use. It's not something you can
blindly count on working.

> Editorial digression: I don't understand why, having freed C from the
> notion that syntactic functions must be implemented as actual function
> calls, the C committee didn't put alloca() into the standard...

Since casts from void* are un-C++-like, even malloc() is in some sense
deprecated, so alloca() shouldn't be encouraged. But I've heard that
variable-sized local arrays are a feature of the latest C spec, and may
be incorporated into C++ in the distant future. I think this would cover
most of the uses people find for alloca().

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35E75C7E.48661A2A@ix.netcom.com>,
Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
>I advise you to put alloca into the same category as setjmp and longjmp,
>or realloc. In other words, it's one of those things that you simply
>shouldn't do in C++ as a matter of course, because it futzes with the
>stack layout in ways that typical C++ implementations are more sensitive
>to than C usually is...
>My guess is that the typical implementation will allocate space within
>the context of the caller, because the compiler just sees it as an
>ordinary function call...

Four different Unix C++ compilers available to me for testing (HP aCC A.03.10,
Solaris CC 4.2, DEC V5.7-002, and IBM xlC 3.1) all recognize "alloca" as much
more than an ordinary function, provided that "#include <alloca.h>" (or, in
IBM's case, "#pragma alloca") precedes its use. Both Solaris and HP
use the header file to map "alloca" to the symbol "__builtin_alloca" which
due to the leading "__" is reserved by the C standard for use by implementors,
and then their compilers recognize that symbol as license to emit inline code
instead of a function call. DEC uses the header file to generate a "#pragma"
which has a similar effect. All of them generate code which appears to me
to coexist with standard C++ constructs.

Microsoft Visual C++ 4.2 maps "alloca" to "_alloca" in "malloc.h" and then
emits special code, unless you disable extensions to the standard.

The real reason to avoid "alloca" is that a program which relies on it
is not standard-conforming. All of these compilers are standard-conforming,
however, because they only give "alloca" a special meaning if you use a
special compiler-provided "#include" or "#pragma" (or, in the Microsoft case,
only when you enable extensions).

Editorial digression: I don't understand why, having freed C from the
notion that syntactic functions must be implemented as actual function calls,
the C committee didn't put alloca() into the standard; while some systems
might not be able to implement it via an actual function call, any system
can implement it via inline code (in the worst case, by emitting calls to
"malloc" and "free" behind the programmer's back). The ability to perform
dynamic allocation on function entry with automatic deallocation on function
exit dates at least as far back as Algol 60 and 1960s Fortran. In C++, of
course, it would constitute another archaism like "malloc" and "free".
--
Steven Correll == 1931 Palm Ave, San Mateo, CA 94403 == sjc@netcom.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Vlad Harchev wrote:
>> Will it allocate the store in the context of caller or in it's own
>> context?

Paul D. DeRocco wrote:
> I advise you to put alloca into the same category as setjmp and
> longjmp, or realloc.

There's another reason to stay away from it, at least in C.  The new
C9X standard adds "variable length arrays" (VLAs) to the language,
which gives you essentially the same capability, but in a blessed
form.

The C9X std is only about a year away, and presumably some vendors
have started adding some of its features.  And I would expect VLAs
to be considered for inclusion in the next revision of C++ (C++2005?).

> In other words, it's one of those things that you simply shouldn't do
> in C++ as a matter of course, because it futzes with the stack layout
> in ways that typical C++ implementations are more sensitive to than C
> usually is. You may find specific exceptions to this "rule", but only
> by learning the particular compiler in question, studying the
> generated code, and figuring out when it works and when it doesn't.

Of course, if the compiler vendor chooses to implement alloca(), it
will futz with the stack in ways that the vendor (should) guarantee
to work with "normal" C++ code.

> My guess is that the typical implementation will allocate space within
> the context of the caller, because the compiler just sees it as an
> ordinary function call. The compiler isn't aware that alloca will
> twiddle the stack pointer before returning.

Most implementations make alloca() a macro defined to some built-in
special identifier (like '__builtin_alloca') that the compiler knows
about, and therefore allows the compiler to generate inline code for.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 Will it allocate the store in the context of caller or in it's own context?




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Vlad Harchev" <vladhar@imimail.ssau.ru> writes:


> Will it allocate the store in the context of caller or in it's own context?

"alloca" is not part of standard C++ (nor part of standard C), so
there is no answer to that question in this newsgroup. You would
have to check the compiler documentation to find out how it
is defined to work.

The C Committee informally discussed adding alloca to the new
C standard, but did not adopt it -- at least it isn't in the
Committee Draft that was issued this month.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]