Re: Allocatable array of allocatable defined types?

On Apr 30, 11:21 am, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
Mark Morss <mfmo...@xxxxxxx> wrote:
On Apr 30, 10:21 am, "Michael Metcalf" <michaelmetc...@xxxxxxxxxxxxxx>
wrote:
type alloc
real, dimension(:), allocatable :: a1
real, dimension(:), allocatable :: a2
end type alloc

type(alloc), dimension(:), allocatable :: work

integer, parameter :: ll = 3

allocate(work(2))
do i = 1, 2
allocate(work(i)%a1(ll), work(i)%a2(ll))
end do
...
It surprises me that you can allocate an array "before" the size of
its elements is known. Apparently the compiler looks ahead and
figures this out?!

No. It isn't a matter of looking ahead, which wouldn't be possible
except in the most trivial cases. When the derived type array is
allocated, the elements are initially all created as unallocated. There
is no data space for them at all until they are, in turn allocated.

I suspect you are not seeing that the implementation of an allocatable
component will look a lot like a pointer in that the actual data space
for the component will be elsewhere in memory rather than embedded in
with the rest of the components. Somethingh that looks much like a
pointer is all that is in the memory space with with the rest of the
components.

The low-level use of constructs like those of pointers is "hidden" from
you. The compiler takes care of the details in a way that works out much
better than if you have to directly use pointers yourself (as does much
code from days before the TR was widely supported, which has only been
relatively recently).

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain


That's very useful to know, thank you.

.

Relevant Pages

  • Re: Allocatable array of allocatable defined types?
    ... end type alloc ... is no data space for them at all until they are, ... component will look a lot like a pointer in that the actual data space ... pointer is all that is in the memory space with with the rest of the ...
    (comp.lang.fortran)
  • Re: X-Mega AVRs are here!
    ... change - but it would have been perfectly possible to make the flash accessible in the data space as well. ... There is no way to express ideas such as a pointer that is accessed by "lpm" instead of "ld", and there is no way to write a function with a pointer parameter which will work with both a pointer to flash and a pointer to ram. ... Solutions include macro wrappers (used by avr-gcc - fully standard C, but a bit ugly), abusing the "const" keyword, a new "flash" keyword, and generalised pointers. ...
    (comp.arch.embedded)
  • Re: X-Mega AVRs are here!
    ... flash accessible in the data space as well (in the same way as the ... eeprom is now mapped into the data space). ... There is no way to express ideas such as a pointer that is ... standard C, but a bit ugly), abusing the "const" keyword (used by ...
    (comp.arch.embedded)
  • Re: Just what makes an architecture "C Friendly"?
    ... Because C only recognizes one kind of data space. ... pointer is a pointer, but in a Harvard machine a pointer to code space ... 16 KiB code and 1 KiB data space, you still would have to use two byte ... macros could not be used for the same reason and had to be replaced ...
    (comp.arch.embedded)