On Sunday 11 September 2005 03:39, Anders Johansson wrote:

On Saturday 10 September 2005 17:47, Jerry Feldman wrote:

...

Just to add to Anders comments. According to the ANSI 89 standard, this is an unspecified operation. The issue here is when the postincrement operator is applied to s. C pushes variables from the last to the first because it may have an unknown number of parameters.

This is a completely unwarranted assumption. This may be the way any one compiler works (and it does make sense), but according to 6.5.2.2 of the 1999 standard

"The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call"

So while I'm sure you're right about any one compiler, it is very wrong to say that C does it, and suicidal to rely on it

I agree; you need to look at your own compilerS. I add the S because linking object code from two different languages can get one into a lot of trouble if they don't obey the same rules. Also one should note that some compilers pass addresses (best in my opinion) while others pass "values". (Values? C passes values sometimes and addresses if it feels like it, so be careful.) And some compilers pass 'hidden' information. So: Why in hell would anybody want to pass something as dumb as s++ ? Us old farts use K.I.S.S. Regards, Colin

Colin,

On Saturday 10 September 2005 18:38, Colin Carter wrote:

...

...

...

So while I'm sure you're right about any one compiler, it is very wrong to say that C does it, and suicidal to rely on it

I agree; you need to look at your own compilerS.

Wrong. You need to code to the standard so your code is immune to changes in the compiler or the environment in which it is to be run. Randall, You cannot always code to 'the standard'. For example, FORTRAN (a very well established language) had a standard of

On Sunday 11 September 2005 12:09, Randall R Schulz wrote: pushing the first argument first, and always by address - simple idea. The other languages followed suit. Then came C For other languages to mix it with C the compilers had to have 'fiddles' inserted into the compilers. e.g. C TYPE routine call Eventually FORTRAN changed its standards to try to assist with compatability. Which means that old FORTRAN code would no execute. And as for ME being 'non-standard', I would like to point out that I developed a very large program over four years of work, on a PC. Then mailed it (yes, we had 'email' years ago) to a reduced instruction set VAX mainframe and it worked the first run. (Code still took 6 hours to execute.)

...

I add the S because linking object code from two different languages can get one into a lot of trouble if they don't obey the same rules. Also one should note that some compilers pass addresses (best in my opinion) while others pass "values". (Values? C passes values sometimes and addresses if it feels like it, so be careful.)

You have got to be kidding. The language is quite clear about the distinctions between values, pointers and references and which is used when and while there are many areas where the compiler (writer) has discretion about its exact behavior, there's no such discretion (no "feels like it") when it comes to parameter passing and whether values, pointers or references are what's passed. That's a big part of what strong typing is about, after all.

You know, you use jargon like "typing", as thought it is a new idea. Us old guys just considered it an intrinsic part of the process; much like we structured our code years before the academics invented the word "structured design" to prevent kids from making spaghetti code. (Twit the language PASCAL, at first without a goto.)

While no language can be used without understanding, C and C++ are more demanding than most in their subtleties. So be it.

I suggest that you replace the word 'demanding' with 'complicated and messy'.

...

...

Colin

Randall Schulz

Colin

On Sunday 11 September 2005 23:40, Jerry Feldman wrote:

On Sun, 11 Sep 2005 17:26:28 +1000

Colin Carter wrote:

...

And as for ME being 'non-standard', I would like to point out that I developed a very large program over four years of work, on a PC. Then mailed it (yes, we had 'email' years ago) to a reduced instruction set VAX mainframe and it worked the first run. (Code still took 6 hours to execute.)

VAX-C or DEC-C? In my experience I have been dealing with a number of different platforms (and 32-bit to 64-bit and big-endian to little-endian) for years. I always recommend trying to code to the standards, but there are cases where it is not possible. FORTRAN :-) VAX I think, but it was ten years ago, so I can't remember for sure. Good night, Regards, Colin

Colin, On Sunday 11 September 2005 00:26, Colin Carter wrote:

On Sunday 11 September 2005 12:09, Randall R Schulz wrote:

...

Colin,

...

Wrong. You need to code to the standard so your code is immune to changes in the compiler or the environment in which it is to be run.

Randall, You cannot always code to 'the standard'.

Sorry, but again you're wrong. You may have to work around compiler problems and idiosyncracies (more so in the past than now, but still an issue), but that's the exception and one of the reasons conditional compilation is necessary in C/C++.

For example, FORTRAN (a very well established language) had a standard of pushing the first argument first, and always by address - simple idea. The other languages followed suit.

If you're going to keep thinking in language implementation terms instead of in terms of the abstractions in which the language is defined, you're going to remain confused.

Then came C For other languages to mix it with C the compilers had to have 'fiddles' inserted into the compilers. e.g. C TYPE routine call Eventually FORTRAN changed its standards to try to assist with compatability. Which means that old FORTRAN code would no execute.

"Fiddles?" You really seem to think that compilers (or their writers) are capricious. Besides, I don't think we're talking about FORTRAN here.

And as for ME being 'non-standard', I would like to point out that I developed a very large program over four years of work, on a PC. Then mailed it (yes, we had 'email' years ago) to a reduced instruction set VAX mainframe and it worked the first run. (Code still took 6 hours to execute.)

I don't know what ME is. And drop the "older than thou" routine. Not everyone here is newbie.

...

...

...

You have got to be kidding. The language is quite clear about the distinctions between values, pointers and references and which is used when and while there are many areas where the compiler (writer) has discretion about its exact behavior, there's no such discretion (no "feels like it") when it comes to parameter passing and whether values, pointers or references are what's passed. That's a big part of what strong typing is about, after all.

You know, you use jargon like "typing", as thought it is a new idea. Us old guys just considered it an intrinsic part of the process; much like we structured our code years before the academics invented the word "structured design" to prevent kids from making spaghetti code. (Twit the language PASCAL, at first without a goto.)

You don't even know who you're talking to. And you clearly don't know what you're talking about.

...

While no language can be used without understanding, C and C++ are more demanding than most in their subtleties. So be it.

I suggest that you replace the word 'demanding' with 'complicated and messy'.

So be it. If you can't handle it, choose a different language.

Colin

Randall Schulz

On Sat, 10 Sep 2005 19:09:52 -0700 Randall R Schulz wrote:

While no language can be used without understanding, C and C++ are more demanding than most in their subtleties. So be it. Very true. This is because C was designed as an implementation language not a high level language. It gives the programmer much more power than most high level languages. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Sunday 11 September 2005 12:25, Anders Johansson wrote:

On Sunday 11 September 2005 03:38, Colin Carter wrote:

...

On Sunday 11 September 2005 03:39, Anders Johansson wrote:

...

On Saturday 10 September 2005 17:47, Jerry Feldman wrote:

...

Just to add to Anders comments. According to the ANSI 89 standard, this is an unspecified operation. The issue here is when the postincrement operator is applied to s. C pushes variables from the last to the first because it may have an unknown number of parameters.

This is a completely unwarranted assumption. This may be the way any one compiler works (and it does make sense), but according to 6.5.2.2 of the 1999 standard

"The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call"

So while I'm sure you're right about any one compiler, it is very wrong to say that C does it, and suicidal to rely on it

I agree; you need to look at your own compilerS.

That's not what I said (or at least not what I meant :)

You need to look at your own code, and make sure you only code according to standards.

...

(Values? C passes values sometimes and addresses if it feels like it, so be careful.)

Parameters in C are always passed by value. If you want to have call by reference, you need to do that explicitly, by passing a pointer (in which case it's still call by value, since you're passing the value of the pointer)

The exception is when you have an array or function as parameter, in which case the pointer to it is passed, but this is well defined, not willy nilly

How about structures, character strings? See: a sometimes thing.

The relevant sections are 6.5.2.2 and 6.7.5.3 in the 1999 standard

...

So: Why in hell would anybody want to pass something as dumb as s++ ?

Well, it's not s++ that's passed, it's s. Having 's++' in the parameter list is just telling the compiler that s is to be incremented by one immediately after its value has been used in the function call. This can be useful as a hint to the compiler, so it can increment s while it's still held in a register. If you have s=s+1; on the next line, a clever compiler might still be able to detect it and rearrange things, but with the postfix notation it's much easier. Especially in tight inner loops, small tricks like this can have noticeable payoffs

Sorry, but I don't agree. Writing 'clever' code is confusing to the reader. Whereas a good compiler (eg FORTRAN) will improve code significantly better than most coders. For example J = J + 1 has been compiled as inc J for many years now, and FORTRAN has, for around thirty years, compiled 'do loops' ( K = 1 to 100) as load registers (minus 1) and decrement the counter from 99 to -1 in registers. A good FORTRAN compiler looks ahead and starts computing code in advance of the time the previous values will be required. That is, it can see things "coming up", and many lines of code will be computed out of sequence. Fancy code just inhibits optimisation. But you might already know this. :-) Regards, Colin

On Sunday 11 September 2005 13:27, Anders Johansson wrote:

then it is much easier for the compiler to generate the "good" code that increments x while it's still held in memory

argh. Still held in a register, I meant

Hi Anders, I will basically agree with you; I don't think that we disagree really, just being a little pedantic about trivia. And it is now 1 am here, so I must hit the sack. Good night. Regards, Colin PS: Out of interest, and respect for you, I will have a look at your code. On Sunday 11 September 2005 21:27, Anders Johansson wrote:

On Sunday 11 September 2005 09:45, Colin Carter wrote:

...

...

Parameters in C are always passed by value. If you want to have call by reference, you need to do that explicitly, by passing a pointer (in which case it's still call by value, since you're passing the value of the pointer)

The exception is when you have an array or function as parameter, in which case the pointer to it is passed, but this is well defined, not willy nilly

How about structures, character strings? See: a sometimes thing.

A character string isn't a separate type, it is an array, so that is covered by the above exception.

Structures are passed by value

Try running the following example program

#include

struct a{ int a; long b; unsigned c; };

void func(struct a var){ printf("The address of var is %p\n", &var); }

int main(void){ struct a var2;

printf("The address of var2 is %p\n",&var2); func(var2);

return 0; }

...

Sorry, but I don't agree. Writing 'clever' code is confusing to the reader. Whereas a good compiler (eg FORTRAN) will improve code significantly better than most coders. For example J = J + 1 has been compiled as inc J for many years now, and FORTRAN has, for around thirty years, compiled 'do loops' ( K = 1 to 100) as load registers (minus 1) and decrement the counter from 99 to -1 in registers. A good FORTRAN compiler looks ahead and starts computing code in advance of the time the previous values will be required. That is, it can see things "coming up", and many lines of code will be computed out of sequence.

Fancy code just inhibits optimisation.

Well, I didn't mean to imply that there was a real difference between x++ and x=x+1, I'm sure there isn't a compiler out there that won't translate both to the same machine instruction. But the question is when they do it.

If you have a construct like

foo(x); x++;

Then before the second line there is a whole function call to consider, and the compiler may or may not be aware of the increment, so it is entirely conceivable that it generates code that calls the function, and on return reloads x from memory to increment it. If on the other hand you had made it

foo(x++);

then it is much easier for the compiler to generate the "good" code that increments x while it's still held in memory, saving one or two instructions along the way. Now, I'm not saying there aren't compilers that see the two as equivalent, I'm sure many, perhaps even most do. But you can't be sure, and that is one reason I use constructs like that. Another is that it's more compact and, to my eyes, elegant to use the *fix notation. I don't think it's *that* much more difficult to read

Colin Carter [11 Sep 2005 17:45:16 +1000]:

Whereas a good compiler (eg FORTRAN) will improve code significantly better than most coders.

Any modern compiler, no matter if it's FORTRAN,C,C++,Pascal or any other language, will optimize far better than most coders.

Fancy code just inhibits optimisation.

No, there are places where fancy code is necessary. Philipp

On Friday 16 September 2005 13:53, Jerry Feldman wrote:

I fully agree that there are places where fancy code may be necessary, but in many cases, fancy code does inhibit optimization, especially in C.

I think we need some sort of sane definition of the word "fancy" though. The obfuscated C code competition I would definitely agree with, I'm surprised most of that stuff compiles at all :) But I wouldn't include x++ in that definition

On Friday 16 September 2005 20:19, Jerry Feldman wrote:

For instance the following code fragment is standards compliant but non-portable: long n; int i = -2; unsigned k = 1; n = i + k;

sign extensions in promotions is something they really should have standardised by now. They haven't even standardised on the binary representation of negative numbers, so yes, it's another thing that's suicidal to rely on

On Saturday 17 September 2005 16:33, Synthetic Cartoonz wrote:

On Saturday 17 September 2005 09:00, Anders Johansson wrote:

...

On Friday 16 September 2005 20:19, Jerry Feldman wrote:

...

For instance the following code fragment is standards compliant but non-portable: long n; int i = -2; unsigned k = 1; n = i + k;

sign extensions in promotions is something they really should have standardised by now. They haven't even standardised on the binary representation of negative numbers, [...]

Should a high level language be dictating to CPU manufacturers how processors must internally represents values?

1. It already dictates that it must be binary 2. There is really no dictate about the representation. All the standards say it must behave *as if* this is how it's done. A good example is the standard include files, like stdio.h. The standard doesn't dictate that they must be present as regular files, it just dictates that if you have #include in your program, a certain set of definitions will be assumed to be present, but this can be entirely internal to the compiler if this is deemed to be optimal. Another example is the preprocessor. So just as it is possible to have a strictly conforming implementation on a tertiary machine (where the compiler translates between the binary representation guaranteed by C to the tertiary representation of the hardware), it would be possible to say a negative number should be stored in two's complement with sign extension behaving in a certain way. Just let the compiler hide the gory details

On Fri, 16 Sep 2005 20:04:29 +0200 Anders Johansson wrote:

But I wouldn't include x++ in that definition The pre-increment/post-increment (and decrement) operators are not fancy code in C, they are an integral part of the language, but they are often misused.

I also do not consider this fancy code: int c; while( (c = getchar()) != EOF) { ... } Note that I generally try to compare vs. NULL or 0, for example: 'if (p == NULL)' rather than 'if (!p)' Both are correct in C, but the second is less readable. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Saturday 17 September 2005 08:48, Jerry Feldman wrote:

On Fri, 16 Sep 2005 20:04:29 +0200

Anders Johansson wrote:

...

But I wouldn't include x++ in that definition

The pre-increment/post-increment (and decrement) operators are not fancy code in C, they are an integral part of the language, but they are often misused.

I also do not consider this fancy code: int c; while( (c = getchar()) != EOF) { ... }

Note that I generally try to compare vs. NULL or 0, for example: 'if (p == NULL)'

Ouch. I've had to fix the typo'd version for this too many times: if ( p = NULL ) Syntactically permitted, but definitely not what is intended. If you have warnings turned off this is an invisible error until you run your program and it crashes. If you must do extra typing try this instead: if ( NULL == p ) The typo for this is an invalid assignment and will result in an error, not a warning at compile time.

rather than 'if (!p)' Both are correct in C, but the second is less readable.

I find this second version perfectly understandable, but I've been doing C for about 20 years.

On Saturday 10 September 2005 17:47, Jerry Feldman wrote:

...

Just to add to Anders comments. According to the ANSI 89 standard, this is an unspecified operation. The issue here is when the postincrement operator is applied to s. C pushes variables from the last to the first because it may have an unknown number of parameters.

This is a completely unwarranted assumption. This may be the way any one compiler works (and it does make sense), but according to 6.5.2.2 of the 1999 standard

"The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call"

So while I'm sure you're right about any one compiler, it is very wrong to say that C does it, and suicidal to rely on it This may have came across wrong. What I was describing the behavior exhibited by gcc on x86-32. GCC is certainly free to make any changes it wants as long as it is complient. (My copy of ISO 99 was at work). One should also note that I used the term "C pushes". On the x86 series, parameters are pushed on the stack. On other processors, such as Alpha, PA-RISC, IA64, some parameters are placed into registers and not pushed. This would cause the compiler to apply the

On Sat, 10 Sep 2005 19:39:53 +0200 Anders Johansson wrote: postincrement and postdecrement in a different order. There is a specific order in which the variables are pushed (or placed into registers), but the order in which their values are evaluated is unspecified. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9