Rebuttal to Treurich et al.
Dan Nagle
Treurich, et al. wrote an article claiming an easy
conversion of their Fortran code to C++.
Toon Moene and I have written a rebuttal which is now
posted on my website, http://users.erols.com/dnagle
click on "Rebuttal to Treurich et al."
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
gib bogle
Jos Bergervoet
> Treurich, et al. wrote an article claiming an easy
> conversion of their Fortran code to C++.
>
> Toon Moene and I have written a rebuttal which is now
> posted on my website, http://users.erols.com/dnagle
Will your text (or some derived version) also appear in "Computing
in Science & Engineering"?
And, by the way, where you write: " ... It is all too easy to find
situations where the restrict keyword is valid for most input datasets
but not unusual edge cases, ... "
^^^
I believe the word 'for' is missing.
This 'restrict stuff' is, AFAIK, the main difference. Aren't you
afraid that people might argue that the implicit presence of
'restrict' in Fortran is dangerous (thereby reversing your argument)?
-- Jos
Dan Nagle
On 18 Jun 2001 21:53:53 GMT, Jos Bergervoet <berg...@iaehv.iae.nl>
wrote:
<snip>
>This 'restrict stuff' is, AFAIK, the main difference. Aren't you
>afraid that people might argue that the implicit presence of
>'restrict' in Fortran is dangerous (thereby reversing your argument)?
It seems to me we've had this debate before, and here in c.l.f anyway,
the result is "you know the rules, play by them".
Besides, are you really going to let a C++ advocate say (with,
presumably, a straight face), "but that's dangerous!" ? ;-)
Jugoslav Dujic
| afraid that people might argue that the implicit presence of
| 'restrict' in Fortran is dangerous (thereby reversing your argument)?
|
| -- Jos
Contrary, Jos, it's not dangerous -- it's restrictive (as the
word says). However, I remember my recent struggling in CLF
("Functions as argument" IIRC) in favor of (a better replacement of)
Cray pointers. My cries that standard should provide a means for
workarounding restrictivity for sake of flexibility weren't quite
supported :-).
Jugoslav
Michael Metcalf
Please note that CISE printed a letter from me on this topic
in the May/June issue. It is at
www.computer.org/cise/cs2001/pdf/c3002.pdf
embedded in the Editorial.
Regards,
Mike Metcalf
--
Jan Vorbrueggen
> Please note that CISE printed a letter from me on this topic
> in the May/June issue. It is at
>
> www.computer.org/cise/cs2001/pdf/c3002.pdf
>
> embedded in the Editorial.
The original author's reply is also revealing. How they manage to read into
your letter that "Fortran 90 ... is inferior to C++" is almost beyond me.
Jan
Stanislaw Kozlowski
discussion.
Imagine a person who attempts to convince us to screw bolts
with a hammer. This is similar to make numerical computations
with C/C++ . Fortran is not ideal, much better for this type of
tasks would be Pascal but .... we do not
have these old, tested, ready to use libraries as in Fortran. So
taking everything into account, for numerics, majority of the programmers
use Fortran. On the other side for manipulating operating system internals
they use C/C++ and not Fortran because for this particular task
it would be too cumbersome.
S. Kozlowski
Poland
"Dan Nagle" <dna...@erols.com> wrote in message
news:1mmsitsagfbndel86...@4ax.com...
Prof. Richard E. Hawkins
Jan Vorbrueggen <j...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
>Michael Metcalf <11354...@CompuServe.COM> writes:
>> Please note that CISE printed a letter from me on this topic
>> in the May/June issue. It is at
>The original author's reply is also revealing. How they manage to read into
>your letter that "Fortran 90 ... is inferior to C++" is almost beyond me.
I'm assuming that it's from noting that C++ went all of the way to OOP,
which, I suppose, is the source of All Goodness.
hawk
--
Prof. Richard E. Hawkins, Esq. /"\ ASCII ribbon campaign
doc...@psu.edu Smeal 178 (814) 375-4700 \ / against HTML mail
These opinions will not be those of X and postings
Penn State until it pays my retainer. / \
Jan Vorbrueggen
> >The original author's reply is also revealing. How they manage to read into
> >your letter that "Fortran 90 ... is inferior to C++" is almost beyond me.
> I'm assuming that it's from noting that C++ went all of the way to OOP,
> which, I suppose, is the source of All Goodness.
That's why I put "almost" in there 8-)...
Jan
Toon Moene
> Dan,
> www.computer.org/cise/cs2001/pdf/c3002.pdf
It might not be that clear from Dan's web page, but he *did* offer the
article to CISE. They never replied to that offer, so we waited 3
months and then decided it could be published without restrictions, i.e.
on that great "freedom of the press" thingie - the World Wide Web.
--
Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
Gib Bogle
>
> Michael Metcalf wrote:
>
> > Dan,
>
> > Please note that CISE printed a letter from me on this topic
> > in the May/June issue. It is at
>
> > www.computer.org/cise/cs2001/pdf/c3002.pdf
>
> > embedded in the Editorial.
> >
> > Regards,
> >
> > Mike Metcalf
>
> It might not be that clear from Dan's web page, but he *did* offer the
> article to CISE. They never replied to that offer, so we waited 3
> months and then decided it could be published without restrictions, i.e.
> on that great "freedom of the press" thingie - the World Wide Web.
Their failure to reply hints at a lack of impartiality, apart from crass
discourtesy.
Dan Nagle
wrote:
>Toon Moene wrote:
>>
<snip>
>> It might not be that clear from Dan's web page, but he *did* offer the
>> article to CISE. They never replied to that offer, so we waited 3
>> months and then decided it could be published without restrictions, i.e.
>> on that great "freedom of the press" thingie - the World Wide Web.
>
>Their failure to reply hints at a lack of impartiality, apart from crass
>discourtesy.
I understand that they changed their address at about the time
I snail mailed the manuscript to them, it's always possible
the snails ate it (i.e., it's lost in the post). ;-)
Perhaps I should try again <sigh>.
I don't think, from reading CSE since the beginning,
that they've ever given Modern Fortran a fair appraisal.
Jos Bergervoet
>>The original author's reply is also revealing. How they manage to read into
>>your letter that "Fortran 90 ... is inferior to C++" is almost beyond me.
> I'm assuming that it's from noting that C++ went all of the way to OOP,
> which, I suppose, is the source of All Goodness.
But then of course, you have to be a fan of All Goodness.
Personally, I like the template classes in C++ (If Fortran had any
form of parametric polymorphism, that would probably be better, but
Fortran hasn't).
Also very nice (in C++) is the automatic memory management (for
function results of dynamic-size type, and similar things) that
Fortran still lacks until allocatable components are introduced,
which means: until f2k. (NB: although the newest version of F
already has it, actually, and some full Fortran compilers support
it as well).
-- Jos
PS: I know that people manage to write code with memory leaks in
C++, but I maintain that C++ has the mechanism to avoid them,
while Fortran (without allocatable components), simply lacks it.
Jos Bergervoet
> I don't think, from reading CSE since the beginning,
> that they've ever given Modern Fortran a fair appraisal.
I think Fortran was mentioned in CISE a few times by Paul Dubois,
(still, it's very likely that there's a conspiracy, of course :-)
-- Jos
Arnaud Desitter
>
> Also very nice (in C++) is the automatic memory management (for
> function results of dynamic-size type, and similar things) that
> Fortran still lacks until allocatable components are introduced,
> which means: until f2k. (NB: although the newest version of F
> already has it, actually, and some full Fortran compilers support
> it as well).
>
For record, I know of:
Lahey, NAG, NAsoftware
Hopefully, more compilers will support that extension in the near
future.
Some code related to code instrumentation is available at:
http://ftp.cac.psu.edu/pub/ger/fortran/test/results.txt
Cheers,
Arnaud
Jos Bergervoet
>> ..
>> Fortran still lacks until allocatable components are introduced,
>> which means: until f2k. (NB: although the newest version of F
>> already has it, actually, and some full Fortran compilers support
>> it as well).
>
> For record, I know of:
> Lahey, NAG, NAsoftware
Although NAG and F have a bug (they don't free the memory in
intent(out) dummies before a routine gives them a new value,
whereas the standard clearly requires this).
> Hopefully, more compilers will support that extension in the near
> future.
Yes. Because then we can show the C++ fans how simple good memory
management can be. In C++ you need to write a class with constructor,
destructor, copy constructor, explicit "deep copy" assignment, all
spelled out in detail. But in f2k, a derived type with allocatable
components automatically has all those things.
Then again, C++ works, and f2k doesn't exist (yet).
-- Jos
Arnaud Desitter
>
> Arnaud Desitter <arnaud....@nag.co.uk> wrote:
> >> ..
> >> Fortran still lacks until allocatable components are introduced,
> >> which means: until f2k. (NB: although the newest version of F
> >> already has it, actually, and some full Fortran compilers support
> >> it as well).
> >
> > For record, I know of:
> > Lahey, NAG, NAsoftware
>
> Although NAG and F have a bug (they don't free the memory in
> intent(out) dummies before a routine gives them a new value,
> whereas the standard clearly requires this).
I think you are refering of the behaviour exposed by ALLOC26.f in
http://ftp.cac.psu.edu/pub/ger/fortran/test/.
NAGWare f95 4.1, which supports the updated technical report, passes
that test (see http://www.nag.co.uk/nagware/NP/NP41_announcement.asp).
>
> > Hopefully, more compilers will support that extension in the near
> > future.
>
> Yes. Because then we can show the C++ fans how simple good memory
> management can be. In C++ you need to write a class with constructor,
> destructor, copy constructor, explicit "deep copy" assignment, all
> spelled out in detail. But in f2k, a derived type with allocatable
> components automatically has all those things.
>
I am not convinced that comparing C++ and Fortran is a very interesting
exercise. Anyway, the real improvement with ALLOCATABLE components
is the ability the optimize the code much more than with POINTER.
I posted a while ago some code that shows that there are still some
compilers
that generate systematically temporaries when POINTER arrays are passed
as
assumed size arguments. As allocatable arrays are contiguous, this
behaviour
won't happen.
> Then again, C++ works, and f2k doesn't exist (yet).
TR 15580 (http://www.nag.co.uk/nagware/NP/doc/TR.html) was published
two years ago.
Regards,
Arnaud
Jos Bergervoet
>> ...
>> Although NAG and F have a bug (they don't free the memory in
>
> NAGWare f95 4.1, which supports the updated technical report, passes
> that test (see http://www.nag.co.uk/nagware/NP/NP41_announcement.asp).
Oops! I was not referring to the latest version (but to the version
on which the latest F is based, which is 4.0a). My fault, of course,
and comparable, albeit less excessive, to the "Treurich et al. style"
of comparing f77 with modern C++.
> I am not convinced that comparing C++ and Fortran is a very interesting
> exercise.
Maybe not, but that was the topic (in Treurichs article as well as in
the various rebuttals by Vivek Rao, Mike Metcalf, Moene & Nagle, and
maybe others as well).
> ... Anyway, the real improvement with ALLOCATABLE components
> is the ability the optimize the code much more than with POINTER.
I don't see why that should be the "real" improvement. I think the
possibilities for memory management are a big improvement. Think
about the ISO_varying_string module. It just CANNOT be implemented
in f95 without memory leaks! Some may see this as an indication that
the language (f95) is simple broken (by todays standards of what a
language should be capable of). Allocatable components nicely remedy
this embarrassing situation (and much more cleanly than the C++ way).
Of course we know that varying strings are not that important, but
similar problems (i.e. data blocks of varying size) often play a
role in the memory management in numerical codes.
I think allocatable components, together with the rules for fail-safe
automatic deallocation as required by TR 15580, are a much greater
invention than most people realize. (Actually, "most people" won't
even know what allocatable components are, but that proves my point :-)
-- Jos