Re: Ada.Containers.Vectors - querying multiple elements

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1wjh6qsazg3rg$.lupowyuqu0tw$.dlg@xxxxxxxxxxxxx
....
> I wonder if introducing ranges as a type class could mend this. Provided a
> fictitious attribute Enum'Range (0) would return a null-length range, one
> could then create empty arrays without referencing to any concrete index
> bounds. But then Obj'First and Obj'Last could potentially raise
> Constraint_Error, which might appear unpleasant but perfectly consistent.
> Could there be a distributed overhead in the implementations of 'First and
> 'Last then?

Yes, there would be a distributed overhead. For Janus/Ada (the only compiler
for which I can speak definitively), in the general case array bounds are
stored in a descriptor record, along with a dimension length and a pointer
to the data. The dimension length is really redundant; I don't think most
compilers store it separately. In order to be able to represent an array as
you say, all compilers would have to store the dimension length and
presumably a bit mask to specify which bounds are invalid and raise C_E if
explicitly touched. And of course all references to 'First and 'Last would
have to check the bit mask. Not too expensive, but certainly a significant
change to compilers and some additional overhead.

Array indexing in the general case subtracts 'First from the calculated
value, so I don't think it would make sense to allow 'First to be an invalid
value - at least not unless the length of the array was 0 (in which case it
doesn't matter). But adding overhead to array indexing operations is not
going to win anyone friends. :-) More seriously, I think it would be a
non-starter.

You also have the problem of making the range check for any value when one
or the other bound could be invalid. More overhead in a particularly bad
spot.

So I don't think this idea is going to fly.

Randy.




.

Relevant Pages

  • array operations on non-conforming arrays -- do compilers catch them?
    ... I am finding that most Fortran 95 compilers do not catch, ... many invalid uses of non-conforming arrays when array subscripts ... For the following invalid code, ...
    (comp.lang.fortran)
  • Re: A Tale of Two Memory Managers (long)
    ... compilers. ... but the JIT also generates atrocious code. ... Multidimensional array access is even worse. ... deep implications for performance as every structure goes through the stack. ...
    (borland.public.delphi.non-technical)
  • Re: [OT] Funny
    ... matter of what is likely to happen in practice than what the standard ... Or more precisely, mixing f77 and f90. ... That's because f77 had no concept of array stride (i.e. noncontiguous ... to do was pass its starting address...and that's all most compilers ...
    (comp.lang.fortran)
  • Re: xlf Fortran Oddity
    ... I do not believe that Allocatable Derived Type is a Fortran 90/95 construct. ... This is supported by some compilers as an F2k extension. ... When compiled with array bounds checking, ... allocate & initialize derived type ...
    (comp.lang.fortran)
  • Re: Text Script
    ... > more overhead than reading from an array as it is an in-memory operation. ... For small files this adds much overhead. ... >> Rewinding a file might indeed be instantaneous as you say, ... design time efficiency may be in the eye of the beholder - ...
    (microsoft.public.windows.server.scripting)