Timeline for A tuple unpacking macro that approximates Python elegance
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 1, 2014 at 14:01 | comment | added | Nobody moving away from SE |
I did not mean realtime chat but the one that is available here on SE (longer discussions in comments are discouraged). The point about zip is that there are instances where you have data in different containers and want to zip them because they come from different sources and you don't want to duplicate. Although I cannot tell you an example right now I know for a fact that I have been missing this feature repeatedly in the last year. And again: My goal for DECLARE_AND_TIE was to improve the "language" interface towards tuples and not to solve problems like zip and enumerate.
|
|
| Sep 1, 2014 at 13:11 | comment | added | Michael Urman | Unfortunately I don't typically have time available for chat, so here's more food for thought (I don't need the answers, but you might). I feel that you're balancing conflicting needs here. In the zip case, why is your related data in multiple containers, instead of records. For non-zip, why not work with the source of the tuple? DECLARE_AND_TIE solves only half the problem; however discussing ideas for solving the whole problem veers a bit from codereview's focus. (Your point about my pre-C++11 requiring random-access containers is true, but I lack the context to evaluate its importance.) | |
| Aug 31, 2014 at 20:54 | comment | added | Nobody moving away from SE | Despite the many concerns I commented now I have to +1 your answer. You have dealt with many of the aspects I wanted reviewed. I would really like to get into a more detailed discussion about this but I feel the comments are the wrong place for this. Would you be interested in such a discussion and if so should we take it to chat? | |
| Aug 31, 2014 at 20:52 | comment | added | Nobody moving away from SE |
Your last part focuses on the zip algorithm, which again is somewhat orthogonal to what I wanted to achieve. There are more instances than only enumerate and zip that could use DECLARE_AND_TIE. Basically everytime we are using tuples we can use better names than the indices to refer to the elements which would justify the aliasing and if we use more then two elements the DECLARE_AND_TIE would look cleaner (IMHO). Finally, your pre-C++11 version unnecessarily constrains the solution random access containers (and even there is non-optimal because of repeated indexing).
|
|
| Aug 31, 2014 at 20:46 | comment | added | Nobody moving away from SE |
Regarding your second section: You are speeking of too much hidden complexity as a problem but the only problem I see there is in maintanence (/wider compiler support). The complexity is hidden to the user and you can hardly argue that it gives a measurable slowdown. As the name suggests I wanted a replacement for std::tie that does not involve copying/moving (though the name tie does not fit any more I think). From my two worries I would give the second more weight than the first. I can clearly imagine an implementation (that would again require a macro) but for NamedTupleZip.
|
|
| Aug 31, 2014 at 20:34 | comment | added | Nobody moving away from SE | I must admit that my ordering is just grown. The basic principles were: "public" interface first then symbols before they are used and in the order in which they are used. The problem about the "live" tests is more like: I would want to check if the compiler errors are sane but this is far too vague (would need a "compiler error testing framework" + some AI to evaluate the errors). I did not tests the duplicate naming problem because I found any errors related to that quite obvious (the compiler telling you that the name is already declared pointing to the macro invocation). | |
| Aug 31, 2014 at 14:59 | history | answered | Michael Urman | CC BY-SA 3.0 |