OK, Maybe the ADA folks are right

This compiles:

((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
raw_data;

I have every confidence that it would work as intended in lieu of

if (adc_ping_pong)
{
osc_vector[fill_vector][fill_ix] = raw_data;
}
else
{
gyro_vector[fill_vector][fill_ix] = raw_data;
}

Ewww.

--
www.wescottdesign.com

On 10/26/2011 5:09 PM, Tim Wescott wrote:
> This compiles:
>
> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
> raw_data;
>
> I have every confidence that it would work as intended in lieu of
>
> if (adc_ping_pong)
> {
> osc_vector[fill_vector][fill_ix] = raw_data;
> }
> else
> {
> gyro_vector[fill_vector][fill_ix] = raw_data;
> }
>
> Ewww.
>

Hey, don't knock it. On a RISC machine, that difference might save you
two, maybe even three instructions.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

On Wed, 26 Oct 2011 19:09:40 -0500, Tim Wescott wrote:

> This compiles:
>
> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
> raw_data;
>
> I have every confidence that it would work as intended in lieu of
>
> if (adc_ping_pong)
> {
> osc_vector[fill_vector][fill_ix] = raw_data;
> }
> else
> {
> gyro_vector[fill_vector][fill_ix] = raw_data;
> }
>
> Ewww.

Probably what the orignal intent, other than just being
a smart ass, is to try and help a bad compiler with the index
multiplies. A good optimizer will fix both code sets to be
the same or very close. The first example might save a stack
save/load if you have a lot of registers to play with.

The Ewww factor is very high, enough to send the person back
to beginning typing school to learn to use more than 2 fingers.

--
Joe
Republic of Texas

On Wed, 26 Oct 2011 19:09:40 -0500, Tim Wescott wrote:

> This compiles:
>
> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
> raw_data;
>
> I have every confidence that it would work as intended in lieu of
>
> if (adc_ping_pong)
> {
> osc_vector[fill_vector][fill_ix] = raw_data;
> }
> else {
> gyro_vector[fill_vector][fill_ix] = raw_data;
> }
>
> Ewww.

You're complaining about the spurious parentheses around adc_ping_pong,
on the first line, right? ;-)

Cheers,

--
Andrew

On 10/27/2011 02:09 AM, Tim Wescott wrote:
> This compiles:
>
> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
> raw_data;
>
> I have every confidence that it would work as intended in lieu of
>
> if (adc_ping_pong)
> {
> osc_vector[fill_vector][fill_ix] = raw_data;
> }
> else
> {
> gyro_vector[fill_vector][fill_ix] = raw_data;
> }
>
> Ewww.
>

You could introduce a temporary variable, and make it a lot more readable:

vector = adc_ping_pong ? osc_vector : gyro_vector;

vector[fill_fector][fill_ix] = raw_data;

Or, rewrite the code like this:

vector[adc_ping_pong][fill_vector][fill_ix] = raw_data;

Andrew Reilly <areilly---@bigpond.net.au> writes:

> On Wed, 26 Oct 2011 19:09:40 -0500, Tim Wescott wrote:
>
>> This compiles:
>>
>> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
>> raw_data;
>>
>> I have every confidence that it would work as intended in lieu of
>>
>> if (adc_ping_pong)
>> {
>> osc_vector[fill_vector][fill_ix] = raw_data;
>> }
>> else {
>> gyro_vector[fill_vector][fill_ix] = raw_data;
>> }
>>
>> Ewww.
>
> You're complaining about the spurious parentheses around adc_ping_pong,
> on the first line, right? ;-)

ha ha , that is just what I noticed, And I write stuff a bit like that
sometimes,,,

AFAIK they are equivalent and should produce the same optimised object
code.


--

John Devereux

On 27.10.2011 02:09, Tim Wescott wrote:
> This compiles:
>
> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
> raw_data;

I'll call, and raise you a

fill_ix<:adc_ping_pong
? osc_vector
: &(gyro_vector[(int)
NULL])[fill_vector:>] = raw\
_data;

If you're going to try a "reductio ad absurdum", why stop short? Might
as well go all the way to make it truly absurd.

Of course it will compile --- it'll even work. Which does beg the
question: why the "Ewww"?

Seriously, though, nobody forces anyone to write code like that first
snippet (much less mine), and rather few programmers would. Most people
would only consider the conditional operator for the right-hand side of
an assignment, or function arguments, i.e. for making rvalues, not lvalues.

But then again, in a pinch the compiler might, for some strange reason,
compile denser/faster code from it, and if that saves the day, there's
nothing wrong with having that option, is there?

And if you're really uncomfortable with that rather dense notation,
there are always in-between options like those shown by others here.
Following the principle of separating things that differ from things
that don't (in other words: don't copy-paste, concentrate!), I would
lean towards this one:

if (adc_ping_pong) {
vector = osc_vector;
} else {
vector = gyro_vector;
}

vector[fill_vector][fill_ix] = raw_data;

On 2011-10-27, Hans-Bernhard Bröker <> wrote:
> On 27.10.2011 02:09, Tim Wescott wrote:
>> This compiles:
>>
>> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
>> raw_data;
>
> I'll call, and raise you a
>
> fill_ix<:adc_ping_pong
> ? osc_vector
> : &(gyro_vector[(int)
> NULL])[fill_vector:>] = raw\
> _data;
>
> If you're going to try a "reductio ad absurdum", why stop short? Might
> as well go all the way to make it truly absurd.
>
> Of course it will compile --- it'll even work. Which does beg the
> question: why the "Ewww"?
>
> Seriously, though, nobody forces anyone to write code like that first
> snippet (much less mine), and rather few programmers would. Most people
> would only consider the conditional operator for the right-hand side of
> an assignment, or function arguments, i.e. for making rvalues, not lvalues.
>
> But then again, in a pinch the compiler might, for some strange reason,
> compile denser/faster code from it, and if that saves the day, there's
> nothing wrong with having that option, is there?
>
> And if you're really uncomfortable with that rather dense notation,
> there are always in-between options like those shown by others here.
> Following the principle of separating things that differ from things
> that don't (in other words: don't copy-paste, concentrate!), I would
> lean towards this one:
>
> if (adc_ping_pong) {
> vector = osc_vector;
> } else {
> vector = gyro_vector;
> }
>
> vector[fill_vector][fill_ix] = raw_data;
>

I think if you are going to use the conditional operator you *must* nest them at
least nine deep. I did that once about twenty years ago, the boss emitted steam.

Well worth it.

Mike

On Thu, 27 Oct 2011 13:51:14 -0500, Mike McGinn
<> wrote:
>
>I think if you are going to use the conditional operator you *must* nest them at
>least nine deep. I did that once about twenty years ago, the boss emitted steam.
>
>Well worth it.
>
>Mike

You can probably rigorously prove that any if-else construct involving
assignment to a single variable can be represented with nested C
ternary operators.

DFC

"Rob Gaddi" <> wrote in message
news:j8a94q$bdf$...
> On 10/26/2011 5:09 PM, Tim Wescott wrote:
>> This compiles:
>>
>> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
>> raw_data;
>>
>> I have every confidence that it would work as intended in lieu of
>>
>> if (adc_ping_pong)
>> {
>> osc_vector[fill_vector][fill_ix] = raw_data;
>> }
>> else
>> {
>> gyro_vector[fill_vector][fill_ix] = raw_data;
>> }
>>
>> Ewww.
>>
>
> Hey, don't knock it. On a RISC machine, that difference might save you
> two, maybe even three instructions.

Only if you have a crap compiler :-(

tim