Prev: gcc4.4: f951: warning: command line option "-MM" is valid for C/C++/Java/ObjC/ObjC++ but not for Fortran
Next: Bad dependency relation for "gfortran"
From: gmail-unlp on 11 Aug 2010 09:02 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 11 Aug 2010 09:24 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 11 Aug 2010 10:40 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 11 Aug 2010 11:48 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 11 Aug 2010 11:53
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 |