Pointers vs. allocatable arrays in derrived types 
Author Message
 Pointers vs. allocatable arrays in derrived types

Hello,

Subj
I'm interesting in difference of using pointers and allocatable arrays
as components of type:
1. What is better to use for incapsulation of [diagonal] matrices,
vectors?
2. What difference in assignment? I mean, what happens will assign one
exemplar to another? When we should override assignment?
3. What difference in perfomance and optimization? I heard that in
optimizing arrays-pointers computation compiler should specialy look do
operands look to different storage in memory, while in allocatable he
knows that to different, not the same storage, so he can optimize.
4. I found that vectorization doesn't work sometime when arrays are
componets of derrived type.
vector1 = vector1 + vector2 ! No vectorization.
Array1 = Array1 + Array2 ! Yes, of course.

Any advise and experience.. I think it's important to decide what use
in this cases.



Wed, 23 Jul 2008 02:07:15 GMT  
 Pointers vs. allocatable arrays in derrived types

Quote:

> I'm interesting in difference of using pointers and allocatable arrays
> as components of type:

An important difference is that allocatable components require the
allocatable TR to f95 and thus are not in older compilers (though most
current ones tend to suppiort the TR). Besides that.

For the most part, you should only use pointers in situations where you
want to do the kinds of things that are fundamental to pointers - being
able to have multiple pointers to the same target, being able to point
to a pre-existing target, and the like.

Becasue you can allocate through a pointer, it is possible to use
pointers as a workaround for places where allocatables used to be
disallowed (before the TR). But it really is a workaround - that's not
what pointers are for.

One consequence of it being a workaround is that the result is often
non-intiutive if you are just thinking of the pointer as a way to
allocate something dynamically sized. This leads to errors. In
particular.

Quote:
> 2. What difference in assignment? I mean, what happens will assign one
> exemplar to another? When we should override assignment?

Assignment for pointer and allocatable components is completely
different. Allocatable components do what you would probably expect; x=y
results in both x and y having separate "copies" (allocations) that have
the same values. Pointer components do what you ought to expect if you
are thinking of them as poiners; you end up with two copies of the
pointer, but not two copies of the target. Both pointers are pointing at
the same target. If you were just using pointers as a way to dynamically
allocate something, this won't be at all what you expected.

You can override assignment in the pointer case, but there are also a
host of other situations where you have to think carefully about the
effects of using pointers like this. It is very prone to memory leaks
and to program bugs from trying to use undefined pointers.

So my advice is to use allocatables if all the compilers you envision
using support them. Use pointers only if you must. The poingter case wil
be trickier and more bug prone. As long as you do only the most trivial
of things, the two look pretty similar, but as soon as you start doing
anything at all non-trivial, even something so simple as an assignment,
then you have to think carefully aboiut the pointer case.

(You might ask how something can be more trivial than assignment. That
would be just using the derived type to organize and hold the data,
possibly having multiple objecst of the type, but never doing operations
on the derived type object as a whole).

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



Wed, 23 Jul 2008 02:24:23 GMT  
 Pointers vs. allocatable arrays in derrived types

Quote:


>>I'm interesting in difference of using pointers and allocatable arrays
>>as components of type:

> An important difference is that allocatable components require the
> allocatable TR to f95 and thus are not in older compilers (though most
> current ones tend to suppiort the TR). Besides that.

> For the most part, you should only use pointers in situations where you
> want to do the kinds of things that are fundamental to pointers - being
> able to have multiple pointers to the same target, being able to point
> to a pre-existing target, and the like.

> Becasue you can allocate through a pointer, it is possible to use
> pointers as a workaround for places where allocatables used to be
> disallowed (before the TR). But it really is a workaround - that's not
> what pointers are for.

> One consequence of it being a workaround is that the result is often
> non-intiutive if you are just thinking of the pointer as a way to
> allocate something dynamically sized. This leads to errors. In
> particular.

>>2. What difference in assignment? I mean, what happens will assign one
>>exemplar to another? When we should override assignment?

> Assignment for pointer and allocatable components is completely
> different. Allocatable components do what you would probably expect; x=y
> results in both x and y having separate "copies" (allocations) that have
> the same values. Pointer components do what you ought to expect if you
> are thinking of them as poiners; you end up with two copies of the
> pointer, but not two copies of the target. Both pointers are pointing at
> the same target. If you were just using pointers as a way to dynamically
> allocate something, this won't be at all what you expected.

> You can override assignment in the pointer case, but there are also a
> host of other situations where you have to think carefully about the
> effects of using pointers like this. It is very prone to memory leaks
> and to program bugs from trying to use undefined pointers.

> So my advice is to use allocatables if all the compilers you envision
> using support them. Use pointers only if you must. The poingter case wil
> be trickier and more bug prone. As long as you do only the most trivial
> of things, the two look pretty similar, but as soon as you start doing
> anything at all non-trivial, even something so simple as an assignment,
> then you have to think carefully aboiut the pointer case.

Hmm. I've been wrong enough times in the past about pointers, that I better ask this if
only to clarify my understanding. If I have:

   type :: mytype
     real, pointer :: x(:)
   end type mytype

   type(mytype) :: a, b

   allocate(a%x(10))
   a%x = 5

   allocate(b%x(10))
   b%x = a%x

   deallocate(a%x)

the last assignment copies the target of a%x to the target of b%x, so the subsequent
deallocation of a%x has no effect on b%x, right? I sure hope so.

cheers,

paulv

--
Paul van Delst



Wed, 23 Jul 2008 03:48:19 GMT  
 Pointers vs. allocatable arrays in derrived types

Quote:


...
>> So my advice is to use allocatables if all the compilers you envision
>> using support them. Use pointers only if you must. The poingter case
>> wil be trickier and more bug prone. As long as you do only the most
>> trivial of things, the two look pretty similar, but as soon as you
>> start doing anything at all non-trivial, even something so simple as
>> an assignment, then you have to think carefully aboiut the pointer
>> case.

> Hmm. I've been wrong enough times in the past about pointers, that I
> better ask this if only to clarify my understanding. If I have:

>    type :: mytype
>      real, pointer :: x(:)
>    end type mytype

>    type(mytype) :: a, b

>    allocate(a%x(10))
>    a%x = 5

>    allocate(b%x(10))
>    b%x = a%x

>    deallocate(a%x)

> the last assignment copies the target of a%x to the target of b%x, so
> the subsequent deallocation of a%x has no effect on b%x, right? I
> sure hope so.

You are correct.  But suppose instead of

   allocate(b%x(10))
   b%x = a%x

You had written:

   b = a

I that case, the X component of B would have been pointer
associated with the X component of A, and the subsequent
deallocate of A%X would also leave B%X undefined.
This doesn't happen if allocatable components are used instead.
In that case, the ordinary assignment above has the same
meaning as the allocate followed by the component assignment
you wrote out originally.  That's the kind of thing Rich Maine
was talking about: defauly assignment for allocatable components
uses the so-called "deep copy", while default assignment for
pointer components uses "shallow copy" semantics.  Things
can get pretty confusing with pointers.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare



Wed, 23 Jul 2008 04:14:55 GMT  
 Pointers vs. allocatable arrays in derrived types
Richard Maine

Quote:
> For the most part, you should only use pointers in situations where you want to do the kinds of things that are fundamental to pointers - being able to have multiple pointers to the same target, being able to point to a pre-existing target, and the like.

.. lists and so on. Yes, using them for what they are.

Quote:
> So my advice is to use allocatables if all the compilers you envision using support them. Use pointers only if you must.

Ok. Thanks for advise. I'll follow it.


Wed, 23 Jul 2008 17:46:01 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. pointers vs allocatable arrays

2. ALLOCATABLE arrays vs POINTERs

3. Efficiency of pointer vs. allocatable arrays in F90

4. Allocatable array of allocatable defined types?

5. allocatable vs non-allocatable arrays

6. problem: type + allocatable + pointer

7. allocatable and pointer in a type

8. Pointer to allocatable array

9. deallocating via pointer associated with allocatable array

10. Using a pointer like an allocatable array

11. Allocatable vs pointer in procedure resolution

12. allocatable/pointer arrays

 

 
Powered by phpBB® Forum Software