and the new multi ranges which essentially could be a variable list of types that expose a begin() and end() member.ranges (as defined in the ranges proposal).The only current options I currently know of however are: I assume it would actually be named differently in order to accept various differing range specifications. I only called it "make_multirange" to illustrate the focus of this current proposal. I guess in reality it could be down to that function to be specialised based on the T's that are passed. I was merely suggesting what the ideal solution might look like given other changes in the standard that are currently not available.įor example I dont think the "ranges.get()." is currently possible to expand out all the items of a tuple like object?Īlso I did not specify exactly what the "make_multirange" function does. The assumption of dependacy on concepts is correct and would be needed for this ability as you have suggested. I was essentially thinking this in addition to the existing for_each definitions. To me it is just much more clear and precise and easy to reason about. I am however not against that also being possible in the standard, but feel a clearer syntax would be better than depending on library iterator adapters and tuple style multiple return values.
FOR LOOP IN R RANGE ZIP
Using the zip format it is difficult to know what each t.get refers to (I do understand that this is essentially the multiple value return idea, but that also then to me seems like it could bloat the declarations in the for statement). To me is much clearer and less prone to errors than:įor( auto& t : zip_iterator( cont1. My only other issues are those to do with clarity of the code. Version stuff under the covers then I would be happy with that. If the new multi-range-based for syntax could be used but essentially do the zip.
FOR LOOP IN R RANGE CODE
My main bugbare is the required boilerplate code in order for it to work. With regards to preference of the zip_iterator version. Therefore no out of range exceptions can occur. Basically the _end is equal the the first container end reached. With regards to what if the containers are different in size, that is mentioned in my draft proposal. Just thinking about it I think the standard changes might even be simpler with that syntax as it will just be a change to the existing range-based for statement rather than a new syntax form. I will amend the proposal to use EWG 43 syntax. I see your points with regards to syntax style. Syntactically close to the related ranges with that syntax it isĮasier to add or remove ranges to iterate over. Syntax more because the element variable declarations are
Personally, I like the zip solution most because it makes clear what
Also, what is theīehavior if the containers have different sizes? Iterate over permutations of the containers. To me, this syntax is slightly confusing.
I would indeed expect it to be more similar to:įor ( auto& var1, auto& var2 : con1, cont2 ) This is just my simple way of writing it as this is a quick draft. I just feel that the way I have defined it is easier to reason about the loop content given a long list of containers.Ībout the issue of the single auto& in the declaration. Īs I mentioned before I am not tied to any particular syntax and would be happy to change. As such I see it as essentially equivalent to the of the legacy for statement, which defines the iteration requirements.įor ( declaration iteration requirement iteration action ).įor ( declarations : iteration requirements and actions ). In regards to the mapping I have always viewed the : to essentially be the "in" definition.
0 kommentar(er)
