Prev: calling a recursive function in fortran 77 ?
Next: equivalent in fortran of the IDL "where" function
From: robert.corbett on 31 Mar 2010 22:30 On Mar 31, 9:08 am, Jim Xia <jim...(a)hotmail.com> wrote: > > I would be very interested in knowing if there is a Fortran > > implementation that does not provide the function LOC. LOC > > is so commonly used, I would think an implementation that > > did not provide it would not be viable. > > > Bob Corbett > > Your example (with LOC) doesn't compile with XLF. Just let you know > there are compilers think differently from yours :-) > > Cheers, > > Jim Do you mean it does not compile or that it does not link? Bob Corbett
From: David Thompson on 7 Apr 2010 01:02
On Thu, 25 Mar 2010 23:12:18 +0000 (UTC), glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > C only allows subtraction of pointers to different parts of the > same object, such as different elements of an array. That removes To be exact, the C standard only requires pointer subtraction within an array, but any (single) object (such as a struct) can be treated as an array of characters, and thus pointers within that object cast to character pointers subtracted. The standard leaves subtraction of pointers to/into different objects undefined: it does not require a diagnostic, the implementation can do what it chooses, and on current machines where subtraction of the machine addresses works fine that's what a sane C implementor does. > some of the cases where this can fail. C also allows different > representation for pointers to different types. If I understand > it right, Fortran doesn't allow for that one. For example, Well, *Fortran* POINTERs can certainly be type-dependent; they pretty much have to be at least rank-dependent. You presumably mean Fortran C_PTR's, which do further constrain the C implementation to use homogenous pointers (note 15.10 in the draft I have to hand). > character pointers on word addressed machines might use other > bits to indicate the position in a word. I believe that C also > doesn't guarantee that there is such an integer type, but only says > what happens if there is such a type. It could be especially Namely the intptr_t and uintptr_t types, which if they exist must be capable of losslessly preserving all data pointer values. Correct. > interesting in the case of 32 bit far model IA32 code, where > pointers are 48 bits. (16 bit segment selector, 32 bit offset.) > If there is no corresponding C type, then asking for the C sizeof > something doesn't make so much sense. There are some C cases > that I wonder about. In C, character constants, such as 'x', have > type int, and so sizeof('x')==sizeof(int). (As I understand it, > that isn't true in C++.) Enumeration constants also have sizeof(int), > though the appropriate variable can have a different size. C doesn't More exactly, in C both characters 'x' and enum constants have the specific type int, just like 123; in C++ they have type char or enum type respectively. sizeof(char) is always 1 and *typically* less than sizeof(int), but there are systems with sizeof(int)=1=sizeof(char). sizeof(enum x) is *typically* the same as sizeof(int) but it may be different at the compiler's choice; except in C++ which allows enum constants to be outside (range of) int but within long in which case *that* enum type (at least) must be wider than int. > allow pointers to constants, which avoids some problems that would > otherwise appear in those two cases. > C99 adds compound literals, which are intended mainly for aggregates (arrays and structs) but can be used degenerately for e.g. simple number as well. But a compound literal explicitly creates an object, initialized by the constant(s) (or if nonstatic in a function, optionally nonconstant(s)), which can be pointed to. Similarly C string constants like "this" have since always actually meant an array of char *object* initialized to the string's value, which like any array in C is actually passed and used as a pointer. |