... Umm ... I know some people are thinking "SO" But I think it's pretty cool.
NOTE: There is no real use for something like this. I just thought I'd share it.
[Edited by - Protocol 0 on March 8, 2005 5:52:50 AM]

0

Share this post

Link to post

Share on other sites

However, I wouldn't overuse it - it mostly makes for unreadable code. You can even put more ?: conditionals into the if condition, but if a reader needs five minutes to figure out one line of code, that code isn't worth much.

For example, even this slight change:

if(min(a, b) < 7) { ...}

with min() defined elsewhere is way easier to read, because you moved the additional condition *out of* the if statement.

Share this post

Link to post

Share on other sites

I'm just wondering. Maybe this could be realy usefuly. I mean, basing an "if" condition; upon another condition. You could than have an "if" statements which could perform dozens of different conditions - based on other conditions.e.g

if () <- in there you would put as many ?'s as you want - which could completely change the if statment altogether. Saving lines and lines of code. You could save using 20 if statements, by just using one complex, well desinged "if" statments, with if/else expressions within the actual condition.

Share this post

Link to post

Share on other sites

Original post by Greg Kumm, you know it compiles down to the same kind of thing as just having more if's...

-Greg

No. That's false.

In the case of having them seperately, then yes. But using an if/else expression to define the condition of an "if" statement? Picture that. It's not the same thing. How would the compiler, in this case, compile it as multiple "if" statements if the "if" expression within the statement is actually used to define the "if" statement. It wouldn't work.

0

Share this post

Link to post

Share on other sites

In the case of having them seperately, then yes. But using an if/else expression to define the condition of an "if" statement? Picture that. It's not the same thing. How would the compiler, in this case, compile it as multiple "if" statements if the "if" expression within the statement is actually used to define the "if" statement. It wouldn't work.

Greg is right. At the ASM level they reduce to a chain of if statements. To use your original example, it's roughly like this:

int temp;if(a < b) temp = a;else temp = b;

if(temp < 7){ ... }

Of course it looks different on the ASM level and is probably optimized to be a bit more arcane (maybe even eliminates the need for an intermediate variable, possibly just keeping it in a register), but that's the basic idea.

All this "trick" does is make the code more obscure. It's indeed a cool feature of the language, but as you yourself said it has no real use. Compilers are very good at making compact, efficient machine code, so unless you are literally to the point where shuffling instructions is vital to execution speed, always opt for more readable and cleanly laid out code. Besides, if you're at the point where shuffling instructions is vital to execution speed, you don't need to be running through a compiler anyways.

0

Share this post

Link to post

Share on other sites

In the case of having them seperately, then yes. But using an if/else expression to define the condition of an "if" statement? Picture that. It's not the same thing. How would the compiler, in this case, compile it as multiple "if" statements if the "if" expression within the statement is actually used to define the "if" statement. It wouldn't work.

Methinks someone needs to learn to read assembler output.

0

Share this post

Link to post

Share on other sites

In the case of having them seperately, then yes. But using an if/else expression to define the condition of an "if" statement? Picture that. It's not the same thing. How would the compiler, in this case, compile it as multiple "if" statements if the "if" expression within the statement is actually used to define the "if" statement. It wouldn't work.

Share this post

Link to post

Share on other sites

Original post by Greg Kumm, you know it compiles down to the same kind of thing as just having more if's...

-Greg

No. That's false.

In the case of having them seperately, then yes. But using an if/else expression to define the condition of an "if" statement? Picture that. It's not the same thing. How would the compiler, in this case, compile it as multiple "if" statements if the "if" expression within the statement is actually used to define the "if" statement. It wouldn't work.

Greg's right. Your code, in x86 assembly, would be something like (a little ugly, it's been a while since I've programmed in assembly):

Actual [modified] code from something I wrote once. Of course; calling clone on a null auto_ptr_var is undefined. However, the auto_ptr_var does not have a default constructor and must be initialized in the initializer list.

Actual [modified] code from something I wrote once. Of course; calling clone on a null auto_ptr_var is undefined. However, the auto_ptr_var does not have a default constructor and must be initialized in the initializer list.

I meant that the nested if/ternary-operator construct was useless, not the ternary operator itself. I abuse that poor operator like you wouldn't believe, often to circumvent things exactly like the situation you listed out there.