Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #68773 > unrolled thread

alloca()-support

Back to article view | Back to comp.lang.c++

Contents

  alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 14:02 +0200
    Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-09-30 07:02 -0700
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:09 +0200
        Re: alloca()-support Bo Persson <bo@bo-persson.se> - 2019-09-30 17:29 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:33 +0200
      Re: alloca()-support gazelle@shell.xmission.com (Kenny McCormack) - 2019-09-30 16:26 +0000
    Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:12 +0300
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:16 +0200
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:30 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:44 +0200
            Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 00:36 +0300
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:08 +0300
                  Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:42 +0200
      Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 14:30 +0000
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:33 +0300
          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-09-30 16:56 +0200
      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-30 15:29 +0000
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:31 +0200
          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 07:03 +0000
            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 10:57 +0200
              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:49 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:20 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:39 +0000
                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:15 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:29 +0000
      Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:14 -0700
    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:04 +0200
      Re: alloca()-support William Ahern <william@25thandClement.com> - 2019-09-30 11:01 -0700
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:19 +0200
      Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-30 22:26 +0300
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:46 +0000
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:32 +0200
        Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-01 09:08 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 08:35 +0200
    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:48 +0200
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:51 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:55 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:58 +0200
            Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:53 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:13 -0700
              Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:38 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:41 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 15:19 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 17:31 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:58 +0000
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:24 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:28 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:30 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:36 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:01 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:42 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:10 +0200
                                  Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:13 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 21:10 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:25 +0200
                          Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:44 +0000
                          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 23:26 +0200
                            Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-01 21:08 -0600
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:19 +0200
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:39 +0200
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:34 +0200
                          Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:14 +0200
                      Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:18 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:21 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 04:09 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:48 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 05:49 +0000
                                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:52 +0200
                                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 06:46 +0000
                                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 10:59 +0200
                Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 13:39 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 13:23 +0000
                  Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-03 15:38 +0200
                    Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 14:51 +0000
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:49 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:47 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:53 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:52 +0200
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:39 +0200
          Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-30 21:36 -0400
        Re: alloca()-support Philipp Klaus Krause <pkk@spth.de> - 2019-09-30 19:14 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:16 +0200
            Re: alloca()-support Robert Wessel <robertwessel2@yahoo.com> - 2019-10-01 00:18 -0500
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:43 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-10-01 02:42 -0700
                Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-01 08:11 -0400
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 14:53 +0200
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 17:52 +0000
      Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 11:20 -0600
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:42 +0200
          Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:02 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:54 +0200
          Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 14:28 -0600
            Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 09:38 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:01 +0200
          Re: alloca()-support Manfred <noname@add.invalid> - 2019-10-01 17:45 +0200
    Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 00:03 -0700
      Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-02 11:30 +0300
      Re: alloca()-support Ian Collins <ian-news@hotmail.com> - 2019-10-02 21:34 +1300
        Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 01:36 -0700
          Re: alloca()-support Ian Collins <ian-news@hotmail.com> - 2019-10-02 21:41 +1300
            Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 02:28 -0700
    Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 02:35 -0700
      Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 02:43 -0700
      Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:26 +0300
        Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 12:33 -0700
          Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-03 01:47 +0300
            Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-05 14:08 -0700

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#68829

> uhm, I didn't mean THAT kind of risk (unavoidable), but the possible 
> difficulties in defining variables beyond the point of declaration of 
> the variable-size array.

The compiler usually collects the size of all the "static" variables in
the stack and reserves the space for them at the function-prolog. The
VLA-spaces are handled within the function at the point where they are
reserved (coudln't be handled differently because their size is only
known at the point where they are reserved).

[toc] | [prev] | [next] | [standalone]

#68823

On 9/30/19 12:55 PM, Soviet_Mario wrote:
> On 30/09/2019 18:51, Bonita Montero wrote:
>>> Since when (if at any time) was variable size automatic 
>>> array supported ?
>>
>> Since C99.
>>
> 
> for curiosity, this feature has one or more of the 
> limitations I feared ... or even none of them ?

There are several limitations on VLAs:
They were not part of standard C until C99, and became optional in
C2011. A C2011 implementation that does not support them will pre#define
__STDC_NO_VLA__ with a value of 1. They have never yet been part of
standard C++.

The type name in a compound literal is not allowed ot be a VLA (6.5.2.5p1).

A VLA can be declared with a size that is unspecified - this is
specified by using "*" for the size, and can only be done in the
declaration of a function parameter that is NOT part of the definition
of that function (6.7.2p4).

The expression for the size of a VLA must be an integer expression with
a value greater than 0 (6.7.2p5).

"Where a size expression is part of the operand of a sizeof operator and
changing the value of the size expression would not affect the result of
the operator, it is unspecified whether or not the size expression is
evaluated." (6.7.2p5)

Thus, portable code cannot rely upon the value of being changed (or
unchanged) by evaluation of sizeof(int[n++]) - as a general rule, that
would make it a bad idea to write such an expression.

"If, in the nested sequence of declarators in a full declarator, there
is a declarator specifying a variable length array type, the type
specified by the full declarator is said to be variably modified.
Furthermore, any type derived by declarator type derivation from a
variably modified type is itself variably modified." (6.7.6p3)

For instance, int (*vla)[n] declares a pointer to a VLA, but is not
itself a VLA. But it is a variably modified type .

A typedef for a VM type cannot be redefined, not even to the same type
(6.7p3).

"A member of a structure or union may have any complete object type
other than a variably modified type." (6.7.2.1p9)

"If an identifier is declared as having a variably modified type, it
shall be an ordinary identifier (as defined in 6.2.3), have no linkage,
and have either block scope or function prototype scope. If an
identifier is declared to be an object with static or thread storage
duration, it shall not have a variable length array type." (6.7.6.2p2)

"If a typedef name specifies a variably modified type then it shall have
block scope." (6.7.8p2)

"If a switch statement has an associated case or default label within
the scope of an identifier with a variably modified type, the entire
switch statement shall be within the scope of that identifier." (6.8.4.2p2)

"A goto statement shall not jump from outside the scope of an identifier
having a variably modified type to inside the scope of that identifier."
(6.8.6.1)

"... if the invocation of the setjmp macro was within the scope of an
identifier with variably modified type and execution has left that scope
in the interim, the behavior [of longjmp()] is undefined."  (7.13.2.1p2)

[toc] | [prev] | [next] | [standalone]

#68802

Am 30.09.19 um 18:51 schrieb Bonita Montero:
>> Since when (if at any time) was variable size automatic array supported ?
> 
> Since C99.
> 
And C99 is the only version where support for them is mandatory.

As of C11, they are optional.

[toc] | [prev] | [next] | [standalone]

#68803

>> Since C99.

> And C99 is the only version where support for them is mandatory.

> As of C11, they are optional.

And with C++ you can ask the compiler via __STDC_NO_VLA__ if VLAs
are not supported.

[toc] | [prev] | [next] | [standalone]

#68826

On Mon, 30 Sep 2019 19:16:19 +0200, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>>> Since C99.
>
>> And C99 is the only version where support for them is mandatory.
>
>> As of C11, they are optional.
>
>And with C++ you can ask the compiler via __STDC_NO_VLA__ if VLAs
>are not supported.


Are C++ compilers actually obligated to define _STDC_NO_VLA_?

[toc] | [prev] | [next] | [standalone]

#68831

>> And with C++ you can ask the compiler via __STDC_NO_VLA__ if VLAs
>> are not supported.

> Are C++ compilers actually obligated to define _STDC_NO_VLA_?

It's at least not part of the C++17-standard.

[toc] | [prev] | [next] | [standalone]

#68842

Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> Are C++ compilers actually obligated to define _STDC_NO_VLA_?

No, __STDC_NO_VLA__ (note the double underscores) is specific to C11 and
later.  C++ doesn't support VLAs at all, so there's no need for a C++
compiler to indicate its lack of support, and the C++ standard doesn't
require it to do so.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#68846

On 10/1/19 5:42 AM, Keith Thompson wrote:
> Robert Wessel <robertwessel2@yahoo.com> writes:
> [...]
>> Are C++ compilers actually obligated to define _STDC_NO_VLA_?
> 
> No, __STDC_NO_VLA__ (note the double underscores) is specific to C11 and
> later.  C++ doesn't support VLAs at all, so there's no need for a C++
> compiler to indicate its lack of support, and the C++ standard doesn't
> require it to do so.

I'm sure you know this, but for the sake of other readers, I'd like to
point out that the fact that __STDC_NO_VLA__ is a C-specific macro does
not, in itself, prevent the C++ standard from saying anything about it.
The C++ standard simply failed to do so. It has said things about other
C pre#defined macros.

The C++ standard mandates the setting of __STDC_HOSTED__ to either 0 or
1, as appropriate, and allows the setting of __STDC_MB_MIGHT_NEQ_WC__,
__STDC__,  __STDC_VERSION__, and __STDC_ISO_10646__. If
__STDC_MB_MIGHT_NEQ_WC__ is pre#defined, it's required expand to the
integer literal 1, and if __STDC_ISO_10646__ is pre#defined, it's
required to expand to "An integer literal of the form yyyymmL".

[toc] | [prev] | [next] | [standalone]

#68849

> No, __STDC_NO_VLA__ (note the double underscores) is specific to C11 and
> later.  C++ doesn't support VLAs at all, so there's no need for a C++
> compiler to indicate its lack of support, and the C++ standard doesn't
> require it to do so.

It might help to port C99-code to C++ when C++ would define this macro
appropriately. Code could conditionally disable VLA-dependent parts.

[toc] | [prev] | [next] | [standalone]

#68806

Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Since when (if at any time) was variable size automatic array supported ?
>
>Since C99.
>

Albeit available pre-C99 standardization in several compilers.

[toc] | [prev] | [next] | [standalone]

#68804

Soviet_Mario <SovietMario@CCCP.MIR> writes:

> On 30/09/2019 14:02, Bonita Montero wrote:
>> I know alloca() neither is an official part of the C nor C++
>> program-
>> ming-language. But I use it for performance-reasons. Can anyone name
>> compilers that don't support alloca()?
>
>
> sorry, mine is not an answer but a related question
>
> Since when (if at any time) was variable size automatic array
> supported ?
>
> I mean a temporary array local to a function whose size becomes known
> only at runtime (seems to me a generalization of variadic functions,
> which, too, does not know at compile time how much stack space will
> consume).
>
> If implemented, It seems equivalent to alloca () ... is it there some
> limitation then in ORDER of automatic variable creations ?

There is no such limitation on your C program.  The VLA can be first,
last, or in the middle.  And you can have more than one of them.

Where in the activation record a compiler chooses to put it is, AFAIK,
not specified.

[toc] | [prev] | [next] | [standalone]

#68805

>> If implemented, It seems equivalent to alloca () ... is it there some
>> limitation then in ORDER of automatic variable creations ?

> There is no such limitation on your C program.  The VLA can be first,
> last, or in the middle.  And you can have more than one of them.

alloca() can be called at almost any point in a function (with some
compilers not within a function-call).

[toc] | [prev] | [next] | [standalone]

#68810

On 30/09/2019 19:42, Bonita Montero wrote:
>>> If implemented, It seems equivalent to alloca () ... is 
>>> it there some
>>> limitation then in ORDER of automatic variable creations ?
> 
>> There is no such limitation on your C program.  The VLA 
>> can be first,
>> last, or in the middle.  And you can have more than one of 
>> them.
> 
> alloca() can be called at almost any point in a function 
> (with some
> compilers not within a function-call).

I've not clear what differences there are in alloca () usage 
vs plain declaration, then ....

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#68808

On 30/09/2019 19:20, Joe Pfeiffer wrote:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
> 
>> On 30/09/2019 14:02, Bonita Montero wrote:
>>> I know alloca() neither is an official part of the C nor C++
>>> program-
>>> ming-language. But I use it for performance-reasons. Can anyone name
>>> compilers that don't support alloca()?
>>
>>
>> sorry, mine is not an answer but a related question
>>
>> Since when (if at any time) was variable size automatic array
>> supported ?
>>
>> I mean a temporary array local to a function whose size becomes known
>> only at runtime (seems to me a generalization of variadic functions,
>> which, too, does not know at compile time how much stack space will
>> consume).
>>
>> If implemented, It seems equivalent to alloca () ... is it there some
>> limitation then in ORDER of automatic variable creations ?
> 
> There is no such limitation on your C program.  The VLA can be first,
> last, or in the middle.  And you can have more than one of them.
> 
> Where in the activation record a compiler chooses to put it is, AFAIK,
> not specified.

ah ! So you are suggestion sort of internal reordering on 
the stack (like : all known types before, then the var-sized) ?

> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#68820

Soviet_Mario <SovietMario@CCCP.MIR> writes:

> On 30/09/2019 19:20, Joe Pfeiffer wrote:
>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>
>>> On 30/09/2019 14:02, Bonita Montero wrote:
>>>> I know alloca() neither is an official part of the C nor C++
>>>> program-
>>>> ming-language. But I use it for performance-reasons. Can anyone name
>>>> compilers that don't support alloca()?
>>>
>>>
>>> sorry, mine is not an answer but a related question
>>>
>>> Since when (if at any time) was variable size automatic array
>>> supported ?
>>>
>>> I mean a temporary array local to a function whose size becomes known
>>> only at runtime (seems to me a generalization of variadic functions,
>>> which, too, does not know at compile time how much stack space will
>>> consume).
>>>
>>> If implemented, It seems equivalent to alloca () ... is it there some
>>> limitation then in ORDER of automatic variable creations ?
>>
>> There is no such limitation on your C program.  The VLA can be first,
>> last, or in the middle.  And you can have more than one of them.
>>
>> Where in the activation record a compiler chooses to put it is, AFAIK,
>> not specified.
>
> ah ! So you are suggestion sort of internal reordering on the stack
> (like : all known types before, then the var-sized) ?

I'm saying there is nothing (I know of) prohibiting a compiler from
doing that; without thinking too deeply about it, I suspect that if I
were writing the compiler that would be my first approach (since, as you
suggest, that would permit the other variables to be accessed through
constant offsets).

[toc] | [prev] | [next] | [standalone]

#68836

On 30/09/2019 22:28, Joe Pfeiffer wrote:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
> 
>> On 30/09/2019 19:20, Joe Pfeiffer wrote:
>>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>>
>>>> On 30/09/2019 14:02, Bonita Montero wrote:
>>>>> I know alloca() neither is an official part of the C nor C++
>>>>> program-
>>>>> ming-language. But I use it for performance-reasons. Can anyone name
>>>>> compilers that don't support alloca()?
>>>>
>>>>
>>>> sorry, mine is not an answer but a related question
>>>>
>>>> Since when (if at any time) was variable size automatic array
>>>> supported ?
>>>>
>>>> I mean a temporary array local to a function whose size becomes known
>>>> only at runtime (seems to me a generalization of variadic functions,
>>>> which, too, does not know at compile time how much stack space will
>>>> consume).
>>>>
>>>> If implemented, It seems equivalent to alloca () ... is it there some
>>>> limitation then in ORDER of automatic variable creations ?
>>>
>>> There is no such limitation on your C program.  The VLA can be first,
>>> last, or in the middle.  And you can have more than one of them.
>>>
>>> Where in the activation record a compiler chooses to put it is, AFAIK,
>>> not specified.
>>
>> ah ! So you are suggestion sort of internal reordering on the stack
>> (like : all known types before, then the var-sized) ?
> 
> I'm saying there is nothing (I know of) prohibiting a compiler from
> doing that; without thinking too deeply about it, I suspect that if I
> were writing the compiler that would be my first approach (since, as you
> suggest, that would permit the other variables to be accessed through
> constant offsets).
> 

Exactly.  It is a likely that the allocation would be handled something
like that.  But the compiler can arrange the details in any way it deems
best.

Alternatives include allocating some fixed frame variables first, then
copying the stack pointer to a frame pointer (call it "fp").  Then the
alloca() or VLA adds to the stack, then there is some more stack data
(maybe another VLA or alloca() ).  The first data can be accessed as "fp
+ offset", later data as "sp + offset".  Intermediary anchor points can
be saved as necessary.

Mixing multiple VLA's and alloca's in the same function is likely to
give you inefficient code and wasted stack space (alloca data lives
until the end of the function, VLA's live until the end of the block).
But the compiler's prime job is to give you correct object code, and it
should handle that okay.

[toc] | [prev] | [next] | [standalone]

#68809

On 30/09/2019 19:20, Joe Pfeiffer wrote:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
> 
>> On 30/09/2019 14:02, Bonita Montero wrote:
>>> I know alloca() neither is an official part of the C nor C++
>>> program-
>>> ming-language. But I use it for performance-reasons. Can anyone name
>>> compilers that don't support alloca()?
>>
>>
>> sorry, mine is not an answer but a related question
>>
>> Since when (if at any time) was variable size automatic array
>> supported ?
>>
>> I mean a temporary array local to a function whose size becomes known
>> only at runtime (seems to me a generalization of variadic functions,
>> which, too, does not know at compile time how much stack space will
>> consume).
>>
>> If implemented, It seems equivalent to alloca () ... is it there some
>> limitation then in ORDER of automatic variable creations ?
> 
> There is no such limitation on your C program.  The VLA can be first,
> last, or in the middle.  And you can have more than one of them.
> 
> Where in the activation record a compiler chooses to put it is, AFAIK,
> not specified.
> 


I have QT that does not supports them, but, if sb would be 
so kind to copy a minimal asm generated code for some

int Funz (int A, int B)
{
int C = 3;
int Buf [A];
int D = 2;
Buf [A-1] = B;
return (A + B * D - C);
}

int main (void)
{
return Funz (4, 3);
}

I'd like to examine the assembler generated in order to 
figure out how Buf (and D, beyond it apparently) are addressed

ah, if not to annoying, TURNING OFF most if not all 
optimizationz (maybe the example is too minimal to be sort 
of resolved at compile time :\)

tnx in advance

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#68857

On 9/30/2019 8:01 PM, Soviet_Mario wrote:
> On 30/09/2019 19:20, Joe Pfeiffer wrote:
>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>
>>> On 30/09/2019 14:02, Bonita Montero wrote:
>>>> I know alloca() neither is an official part of the C nor C++
>>>> program-
>>>> ming-language. But I use it for performance-reasons. Can anyone name
>>>> compilers that don't support alloca()?
>>>
>>>
>>> sorry, mine is not an answer but a related question
>>>
>>> Since when (if at any time) was variable size automatic array
>>> supported ?
>>>
>>> I mean a temporary array local to a function whose size becomes known
>>> only at runtime (seems to me a generalization of variadic functions,
>>> which, too, does not know at compile time how much stack space will
>>> consume).
>>>
>>> If implemented, It seems equivalent to alloca () ... is it there some
>>> limitation then in ORDER of automatic variable creations ?
>>
>> There is no such limitation on your C program.  The VLA can be first,
>> last, or in the middle.  And you can have more than one of them.
>>
>> Where in the activation record a compiler chooses to put it is, AFAIK,
>> not specified.
>>
> 
> 
> I have QT that does not supports them, but, if sb would be so kind to 
> copy a minimal asm generated code for some
> 
> int Funz (int A, int B)
> {
> int C = 3;
> int Buf [A];
> int D = 2;
> Buf [A-1] = B;
> return (A + B * D - C);
> }
> 
> int main (void)
> {
> return Funz (4, 3);
> }
> 
> I'd like to examine the assembler generated in order to figure out how 
> Buf (and D, beyond it apparently) are addressed
> 
> ah, if not to annoying, TURNING OFF most if not all optimizationz (maybe 
> the example is too minimal to be sort of resolved at compile time :\)
> 
> tnx in advance
> 

AFAIU this is a feature of the language and compiler, not of QT, so 
probably your limitation is not because you use QT per se, but instead 
because C++ does not have VLAs.

Trying to force VLAs via asm in C++ would probably open a can of worms 
not worth the benefit.
A more viable alternative could be having the code that needs VLAs 
implemented in C modules linked to C++, or switch to std::vector.
If it is directly coupled to QT itself, e.g. GUI handlers, then the 
performance gap of using std::vector is most probably neglectable.
(and, of course, there still is _alloca() if it is supported by the 
compiler)

[toc] | [prev] | [next] | [standalone]

#68886

On Monday, September 30, 2019 at 1:02:16 PM UTC+1, Bonita Montero wrote:
> I know alloca() neither is an official part of the C nor C++ program-
> ming-language. But I use it for performance-reasons. Can anyone name
> compilers that don't support alloca()?


I wonder if this would be a good reason to add a new compile-time operator to the C++ language? We could re-use the keyword 'extern' as follows:

#include <some_header.hpp>

int main()
{
    if extern(alloca)
    {
        /* alloca is declared so we can use it */
    }
    else
    {
        /* Do some other trick */
    }
}

[toc] | [prev] | [next] | [standalone]

#68891

On 2.10.2019 10:03, Frederick Gotham wrote:
> On Monday, September 30, 2019 at 1:02:16 PM UTC+1, Bonita Montero wrote:
>> I know alloca() neither is an official part of the C nor C++ program-
>> ming-language. But I use it for performance-reasons. Can anyone name
>> compilers that don't support alloca()?
>
>
> I wonder if this would be a good reason to add a new compile-time operator to the C++ language? We could re-use the keyword 'extern' as follows:
>
> #include <some_header.hpp>
>
> int main()
> {
>      if extern(alloca)
>      {
>          /* alloca is declared so we can use it */

Please, when proposing new extensions for C++, could we refrain 
ourselves from things which would increase the danger of poorly 
predictable nasty fatalities like stack overflows? There are already 
enough ways to shoot someone's legs off in C++.

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | comp.lang.c++

csiph-web