Chad J wrote: > Steven Schveighoffer wrote: >> On Wed, 29 Jul 2009 14:22:26 -0400, grauzone <n...@example.net> wrote: >> >>> Steven Schveighoffer wrote: >>>> On Wed, 29 Jul 2009 10:16:33 -0400, grauzone <n...@example.net> wrote: >>>> >>>>> Daniel Keep wrote: >>>>>> Maybe the compiler could rewrite the above as: >>>>>> auto t = a.b; >>>>>> t.c = 3; >>>>>> a.b = t; >>>>>> Unless it can prove it doesn't need to. Same solution as to the op= >>>>>> conundrum. >>>>> Yes! At least that's what the user wants. >>>>> >>>>> The compiler has to detect, that the object was modified at all. (To >>>>> know whether it should generate code to write back the property.) >>>>> Would this make the compiler much complexer? >>>>> >>>>> You also have to deal with nested properties: >>>>> >>>>> a.b.c.d = 3; >>>>> >>>>> turns to >>>>> >>>>> auto t = a.b; >>>>> auto t2 = t.c; >>>>> c.d = 3; >>>>> t.c = t2; >>>>> a.b = t; >>>>> >>>>> ??? >>>> Yeah, I think this idea is no good. a.b.c.d.e.f = 3, results in one >>>> gigantic mess, which the user might not want. >>> I don't want to type out that mess as a user either... >> What I meant was, I wouldn't want something like a.b.c.d.e.f = 3 to >> generate the equivalent of 25 lines of code. >> >>> Design changes to avoid that mentioned mess would interfere with the >>> goal of abstraction (e.g. assume you have widget.position, now how do >>> you set only the x coordinate? yeah, split the property into >>> position_x and position_y. Result is you have more noise, and you >>> can't use a Point struct.) >> option 1, return a ref Point struct >> option 2, return a special struct which uses properties to set the >> values in the original widget. >> >> I don't think it's an impossible problem to solve, I just don't think >> the compiler should be involved, because it makes it too easy to >> gerenate horrible code. >> > > So we could have semantics that actually work, but you don't want them > because, oh man, my code might have to do a few more assignments. A few > assignments. Really?! > > !!!! > > Assignments aren't even that expensive! They are one of the easiest > operations your CPU can perform! It's like you'll have a few more MOV > operations laying around in the worst case. > > If there are dereferences involved it has to break up the expression > ANYWAYS. > > ARGH! > > You'll have to forgive me. What I'm reading here is quite frustrating. >
Thinking about it a little more, the extra temporaries could run you out of registers. That still sounds like a negligable cost in most code. As I've mentioned elsewhere, it's also really easy to optimize this by hand if it ever becomes a performance problem. >> Now, having the compiler reject invalid assignments is definitely >> something I can live with. >> >> -Steve