From: gmail-unlp on
On Aug 11, 2:43 am, Daniel Kraft <d...(a)domob.eu> wrote:
> gmail-unlp wrote:
> > and taken into account the gfortran option -std=f2003 without any
> > warnings on incomplete support, added to my lack of expertise, I
> > assumed that at least most of the 2003 standard was already supported
> > after... 7 years... Again, thank you very much. If possible, I would
> > like to know the most important OO features not yet implemented (in
> > gfortran or the compiler you are using) that you consider necessary
> > for the
> > "
> > ...potential benefit in using Fortran2003 OO stuff in some of my day
> > to day work...
> > "
>
> You can look at the GFortran wiki:
>
> http://gcc.gnu.org/wiki/Fortran2003http://gcc.gnu.org/wiki/Fortran2003Statushttp://gcc.gnu.org/wiki/Fortran2008Status
>
> We're working on F2003 and experimental F2008 support, and AFAIK a good
> part of OOP is already implemented -- but not all of it.
>
> Yours,
> Daniel

Thanks, Daniel,

I've read those lists before my previous post, and I'm interested in
those features not implemented in the compilers that prevent taking
advantage of the "potential benefit of Fortran OO stuff". I'm
considering the risks of rewriting legacy code (mostly in FORTRAN 77,
maybe some in FORTRAN 66) and I would like to know from those actually
using Fortran why they say Fortran compilers lack OO support,
explicitly what kind of support they consider current compilers fail.

Thanks again,

Fernando.
From: dpb on
Vincenzo Mercuri wrote:
....

> THANK YOU ALL for your answers, now I think I have a clearer idea
> of what to do. thanks.

Which is/would be????

I'd suggest follow-up on the reference book -- there's one by several of
the contributors here--Richard M et al.

--
From: Paul van Delst on
Hello,

Gary L. Scott wrote:
> On 8/10/2010 6:55 PM, Paul van Delst wrote:
>>
>>
>> gmail-unlp wrote:
>>>
>>> Why OO in Fortran is not an alternative?
>>
>> The fact that f2003 compilers are still (!) not widely available?
>>
[snip]
>> I've
>> given up asking vendors when fully compliant f2003 compilers will be
>> available since I always get the same response:
>> "Please let us know what features you would like implemented".
>> Crikey... all of 'em!
>
> But they're asking which ones you want FIRST. They are asking for
> priorities. They can't do them all at once.

I realise that - my reply was a bit curmudgeonly. In my defense, I didn't seriously start asking about full-f2003
support until a couple of years ago - at which point I did give my $0.02 worth on what I wanted things I would like
implemented first.

It's now half-way through 2010.

I'm (well, my work is) paying maintenance and license fees on various compilers so I don't think it's unreasonable to
expect implementation of a 5 year old standard to be available (we'll assume the year 2003 is not when the clock starts
ticking).

To be honest, all I would like to see/hear from vendors is something like "we will be releasing a fully compliant
Fortran2003 compiler for <insert platforms here> in version XX in 1st quarter 201?" (insert your own digit for the "?").
At least then I could start planning for adoption of f2003 in general (e.g. giving tech seminars on how to use it in
current and new code development, get the $$ for new licenses in budgets for the coming year, etc).

Unless you're writing code just for yourself or a small group of people in an organisation, the availability of f2003
has to be widespread across vendors and users before it can be effectively used (IME).

cheers,

paulv

From: Vincenzo Mercuri on
dpb wrote:
> Vincenzo Mercuri wrote:
> ...
>
>> THANK YOU ALL for your answers, now I think I have a clearer idea
>> of what to do. thanks.
>
> Which is/would be????


To learn some Fortran on my own, at least to be able
to understand existing code or interface it to C.
Actually, an easier matrix manipulation syntax is a great
temptation. Apart from these reasons, learning a new language
is not that bad.


> I'd suggest follow-up on the reference book -- there's one by several of
> the contributors here--Richard M et al.


You are right, I'll post a follow-up. thanks


--
Vincenzo Mercuri
From: Ron Shepard on
In article <4c628139$0$56730$c30e37c6(a)exi-reader.telstra.net>,
"robin" <robin51(a)dodo.com.au> wrote:

> | [...] Also, float arguments were promoted to double
> | in all function calls,
>
> That may or may not be a problem, as in the PC,
> float arithmetic is performed in extended precision.

Not always. In particular, SSE operations are done in either 32-bit
or 64-bit arithmetic.

> [...]
> | For example, something declared as float on one machine might have
> | the same precision as something declared as double or as long double on
> | some other machine.
>
> That can happen in Fortran too.

Only if you go out of your way to make it happen with modern
fortran. As I describe a few sentences later, in fortran 90 and
later you can use parameterized declarations with KIND,
selected_real_kind(), precision(), and so on to pick the desired
precision. A one-line change in a single module is all it takes to
bring an entire program into conformance with the desired precision,
or if the original programmer used foresight with
selected_real_kind(), maybe even a zero-line change.

>
> | [...] Arrays in fortran can have any base at all,
> | whatever best fits the problem at hand.
>
> Good point, but FORTRAN used to have 1 as the base.

Yes, that was the case in the 1950's and 1960's, but it has not been
the case since f77 which allowed array dimensions to have arbitrary
lower bounds. If you are counting, that's over three decades, which
is probably longer than the original poster has been alive.

Nonetheless, all of these points are important because a typical
numerical algorithms programmer in fortran will almost certainly
encounter legacy fortran codes that were written in the 60's, before
the nice modern constructs were available. It is absolutely safe to
say that no C programmer will encounter legacy C codes from that
same era.

$.02 -Ron Shepard