Displaying 3 results from an estimated 3 matches for "1_62_0".
2016 Dec 14
2
Openness to a "zip_iterator" type?
...LLVM) use a traditional for-loop with 2 iterators in it. In a few others, the implementation uses range-for over 1 range with an iterator pattern on the other.
IMO, the correct solution to this would be a templated 'zip' type (similar, though not identical to http://www.boost.org/doc/libs/1_62_0/libs/iterator/doc/zip_iterator.html) that would permit:
for (auto&& things : IteratorZip(ParmRange, ArgRange)) {
[CurParm, CurArg] = things; // things is a tuple that contains a reference to each value
}
If I were to implement this IteratorZip type for the LLVM codebase, would this be so...
2016 Dec 14
0
Openness to a "zip_iterator" type?
...a traditional for-loop with 2 iterators in it. In a few others, the implementation uses range-for over 1 range with an iterator pattern on the other.
>
> IMO, the correct solution to this would be a templated 'zip' type (similar, though not identical to http://www.boost.org/doc/libs/1_62_0/libs/iterator/doc/zip_iterator.html) that would permit:
>
> for (auto&& things : IteratorZip(ParmRange, ArgRange)) {
> [CurParm, CurArg] = things; // things is a tuple that contains a reference to each value
> }
>
>
> If I were to implement this IteratorZip type for...
2016 Oct 12
15
RFC: General purpose type-safe formatting library
A while back llvm::format() was introduced that made it possible to combine
printf-style formatting with llvm streams. However, this still comes with
all the risks and pitfalls of printf. Everyone is no-doubt familiar with
these problems, but here are just a few anyway:
1. *Not type-safe.* Not all compilers warn when you mess up the format
specifier. And when you're writing your own