Any advantage to this syntax...

[Guest]

Is this:

A = B = C;

Any more efficient than:

A = C;
B = C;

In the compiled application?

Thanks.

J

 

[Barry Kelly]

Is this:

A = B = C;

It's certainly more obscure. Any difference in performance would be
almost unmeasurable though, and certainly not worth worrying about, as
it would be liable to change due to optimization improvements in the
future. The code at the bottom could be translated into the code above,
or vice versa, automatically by the compiler depending on which one
performs better. Ultimately, they ought to perform the same.

I personally consider it bad style to use assignment in an expression
except in certain, very limited scenarios. There is a borderline
justification for certain kinds of initialization, such as in:

counterA = counterB = 0;

And of course, reading items from a TextReader is idiomatic:

while ((line = r.ReadLine()) != null) { ... }

Outside of these kinds of things, I don't think it's a terribly good
idea.

Any more efficient than:

A = C;
B = C;

In the compiled application?

A slightly closer translation (C# 3.0) would be:

var temp = C;
B = temp;
A = temp;

Your translation would work out differently if e.g. C is a complex
expression or a property, and also B is assigned before C, which may
matter if A is a property and happens to have some odd dependency on B
in its setter.

-- Barry

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Is this:

A = B = C;

Any more efficient than:

A = C;
B = C;

In the compiled application?

Thanks.

J

Most likely they will be optimised into the same code.

Even if the code will be different, it's hard to predict which code will
actually perform better. If it's compiled into two separate load-store
operations, that might actually perform better than a load-store-store
sequence, as the two operations might be performed in parallel by the
processor.

Also, if there is a difference, it's so very small that you will only be
able to measure it if you repeat the operation a very large number of times.

(This all assumes of course that C is not a property or a huge
structure, but a regular, simple variable, like for example a local int.)

 

[Guest]

Thanks for the responses. I'm using it to initialize a bunch of properties, or in some cases, clear out a bunch of preprties in a reset function. I like the more compact syntax and I just started wondering if it was any more efficient, or just more convenient.

J
Is this:

A = B = C;

Any more efficient than:

A = C;
B = C;

In the compiled application?

Thanks.

J

 

[Luc The Perverse]

Thanks for the responses. I'm using it to
initialize a bunch of properties, or in
some cases, clear out a bunch of preprties
in a reset function. I like the more
compact syntax and I just started wondering
if it was any more efficient, or just more
convenient.

*Message reformatted slightly*

If you have two things that are going to a null, zero or equivalent state
then yes it might be clear. If you have many properties returning to
default values - you might want to consider not hard coding them - or
storing them in an array.

I had a serious problem in one project that I worked on where resetting,
default and initialization values for options on dialogs were all being set
to different values in different places - and error/consistancy checking was
spread out in event handler functions all over the place. It was an
unbelievable mess as dialogs would change and old data would become
obsolete. (And count on the end user to find bugs like these!)

I may have overcorrected in my re-write. I won't go into details as it was
not a C# project.

 

[Zeke]

Why don't you just put it in a loop and benchmark it?

 

[Alun Harford]

Most likely they will be optimised into the same code.

Even if the code will be different, it's hard to predict which code will
actually perform better. If it's compiled into two separate load-store
operations, that might actually perform better than a load-store-store
sequence, as the two operations might be performed in parallel by the
processor.

If the JIT compiler were good, it could reorder the operation so that
the result of B=C comes back when it's needed for the next instruction.

Of cause, if the compiler were good, it could change between the two
methods as needed.

Unfortunately, the C# compiler is rubbish.

Alun Harford

 

[Mark Wilden]

I like A = B = C because it reduces duplication, which increases readability
and decreases bugs, in my opinion.

///ark

 

[Mark Howell]

There are two problems with that format:
1) You have to know the order of evaluation.
2) You're betting that that order will never be changed.

As for readability, I feel rather the opposite, it seems a bit too terse
rather than clear.

 

[Jon Skeet [C# MVP]]

There are two problems with that format:
1) You have to know the order of evaluation.
2) You're betting that that order will never be changed.

As for readability, I feel rather the opposite, it seems a bit too terse
rather than clear.

Agreed. It would certainly make me stop and think, whereas I'd take two
separate assignments in my stride.

 

[Kevin Spencer]

1) You have to know the order of evaluation.

There is no evaluation in the expression A = B = C; It is an assignment
expression. The only order issue is that the value to be assigned be on the
right. The order of the other (lefthand) operands is irrelevant.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

There is no evaluation in the expression A = B = C; It is an assignment
expression.

That depends what you mean by evaluation. The compiler evaluates the
assignment B = C to have the value of the assigned value, and uses that
in the assignment to A. It's not what you normally would regard as an
evaluation as it's so trivial, but the compiler has to do it anyway.

The only order issue is that the value to be assigned be on the
right. The order of the other (lefthand) operands is irrelevant.

Yes, once you realise that B = C has to be evaluated (?) first in order
to assign it to A, the order of execution is clear. If you see this
construct for the first time I imagine that the first impression might
be that A = B would be executed first, as we read from left to right.

 

[Mark Wilden]

In some cases, A = B = C better represents what I mean that putting the
assignments on separate lines. It says "I want all three of these values to
be the same." If that's only incidentally true, then I'd put them on
separate lines.

///ark

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

In some cases, A = B = C better represents what I mean that putting the
assignments on separate lines. It says "I want all three of these values to
be the same." If that's only incidentally true, then I'd put them on
separate lines.

///ark

Good point.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Is this:

A = B = C;

Any more efficient than:

A = C;
B = C;

In the compiled application?

I would expect same code generated, but that is implementation
not language.

The construct is an old C'ism.

And it should not have been migrated from the 70's to
the 80's in my opinion.

Arne

 

[Rick Lones]

I would expect same code generated, but that is implementation
not language.

The construct is an old C'ism.

And it should not have been migrated from the 70's to
the 80's in my opinion.

Arne

Oh, it's older than that. Saves on 80-column punch cards, you see . . .

-rick-

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Oh, it's older than that. Saves on 80-column punch cards, you see . . .

What language ?

I am pretty sure that I have seen it in some Fortran dialects, but
I do not think it was ANSI Fortran.

Arne