****ing Fortran

[KrazyHorse]

The quintessence is, you just don't do stuff like this. You don't pass a constant (like 7 in the second example) to a function and then try to write another value over it.

You should be able to. If the function recognizes a call by value (as it does) then you should be able to use the named variable in the function declaration as a local variable inside the function. There's no reason not to be able to.

[Harovan]

Originally posted by KrazyHorse

You forgot to assign the return value of the function. You should have added the line

Doesn't make a difference

Does it make a difference if you assign the return value and don't pass a constant as parameter (and try to overwrite it in the function, thus causing a segfault)?

I'm not very sure what your code is supposed to do, though. What value is I supposed to contain in the end?

[KrazyHorse]

It still causes segfault if you properly assign return value.

The reason my code does not properly assign return value is that this is just a simple example. I deleted all the parts which were not relevant.

I didn't think you would want to read through 50 lines of common block declarations and 1000 lines of some fairly abtruse physics thinking in order to see the problem.

That's also the reason the code doesn't do anything useful in its current form.

[Harovan]

Originally posted by KrazyHorse

The quintessence is, you just don't do stuff like this. You don't pass a constant (like 7 in the second example) to a function and then try to write another value over it.

You should be able to. If the function recognizes a call by value (as it does) then you should be able to use the named variable in the function declaration as a local variable inside the function. There's no reason not to be able to.

Stuff like this is compiler dependant. You never know where they put temporary variables. You can't even call this a bug. You're always fine as long as you don't try to pass a constant on the place of a variable.

Well, a variable is called a variable, because its content may vary. And a constant is called a constant... you get my point. And 7 is a constant (and hence r/o by definition), while ISTART is a variable (and thus r/w).

[KrazyHorse]

Yeah, I get it, but it doesn't seem smart to write the compiler that way.

From what I recall I can do that all day long in C and not have any troubles.

[Harovan]

C is different. In C (by language definition) parameters are always treated as local (r/w) variables. If you pass a constant, it's value is copied on the parameter stack, i.e. it contains the direct value 7 and not the address of an external variable containing 7, like obviously FORTRAN does.

You can write this in C:

main() {
int i = func(7);
return 0;
}

int func(int x)
{
x = 5;
return 2;
}

No problem and no segfault, because 7 is put on the stack. It is overwritten in func(), but the result is lost as the parameter stack is discarded on function return.

After the function, i contains 2.

FORTRAN does not have this "copying" habit, obviously.

[KrazyHorse]

See, you've lost me. I have no idea what a stack is.

Nor do I particularly want to know. All I know is that FORTRAN sucks.

SUUUUUUUCCCCCCKKKKKKS

[Harovan]

By the way, call by value works fine and dandy as long as you use the value (for instance as function parameter) and not the address that contains the value as sort of obscure return value pointer.

[Harovan]

A stack is just a chunk of memory, where programs write down temporary values and return addresses. It is worked by a special CPU register, the stack pointer (ESP on Intel-32 architecture).

For instance, if you call a function, the compiler decrements ESP by 4 (the size of an address in bytes) and then writes the return address on the place where ESP points. When the function returns, it just jumps on the place where ESP points and, doing this, increments ESP by 4, so it has exactly the same value as before the function calls. This is very important, as if you don't unwind the stuff you put on the stack before the function returns, it'll jump not to the return address, but to the content of some variable (like 7 ), resulting in a nice crash.

[Harovan]

Originally posted by KrazyHorse
Nor do I particularly want to know. All I know is that FORTRAN sucks.

SUUUUUUUCCCCCCKKKKKKS

I sign that not hesitating. I haven't used it since the mid 80's. And I hated F77 (always used Fortran IV and the nice three way IF).

Third post in a row... and they actually count, too.

Good night!

[Asher]

Originally posted by KrazyHorse
Yeah, I get it, but it doesn't seem smart to write the compiler that way.

I'm also pretty sure it violates ISO standards, but I've misplaced my Fortran PDF...

[Asher]

Originally posted by KrazyHorse
See, you've lost me. I have no idea what a stack is.

[Harovan]

Good picture. Now imagine the plates are the stack, and the left thumb the stack pointer. If you call a function, its return address is put on the plate where the thumb points, and the thumb slides one down... (etc.)

[LDiCesare]

Damnit. I aftually read every post.
FORTRAN is decidedly a despicable language but I think I can understand why it's fast when I read the generated assembly. Using the data segment directly is certainly more efficient than the corresponding C code, but segfaults and bugs are so much more common than in C (which is not the most robust language itself).

[Harovan]

The corresponding C code would not be less efficient, given similar compiler settings (optimization). The most remarkable difference would be, that in C (at least with the default "cdecl" calling convention) the direct value 7 is passed on the stack, while in this Fortran version a pointer to a memory location containing 7 is passed there. In terms of performance that makes no difference, both (direct value and address) are numbers, and of the same width too.

Plain C is certainly not perfect, but for a good and careful programmer it is a mighty tool, as he has control over practically everything. C++, if properly used, produces safer and better readable code at the cost of a bit performance (the overhead is slightly greater). Yet more "comfortable" languages like C#, Java et al. (I call them languages for the lazy) give up a yet greater deal of performance and control in exchange for yet more safety and comfort.

In the end it matters what your program is supposed to do. If you write a GUI (lots of graphics, little or no performance issues), the usage of C would be quite painful. C++ and a good class library would be better, but best would be C# or Java. If you write compact and fast code without a big interface (like firmware or embedded applications), C++ should be the best tool, perhaps even plain C. If you do OS core programming, you usually deal with a stripped down version (no full featured library) of C.