Prev: parameter inconsistency (now adjustable dimensions of arguments)
Next: call c lib from fortran in ms visual studio 2005
From: Jim Xia on 21 May 2010 13:58
On May 20, 9:41 pm, nos...(a)see.signature (Richard Maine) wrote:
> Ian Harvey <ian_har...(a)bigpond.com> wrote:
> > On 2/05/2010 9:04 AM, Ian Harvey wrote:
> > > Is there a way to suppress the intrinsic assignment of a derived type,
> > > so that an attempt to use intrinsic assignment (versus defined
> > > assignment) results in a compile time error?
> >  From the lack of response, I'll take the answer to the question as
> > being "No".
>
> I don't recall seeing your original post. I'm not sure whether that
> means I really didn't see it or just read it quickly without answering
> and then forgot about it. In any case, I'll confirm that the answer is
> "no", so that you don't have to interpret the silence.


I didn't see your post either. For the type-bound assignment, it is
invoked even during the intrinsic assignments for components come with
type-bound assignment. This is quite different from F95 rules.

>
> > One way of ensuring that the right assignment procedure gets called
> > appears (when supported by enough compilers) to be to make it a type
> > bound procedure.


Right, I agree. That's also how XLF implements the type-bound
assignments.


>
> I recall that things like accidentally getting intrinsic assignment were
> specifically cited during development of the standard as among the
> problems that type-bound assignment was going to help with.
>
> > My understanding though, is that this then means that each entity and
> > each call will come with all the baggage associated with type bound
> > procedures (akin to virtual calls and vtables in C++ implementations?).
> >   Or does the specification of type bound procedures in the standard
> > mean that compilers can see that the type isn't extended in a particular
> > use and so it can implement the assignment just like it would for F95
> > defined assignment?
>
> I can't give you all the implementation details from my personal
> knowledge. Have to ask the vendors that one. But I was told by people
> who at least talked convincingly like they understood the issues
> (convincingly enough for me) that the f2003 spec was avoiding a lot of
> the overhead of C++ in this area. I think that avoidance of multiple
> inheritance might have been one of the things that helped, but I could
> well be confusing separate issues here. Maybe someone else can provide
> more details.


Multiple inheritance often leads to design difficulties. It's not a
performance issue that it is not included. In Fortran you can declare
an entity using TYPE like the following
TYPE (x) :: y
then "call y%foo()" is resolved at compile time, not run time overhead
here. The point here is if you know your object y is always of type
x, then there is no polymorphism involved. Even though the type may
come from a deep hierarchy tree, you still can resolve the function
calls at compile time. It has a performance advantage.

If you don't know the dynamic type of y, then you have to declare y as
CLASS(x) :: y !<-- assume a dummy argument

Then "call y%foo()" is resolve at runtime based on the dynamic type of
y. You'll pay the overhead to find the correct function at runtime.

Another different between Fortran's OO and C++'s OO is in the arrays.
If you're familiar with C++'s object model, then you know for a C++
array, each elemnet hold a vft pointer. This is because each element
of the array can be of different dynamic type. For Fortran this is
not the case. So there is no need to stuff a vft pointer to each
element in an array. This may lead to a better performance during the
array processing because all the type-bound procedure calls "x(i)
%foo()" are invoking the same procedure.

My belief is one shouldn't be afraid of OO simply because someone has
said it "hurts" performance. The key is you have to balance out your
development cost (including maintenace and bug fixes) vs the run
cost. Very often, people find the dominating cost is the
maintenance. Stuck in an old language will eventually hurt more in
the long run.

Cheers,

Jim
First  |  Prev  | 
Pages: 1 2
Prev: parameter inconsistency (now adjustable dimensions of arguments)
Next: call c lib from fortran in ms visual studio 2005