C vs. Fortran (half OT questions)
in [Fortran]
|
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: Vincenzo Mercuri on 12 Aug 2010 02:32 glen herrmannsfeldt wrote: >> 3 -- what about the Standard IEEE 754 (IEC 60559:1989) conformance? >> is that intrinsecal to the language or the implementation? >> which language can offer a full support to the IEEE Standard, >> C or Fortran? > > IEEE 754 (why 1989 and not 2008?) is not intrinsic to either, > and likely neither offers full support. Fortran 2003 includes > a module and many intrinsic functions, and those help write > conforming code. Though not standard, many of the IEEE 754 features > were available in C earlier than in Fortran. Actually the reason not to mention the 2008 Standard is that it is too recent. If I think about C99 compliance of even the most widely used C compilers I think it will take long for IEEE 2008 to be supported. >> 4 -- what about performance? would you bet on C or Fortran? :-) > > I wouldn't bet. If you are careful in writing the appropriate > low-level code in C, it can often be faster than Fortran. > If you are not so careful, a good optimizing Fortran compiler > might generate faster code, or it might not. [...] I asked because it is such a temptation to keep using the same programming language. But actually, the answer lies in the reasons why and the contexts where the 2 languages were born. Fortran for numeric computation and C for system programming (and some more abstract programming paradigm). Thank you. -- Vincenzo Mercuri
From: Nick Maclaren on 12 Aug 2010 04:15 In article <dc8cf9de-1ef4-445d-b9bf-14a214614eaa(a)i19g2000pro.googlegroups.com>, steve <kargls(a)comcast.net> wrote: >> >> >Note, the only item marked broken for the compiler is >> >near and dear to your heart. >> >> You have got that spectacularly wrong! =A0I thought that I had made >> it clear that I regarded the IEEE 754 support as demented. > >I suppose I should have used a 'smiley' to denote sarcasm. >Yes, I'm well aware of your views concerning ieee754. Sorry - I shouldn't have posted when half asleep! Regards, Nick.
From: Nick Maclaren on 12 Aug 2010 04:26 This is getting very off-group, so I shall stop here. In article <slrni673rj.f7m.foo(a)vipunen.hut.fi>, JB <foo(a)bar.invalid> wrote: > >Well, gcc can be used with other C libraries than glibc. glibc is used >only on Linux, AFAICT. Just don't expect the combination to work! "glibc" should probably read "a supported library, primarily gcc". >That being said, you're right, and this split >only on Linux, AFAICT. That being said, you're right, and this split >has caused some problems in the past (an obvious one in the context of >this discussion being that the level of C99 support is different on >targets using different C libraries), and IMHO it would make sense if >the C standard library would be part of gcc, and then glibc could be >more like some "libposix" are whatever one might call it. But, >anyways, that's not how things are done in reality, largely for >historical reasons I suppose. No, but it's NOT separated into the library, either. Fortran still has a sharper distinction between the language and the intrinsics, but Fortran 90 stopped regarding them as distinct, and I know of no modern compiler/library combinations that can be split. >> I will try to remember what the issue was where C99 was incompatible >> with gcc, and there was a definite intent to maintain compatibility >> at the expense of C99, and check what has happened to it. But it's >> a long time ago now, and I may not be able to. > >The only thing I can recall right away is that there was an >incompatibility with the C99 "inline" and the GCC extension >"inline". IIRC something like the GCC "extern inline" meant the same >thing as just "inline" in C99, and vice versa. But, this issue was >fixed a few years ago, and GCC nowadays by default follows the C99 >semantics. I remember something to do with the scope of variable length arrays, but that MIGHT be something that could be swept under the carpet as a quality of implementation issue. Regards, Nick Maclaren.
From: Vincenzo Mercuri on 13 Aug 2010 03:42 teg ha scritto: > Den Tue, 10 Aug 2010 18:26:35 +0200 skrev Vincenzo Mercuri: > >> 1 -- is there any reason not to learn Fortran (a new language for me) >> and focus on C (and C numerical libraries) potentialities? > > Learn both and learn how to call Fortran from C and C from Fortran. yes, that's the point indeed. >> 2 -- is Fortran considered the best choice in this field only because >> of its construct and syntax that makes easier to handle >> mathematical entities? > > No, mostly because the code (and I mean Fortran77) is prettier :) ....in performing matrix calculations you are definitely right! I still need the power of C in system programming though. >> 4 -- what about performance? would you bet on C or Fortran? :-) >> > > Same. For real performance critical applications you want handcoded > assembly libraries. true...but 'handcoding assembly libraries' sounds a little scary :-) -- Vincenzo Mercuri
From: Vincenzo Mercuri on 13 Aug 2010 04:15
Lynn McGuire ha scritto: > I would use C++ instead C. I would also check on the potential > platforms that you will be developing on or porting to and make > sure that there is a good fortran vendor there. For instance, > the iPhone only supports 4 compilers: Objective C, C++, C and > Java. Any proprietary environments can be very limiting. Thank you. Well, actually I'd like to learn C++ too. But for now, apart from numerical calculations, I just need to do some system programming and I find it easy, I'd say natural, to do it in C. Maybe it would be as easy in C++, but I have (maybe wrongly) a picture in mind of C++ as not so handy for small functions (I'd say procedures in a Fortran context), but more suitable for large projects. -- Vincenzo Mercuri |