An 'interesting' thing you can do in C++

[hamster_nz]

Just when you think you have seen it all...

Code: [Select]

#include <stdio.h>

int main(int argc, char *argv[]) {
  int a=  0, b = 0;

  (argc == 2 ? a : b) += 5;

  printf("%i %i\n",a,b);
  return 0;
}

I guess it could be useful...

Has anybody used/found a use for this?

[IanB]

What am I looking at? Is there something to see here?

[hamster_nz]

What am I looking at? Is there something to see here?

Code: [Select]

  (argc == 2 ? a : b) += 5;

You can use the '?' operator, to select one of two different variables to be the target of the assignment.

[ejeffrey]

The point is I guess that the result of ?: can be an lvalue assuming arguments 2 and 3 are.

This is only allowed in C++, not C.  I'm not sure what motivation, if any, lead to the change.

[hamster_nz]

The point is I guess that the result of ?: can be an lvalue assuming arguments 2 and 3 are.

This is only allowed in C++, not C.  I'm not sure what motivation, if any, lead to the change.

My guess of the motivation is : "It's not feature complete, until it is Turing Complete"

[boffin]

And it's single lines of code like that, that make it damn near impossible to debug.  When you go back two years later, it's not obvious what is happening

[westfw]

I find the "creeping featurism" of C++ to be ... alarming.
Already, the Open Source programs you can find look nothing like the basic C++ that one learns in school, and frequently they don't look much like each other, either.   And they keep going "no wait!   There's a weird punctuation character we haven't used yet, George at U of X wants it, and it allows programmers to avoid doing an  obscure thing bt doing this MORE OBSCURE thing instead!"
No wonder so many people stick with C.

[Berni]

Oh wow, had no idea you could do that.

But how useful it is? Im not so sure. It does condense down what would otherwise be an IF statement down into just one line, but its also kinda hard to read. Higher level compilers are made for the purpose of making code easier to read so i guess this is a bad feature to add.

Then again its probably getting hard to come up with new features ideas for C since all the great features have already been put in there (Features that are in the spirit of C being close to the hardware that is)

[TomS_]

And it's single lines of code like that, that make it damn near impossible to debug.  When you go back two years later, it's not obvious what is happening

This ^^

Have a read of the MISRA C spec. Sometimes I joke that it should be called MISRAble because its quite restrictive sometimes, but having been bitten by some of the very things it tries to protect against in my own personal projects, Ive taken some of it on board.

e.g. I used to think it was nifty not having to wrap single statements following if or loop statements in braces, but then a couple of times while not really thinking about it I added some extra statements and forgot to add the braces and wondered why it wasnt working, only to spend a while debugging and then realising they werent part of the same block of code. So now I avoid that kind of syntax and use braces even for single statements. I could probably partially blame the fact I write a lot of python for that too (because they were indented to the same level).

When you work as a professional programmer in any kind of capacity, you come to appreciate that readability trumps all, especially when you may have to re-read code months or even years down the line, or you have to read someone elses code, or someone else has to read your code.

[maginnovision]

That's just for consistency. Some of the guys in charge value consistency over... everything else. So this is an example of that. I probably wouldn't use something like that except for a lambda. Even then rarely.

[SparkyFX]

Code: [Select]

  (argc == 2 ? a : b) += 5;

You can use the '?' operator, to select one of two different variables to be the target of the assignment.

I like the question mark operator with colon as a short for an "if" "then" "else" construct replacement, it really speeds up things and makes the code fast to write, and even does enable new ways to write code like the example shown.

And it's single lines of code like that, that make it damn near impossible to debug.  When you go back two years later, it's not obvious what is happening

Relatively understandable for anyone with some Perl knowledge ... not exactly but close.

[nfmax]

So, what do you think would be the values of a and b after the following code runs (assuming all three variables are declared as int)?

Code: [Select]

a = 0;
b = 0;
ptr = 17;
(++ptr == 18 ? a : b ) = ptr--;


[hamster_nz]

So, what do you think would be the values of a and b after the following code runs (assuming all three variables are declared as int)?

Code: [Select]

a = 0;
b = 0;
ptr = 17;
(++ptr == 18 ? a : b ) = ptr--;


Not sure. Would need to test.

Hunch would be that it is evaluated left to right, so a will be 18, b will be zero.

But this is more a problem of the ambiguity of using ++ and -- at the same time as acessing the value of a variable.

foo(++a, ++a, a--) is much the same.

If it was written:

(ptr+1 == 18 ? a : b ) = ptr+1;

or

ptr++;
(ptr == 18 ? a : b ) = ptr;
ptr--;

Then there is no problem.

[SparkyFX]

rewrite to
if (++ptr == 18) { a = ptr-- } else { b = ptr-- };
And you are not any smarter.

It is not as if this stops someone from doing ambigous stuff, just because it is a different way of writing if ... else.

At least i hope i got the topic correct and it is about this operator, not about returning variables for lvalue assignment, which is interesting in itself.

[brucehoult]

And it's single lines of code like that, that make it damn near impossible to debug.  When you go back two years later, it's not obvious what is happening

Why? What's difficult about it?

You've always been able to do the same thing as...

Code: [Select]

*(argc == 2 ? &a : &b) += 5;


[nfmax]

The difficulty arises because it is unclear which of the ptr-modifying expressions is evaluated first - the one in the rvalue or the one in the xvalue. The preincrement/postdecrement complication is just a red herring, intended to distract!

Code should be written to be easy to read and understand!

[taydin]

e.g. I used to think it was nifty not having to wrap single statements following if or loop statements in braces, but then a couple of times while not really thinking about it I added some extra statements and forgot to add the braces and wondered why it wasnt working, only to spend a while debugging and then realising they werent part of the same block of code. So now I avoid that kind of syntax and use braces even for single statements.

I can second this recommendation. Putting in braces even when not necessary helps clearly see the "if" actions and "else" actions and it really helps somebody else (or you, after you haven't looked at it for a while) maintain your code.

Young programmers that are just starting out will often use clever, exotic features of the language in their code, in an attempt to prove that they are intelligent and proficient. But they just end up proving the opposite 

[cgroen]

e.g. I used to think it was nifty not having to wrap single statements following if or loop statements in braces, but then a couple of times while not really thinking about it I added some extra statements and forgot to add the braces and wondered why it wasnt working, only to spend a while debugging and then realising they werent part of the same block of code. So now I avoid that kind of syntax and use braces even for single statements.

I can second this recommendation. Putting in braces even when not necessary helps clearly see the "if" actions and "else" actions and it really helps somebody else (or you, after you haven't looked at it for a while) maintain your code.

Young programmers that are just starting out will often use clever, exotic features of the language in their code, in an attempt to prove that they are intelligent and proficient. But they just end up proving the opposite 

And old programmers will often stick with the old ways and totally ignore the new and better features as they are stuck in "good old times"
PS: I have been a professional developer for 34+ years, so this probably also goes for me in some way 

[nfmax]

You can pull the same sort of stunt in plain old C:

Code: [Select]

#include <stdio.h>

int main(int argc, char** argv) {
int array[] = {0,1,2};
int index = 0;

printf("Before: array = [%d, %d, %d], index = %d\n", array[0], array[1], array[2], index);
array[index++] = index++;

printf("After: array = [%d, %d, %d], index = %d\n", array[0], array[1], array[2], index);
return 0;
}

Which compiles (with a warning) and runs to give:

Code: [Select]

Before: array = [0, 1, 2], index = 0
After: array = [0, 0, 2], index = 2

So the rvalue is expression is evaluated first. However, the warning message is revealing:

Code: [Select]

wotsit.c:8:13: warning: multiple unsequenced modifications to 'index' [-Wunsequenced]
        array[index++] = index++;
                   ^          ~~
1 warning generated.

as it implies this behaviour is not guaranteed.

Don't Do Things Like This!

[GeorgeOfTheJungle]

The point is I guess that the result of ?: can be an lvalue assuming arguments 2 and 3 are.

This is only allowed in C++, not C.  I'm not sure what motivation, if any, lead to the change.

It compiles ~ fine in gcc 4.2/2007

Code: [Select]

#include <stdio.h>

int main (int argc, char *argv[]) {
    int a=  0, b = 0;
    (argc == 2 ? a : b) += 5;
    printf("%i %i\n",a,b);
    return 0;
}

jorge@unibody:~/kk$ gcc --version
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)
Copyright (C) 2007 Free Software Foundation, Inc.

jorge@unibody:~/kk$ gcc kk.c -o kk.out
kk.c: In function ‘main’:
kk.c:5: warning: target of assignment not really an lvalue; this will be a hard error in the future
jorge@unibody:~/kk$ ./kk.out
0 5
jorge@unibody:~/kk$ ./kk.out 1
5 0
jorge@unibody:~/kk$

[grumpydoc]

This is only allowed in C++, not C.  I'm not sure what motivation, if any, lead to the change.

No but in C one can write *(argc == 2 ? &a : &b) += 5;

If you really want

Yes I have done this, but I'm not proud of it (outside of intentionally obfuscated code).

[GeorgeOfTheJungle]

Young programmers often ignore the reason why things are the way they are... and tend to use tabs instead of spaces  and put blocks in ifs and loops when there's no need  because a comma operator would do  but they just don't know it 

Code: [Select]

while (young) make(), mistakes();

[rstofer]

I must be getting old!  Not only do I not know what some of these constructs will do, I don't even want to know.  I would never write something like that!  I really don't like 'clever' code.

I'm of the opinion that I should write code as clearly as possible and let the compiler worry about optimization.

[GeorgeOfTheJungle]

No but in C one can write *(argc == 2 ? &a : &b) += 5;

Yep. That's clear and unambiguous and compiles without warnings. C++ is obscure, a mine field. Sometimes I wonder if Stroustrup eats mushrooms.

[dferyance]

In my experience young programmers don't make mistakes. They pip or npm install 1000 random packages in python or node hoping that some of them will do what they need. Glue together other people's work; writing code is so retro!

On a more serious note, I get some of the frustration with the complexities of C++. Despite plenty of the downsides, i've learned to really respect C and C++ for not getting in your way. So many other programming languages and libraries want to "encourage" / force you to code a certain way. This kind of "opinionated software" is considered good. There are vastly different needs between engineering projects. While C++ doesn't help you much or hold your hand, at least it doesn't try to force all your projects to be written like a REST api, or document editor or whatever the language designer likes to code.