schwea@aur.alcatel.com (E. Schweitz) wrote:

>In article <49lidc$bjc@natasha.rmii.com>,
>Jerry Coffin <jcoffin@rmii.com> wrote:
>>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:
>>>>IMHO the most important reason to disallow RT-sized arrays
>>>>is that then sizeof also becomes a RT-size.
>>
>>>A fair point -- but would that really cause any problems?
>>
>>Unless I'm missing something, a run-time version of sizeof would likely
>>have to evaluate its argument, so you'd basically end up with two
>>different sizeof's - one that happened at compile time, didn't evaluate
>>its argument and allowed use of expressions that can't be evaluated
>>legally.

>While the essence here is true, I don't think it is a real problem.  The
>compiler must be able to detect a variable of type dynamic array (as
>I'm late to this discussion, I am assuming dynamic arrays are arrays
>allocated on the stack of variable size) and thus infer that it must
>compute the sizeof said array at run-time.  Which basically, it has to
>do anyway under these assumptions.

That was more or less what I was trying to say -- basically all that's
happening is that sizeof is getting overloaded, which at least initially
doesn't seem like it should be a particularly difficult thing to handle
since operator overloading is already common throughout the language.

At the same time, I'm a bit hesitant to say that it's necessarily
trivial without hearing something from a compiler author who's actually
done it...
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

jbuck@Synopsys.COM (Joe Buck) wrote:
>
>Rohan Lenard asks:
>>> Why is there no auto_array_ptr in the DWP ? Is it an omission or a mistake ?
>
>Nathan Myers <ncm@netcom.com> writes:
>>Neither.  The feeling in the committee was that that would be too close to
>>vector<>.  I.e. when you think you want an auto_array_ptr, consider using
>>a vector<> instead.
>
>In my humble opinion, this is a mistake; vector<> is a far bigger chunk of
>code than auto_array_ptr<> and supports functionality beyond what a natural
>auto_array_ptr would supply.

Actually, this need not be the case. If you _use_ a vector
"as if" it were a less kind of array type, the code
for the "extra" functionality won't be generated.
If the use is lexically restricted to a block, then
in theory a compiler could optimise vector to work exactly
like a dynamically allocated array.

Remember vector isn't really a template, it's a built in
structuring tool of the C++ language just like
"array" or "struct" is.

Don't expect this kind of optimisation right away --
we need stable working ISO C++ implementations first.


--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <49lidc$bjc@natasha.rmii.com>,
Jerry Coffin <jcoffin@rmii.com> wrote:
>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:
>>>IMHO the most important reason to disallow RT-sized arrays
>>>is that then sizeof also becomes a RT-size.
>
>>A fair point -- but would that really cause any problems?
>
>Unless I'm missing something, a run-time version of sizeof would likely
>have to evaluate its argument, so you'd basically end up with two
>different sizeof's - one that happened at compile time, didn't evaluate
>its argument and allowed use of expressions that can't be evaluated
>legally.

While the essence here is true, I don't think it is a real problem.  The
compiler must be able to detect a variable of type dynamic array (as
I'm late to this discussion, I am assuming dynamic arrays are arrays
allocated on the stack of variable size) and thus infer that it must
compute the sizeof said array at run-time.  Which basically, it has to
do anyway under these assumptions.

--
Eric



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:

>>IMHO the most important reason to disallow RT-sized arrays
>>is that then sizeof also becomes a RT-size.
>
>A fair point -- but would that really cause any problems?

I see two possibilities.  First sizeof(RT) would be flagged as a
syntax error, or it computes the size correctly.


Ralph Shnelvar      "We make tape drives work like disk drives"
President           http://www.ecnet.com/tpd/index.html
TAPEDISK Corporation

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:


>>IMHO the most important reason to disallow RT-sized arrays
>>is that then sizeof also becomes a RT-size.

>A fair point -- but would that really cause any problems?

Unless I'm missing something, a run-time version of sizeof would likely
have to evaluate its argument, so you'd basically end up with two
different sizeof's - one that happened at compile time, didn't evaluate
its argument and allowed use of expressions that can't be evaluated
legally.

It'd be interesting of anybody from Metaware were to jump in on this one
- their Direct to SOM system on OS/2 already does run-time evaluation of
sizeof at least part of the time, so their information on the subject
would be less speculative than mine.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Rohan Lenard asks:
> Why is there no auto_array_ptr in the DWP ? Is it an omission or a mistake ?

Neither.  The feeling in the committee was that that would be too close to
vector<>.  I.e. when you think you want an auto_array_ptr, consider using
a vector<> instead.

Nathan Myers
myersn@roguewave.com

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

IMHO the most important reason to disallow RT-sized arrays
is that then sizeof also becomes a RT-size.
You cant consider one without the other.

To get around this with the least effect on other parts of
the language the easiest way would be to disallow sizeof for
RT-sized arrays (ugly).


Ulf Schuenemann

--------------------------------------------------------------------
 ,_.   Ulf Schuenemann
#,  \  Fakultaet fuer Informatik, Technische Universitaet Muenchen, Germany.
 |   > email: schuenem@informatik.tu-muenchen.de
 v=-<  WWW:   http://hphalle2.informatik.tu-muenchen.de/~schuenem/

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <30BA28C5.50C6@netcom.com> you write:
>Rohan Lenard asks:
>> Why is there no auto_array_ptr in the DWP ? Is it an omission or a mistake ?
>
>Neither.  The feeling in the committee was that that would be too close to
>vector<>.  I.e. when you think you want an auto_array_ptr, consider using
>a vector<> instead.

Which unfortunately is a bit sad, since there is a whole heap of code
out there which would benefit from this immediately (without a significant
amount of rewrite).  Having to use vector of cause does impose a
significant amount of rework - for little additional (on top of auto_ptr)
value :-(

Rohan

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

> ==========Michael Elizabeth Chastain, 11/25/95==========

> I say 'may have to' because every processor I know can implement
> variable-sized stack frames by subtracting an appropriate value from
> the stack pointer at the appropriate time.  But what about processors I
> don't know about?  Are there truly any processors in use which don't
> support subtracting a computed value from the stack pointer?

Subtract implies stack direction.  There have been machines with
stacks that increased in address instead of decreased in address.
Have they all really disappeared from heavy use?  I am rusty
on current machine architectures, but an amazing variety of
architectures have existed, including some for which the address
of a memory location varied according to the width of the access.

Also, how about the case of several of these in one stack frame.
The "start" (i.e., address) of some is affected by the size of others
rather than just being an offset into the stack frame from the frame
pointer.  That makes the solution messier to do and starts favoring
the various heap schemes for this as preserving fixed frame offsets
is usually a very good thing to do.

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Dick Menninger <Dick.Menninger@daytonoh.attgis.com> wrote:

[snip]

>Also, how about the case of several of these in one stack frame.
>The "start" (i.e., address) of some is affected by the size of others
>rather than just being an offset into the stack frame from the frame
>pointer.  That makes the solution messier to do and starts favoring
>the various heap schemes for this as preserving fixed frame offsets
>is usually a very good thing to do.

I remember the old TI 990 Pascal (God am I getting old.)

Dynamically sized arrays could be placed on the stack.  If there were
multiples, the sum of all the sizes was was subtracted (added?) to the
stack pointer and then a pointer to the appropriate place in this
stack frame was where you found the array.  Of course, all of this was
done automatically.

Ralph Shnelvar      "We make tape drives work like disk drives"
President           http://www.ecnet.com/tpd/index.html
TAPEDISK Corporation


[Moderator's note: this discussion is still relevant to the design of
C++, but it's beginning to edge in a different direction.  Please
think about which newsgroup(s) your response belongs in.  mha]

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

schuenem@informatik.tu-muenchen.de (Ulf Schuenemann) writes:

>IMHO the most important reason to disallow RT-sized arrays
>is that then sizeof also becomes a RT-size.

A fair point -- but would that really cause any problems?

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
I will have little or no net access from Nov 30 until Dec 25,
so please email me a copy of any follow-ups.

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Has allowing the following been considered?

  int  length = strlen (some_string);
  char buffer [ length ];

  // ...

I.E. allowing non const array sizing.

g++ can do it, so I'd be surprised if this has not been considered,
but it does not seem to be in the DWP. Does anyone know the story?

Thanks,
Joe.

--
  ____
 |___ | ___  ___   EMail: walkerjj@sweng.ecid.cig.mot.com
 _  | |/ _ \| __|  SMail: Motorola, 16 Euroway, Blagrove, SWINDON SN58YQ
| |_| | (_) | _|   Tel:   [+44/0] 793 54 5346
 \___/ \___/|___|  Fax:   [+44/0] 793 54 1228

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

clamage@Eng.Sun.COM (Steve Clamage) writes:
 ...
>The standard could say that an implemention is allowed to simulate
>variable-sized stack or static arrays by using the heap and automatically
>deallocating the storage.

I think that, while a minor issue, this would have been preferable
to the present situation of forbidding the arraysize to be runtime
computed.  gcc has had runtime arraysizes forever as an extension,
and it does not seem to have given it any trouble being portable.
But I cannot _use_ that extension if I want my code to stay portable
(except through the usual '#if' rigmarole, of course:-).

>IMHO that is not acceptable because in
>portable code you would not know whether a declaration like
> char buffer[length];
>could fail.

But that would be no different from the present situation!  I.e., in
portable code you DO not know whether a declaration like
 char buffer[16384];
can fail; it depends on whether your current stack has space for
it, on whether the OS can extend that stack dynamically for you,
etc, etc.  And, if it does fail, there's no *portable* way to
catch it, either.

>It also could turn what looks like a simple declaration into
>a heavy-weight operation.

Again, no different from the present situation; the OS might be
extending your stack for you "transparently", which can be just
as "heavy" as the compiler/runtime handling the extension of the heap
(perhaps by more direct negotiation with the OS).

>You can get the effect you want by using an auto_ptr and heap allocation,

auto_ptr does not handle builtin arrays, so how could it ever help here?
If you new[] some memory, you cannot use the resulting pointer to an
auto_ptr nor any other standards-supplied class -- you have to use a
bare pointer, or roll-your-own -- in which latter case the following
idea appears much more promising:

>or by using an array class instead of a C-style array.

Yep, that would surely be the best approach in 99.44% of the cases.
Still, it DOES imply overhead (heap rather than stack allocation)
since that builtin class, in turn, cannot portably use a runtime
computed arraysize except on the heap.  A minor matter, but, it's
a pity that the standard does not supply a portable way to say
"place this on the stack if feasible on this platform otherwise
handle the heap dance transparently":-).


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9532616.4242@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
> But as you suggest below, on platforms for which stack allocation is
> difficult, the compiler could simply allocate such arrays on the heap.
> In any case, there is a very large variety of prior art in terms of
> language implementations that support variable length arrays on a variety
> of platforms.  For example, all Ada implementations support this.
> So does GNU C.

I accept the prior-art argument and the usefulness argument.

But I don't accept this part: 'the compiler could simply allocate such
arrays on the heap.'

The compiler may have to use a hidden auto-pointer-like mechanism for
removing such arrays from the heap in cases of function returns,
longjmp, and exceptions.  I expect this would be reasonable for function
returns and exceptions.  But it would be new functionality for
'longjmp'.

I say 'may have to' because every processor I know can implement
variable-sized stack frames by subtracting an appropriate value from
the stack pointer at the appropriate time.  But what about processors I
don't know about?  Are there truly any processors in use which don't
support subtracting a computed value from the stack pointer?

Michael Chastain
mec@duracef.shout.net
Check out my cool trace-and-replay debugger:
ftp://tsx-11.mit.edu/pub/linux/sources/usr.bin/mec-0.3.tar.gz
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]