Re: Is this legal and if not why not?
- From: nospam@xxxxxxxxxxxxx (Richard E Maine)
- Date: Mon, 19 Dec 2005 10:34:15 -0800
David <Contributor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> It seems to work but is it standard Fortran and if not why not?
> A base type:
>
> type TBase
> sequence
> integer :: a
> end type TBase
>
> A derived type:
>
> type TDerived
> sequence
> type(TBase) :: base
> integer :: b
> end type TDerived
>
> Casting:
>
> type(TBase) :: basetype
> type(TDerived):: derivedtype
>
> equivalence(basetype, derivedtype) ! is this standard/legal
No. Such "why" questions are mostly unanswerable with anything than
"because that's the way the votes came out". Sometimes one can posit
relatively simple explanations, but this isn't really such a case. There
are *LOTS* of intertwining issues on this one. For example, a full
explanation would no doubt have to get into the inclinations of some
people to avoid extending equivalence at all, the differring
inclinations of other people, and the process of resolving the conflicts
between those camps. You can never really get a good answer for things
like that - anyone that claims to be able to give a full unbiased answer
is probably just demonstrating his/her biases :-)
With that huge caveat that this won't be all of the reasons, and perhaps
not even the most important ones, let me mention at least one technical
issue.
You can *NOT* assume that even sequence types are actually laid out in
memory in the "obvious" way. Hardware alignmenmt issues get in the way.
The alignment requirements can and do vary among hardware platforms, so
things that depend on them are inherently non-portable. Such
non-portable things are exactly the kind of things where the standard
tends to say something is nonstandard. That doesn't necessarily mean all
compilers will reject it - but it does mean that it is likely to get
different results on different platforms, and some compilers might
reject it.
For example, this is *VERY* much parallel to the f77 restrictions
against equivalencing character and non-character data.
Basically, what sequence does for you is just allow you to have "the
same" (or close enough) type declaration in two different scoping units
and be sure that they will be compatible. Think of it as ensuring a
degree of consistency.... but that consistency does not have to imply
that things are laid down in exactly the order that you write the
components, and with no padding. There might be padding. The components
storage order might be rearranged (to avoid padding). Whatever. So in
your case above, the base component might not actualy be the first thing
in memory in TDerived. Ok, odds are that it will in this particular
case, but that doesn't necessarily generalize, and the hstandard doesn't
require it.
> or without need of the EQUIVALENCE
>
> call Base1(derivedtype%base)
That works. But sometimes it isn't convenient.
> What is missing? What OO function cannot be achieved with Fortran 90?
That's a big question. You *CAN*, of course, do anything. Fortran 90 is
Turing complete. Sometimes things get awkward, though. This post isn't a
good place to do a full treatment of the f2003 OO features and what they
do for you. I've tried to write up a bit on that, but it is more than I
can fit in the margin of this posting. :-) Besides, one of our security
folk wants to kick me off this machine for a while to install
patches/upgrades.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.
- References:
- Is this legal and if not why not?
- From: David
- Is this legal and if not why not?
- Prev by Date: Is this legal and if not why not?
- Next by Date: Re: about c to fortran
- Previous by thread: Is this legal and if not why not?
- Index(es):
Relevant Pages
|
Loading
