i love comma expressions

[menchar]

You just have to love a language that lets this happen:

iReturnVal = func1 (param1), param2, param3;

[dummy_decoy]

this calls for a debugging nightmare...

but it may be useful this way:

double array[length];

int index;

double *ptr;

ptr = array;

for ( index = 0; index < length; index++, ptr++ ) // note the comma in the last expression

{

    // here you have the value of the index, and also a pointer to the element.

    // for non-optimizing compiler, it makes a difference, and the syntax is easy to read

}

more useful with its variation:

for ( index = length - 1; index >= 0; index--, ptr++ )

{

    // now you have a pointer to an element, and the inverse of its index

}

if you love that, you will love C++ which lets you overload the comma operator: you can give your own meaning to the comma applied to an object...now any people reading your code have to be very careful, because if they do not notice the overload, they will never understand how your code is working.

[Guillaume Dargaud]

I also sometimes use it to save a bit on curly braces, as in:

if (a<0) Func(), OtherFunc(), ThirdFunc();

But I agree, it can be surprising to read.
--
Guillaume Dargaud
http://www.gdargaud.net/

[dummy_decoy]

if your manager is evaluating your productivity by how much lines of code you write to implement a feature, then this is the way to go. trust me, some managers really think that if you write less code you are more productive.note that those same managers tends to count the lines by the number of CR/LF they find in your sources, including spacing blank lines, comments, lines containing only braces, etc.

some people working with this type of managers developped a bad habit of badly formatting code. this bad habit later turned into an art, which gave birth to a contest: The International Obfuscated C Code Contest.

[menchar]

Well, if you accomplish the same task with fewer lines of code than someone else, to some extent you might think it's more efficient code.  But almost any metric based on LOC is vulnerable to error.  Most of the source line counting tools can't detect redundant code for example - i.e. code that's been cut and pasted, dead code, automatically generated code, etc.  And it speaks nothing to the issue of reliability, maintainability, readability, etc.

And if you counted added comments and structuring code that promotes reuse, then you might say you have  taken longer to solve the problem but it's way better code and in fact more efficient in the longer term when you consider mainenance and re-use.

I claim that if you disclose the metric ahead of time I can write for goodness against that metric that will have little bearing on whether it is good code or not 😉

Capers Jones said that comparing LOC between languages is professional malpractice 😉

The use of the coma is a well known C non-orthogonality that causes problems.

It's fun to show a new developer how you can cut and paste random snippets of code almost anywhere in a C module and it will compile and build.  The statement I started this thread with was a cut and paste error.

[dummy_decoy]

i suppose it should have been:

iReturnVal = func1 (param1, param2, param3 );

then the compiler should have screamed about an incorrect use of the function (missing parameter). why didn't it notice the error ?

maybe because the function declaration is using another bad construct from C: variable parameters.

the biggest problem with C is that its syntax makes it hard to automatically verify what you write.

[menchar]

func1 was    <some type> func1 (<some type> param1);

param2 and param3 existed and were in scope and visible so the compiler found no errors, thinking it was a comma expression, which is relatively rarely used, if for no other reason than it's so hard to read.  IMHO I think using it to evaluate muiltiple expressions in a for statement (as someone mentioned above) is OK.

Yup, almost anything is an expression and expressions can appear almost anywhere in a C module.

The paradigm is trust the programmer because you can't trust the compiler.

The obscure C contest is really wild - the best ones are amazing.    Just when you think you understand a language ...