On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques <[email protected]> wrote: > On Tue, 17 Nov 2009 05:44:31 -0500, downs <[email protected]> wrote: > >> Robert Jacques wrote: >>> >>> On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun <[email protected]> >>> wrote: >>> >>>> Robert Jacques wrote: >>>>> >>>>> On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon >>>>> <[email protected]> wrote: >>>>> >>>>>> dsimcha wrote: >>>>>> <snip> >>>>>>> >>>>>>> Axe. Looks like the only things it's good for are making code >>>>>>> undreadable and >>>>>>> abusing for loop syntax to... >>>>>>> Make code unreadable. >>>>>> >>>>>> <snip> >>>>>> >>>>>> Suppose you want the increment of a for loop to change two variables >>>>>> in parallel. I don't call that making code unreadable. >>>>>> >>>>>> Stewart. >>>>> >>>>> Yes the classic use case of the comma operator is multi-variable >>>>> declarations/increments in a for loop. >>>> >>>> This was argued before and as I and others said before, this is *not* >>>> a use case for the comma separator. >>>> >>>> e.g. >>>> for (int a = 0, b = 1; condition(); a++, b++) {...} >>>> >>>> int a = 0, b = 1 // this is a declaration and not an expression >>>> >>>> a++, b++ // isn't assigned to any variable and can be treated as a tuple >>>> >>>> the only use case that will break is if the two increments are >>>> dependent on the order (unless tuples are also evaluated from left to >>>> right): >>>> e.g. >>>> a + 5, b + a // >>>> >>>> I doubt it very much that anyone ever uses this, it's too unreadable >>>> to be useful. >>> >>> However, I imagine tuple(a++,b++) would have some overhead, which is >>> exactly what someone is trying to avoid by using custom for loops. >>> >>> Personally, I like using a..b => tuple(a,b), since it also solves the >>> multi-dimensional slicing and mixed indexing and slicing problems. >> >> Zero overhead. Tuples are flat compile-time entities. > > There are compile time tuples and runtime tuples. D already has a form of > compile-time tuples. This discussion seems to be about runtime tuples which > currently don't have a nice syntax: you have to use tuple(a,b). And > tuple(a,b) does have runtime overhead.
I think the point is that in something like this: auto foo = (a,b); foo.a += 2; foo.b += foo.a; // etc The tuple foo is allocated on the stack and the compiler knows where the a part and b part are, so the code generated should be absolutely no different from the code generated for: auto foo_a = a; auto foo_b = b; foo_a += 2; foo_b += foo_a; // etc So there doesn't need to be any "tuple overhead". --bb
