search for: randomaccessiterator

...*const *Vals, ///< The elements of the array unsigned NumVals) { ///< The length of the array return ConstantArray::get(Ty, Vals, NumVals); } /// GetArray - return a constant array given an array type and an /// iterator pair template<typename RandomAccessIterator> static Constant *GetArray( const ArrayType *Ty, ///< The type of the array RandomAccessIterator ArgBegin, ///< Iterator for the first element RandomAccessIterator ArgEnd) { ///< The elements of the array return GetArray(Ty, &ArgBegin[0], A...

...e API if it were a subset of an existing standard, or with clearly documented deviations from the standard. I had not actually thought about using the std::random_device interface. If we were able to use C++11 features, this would be quite nice, since that includes builtin things like shuffle over RandomAccessIterators and such niceties. However, since this is not the case, I think complying to the <random> API (which is quite odd, there's not even an overarching interface) might be more complication than is necessary. We would have to emulate not only the generator, but also the distribution classes a...

Stephen Crane wrote: > Thanks for all the feedback! It seems there is some interest, so I thought I'd try to summarize discussions so far, and provide patches for closer inspection. I'm not sure if patches should end up here or on a different list in this instance, so if I should instead send this to a different list, I'm happy to do so. > > - Is diversity needed, or are

Thanks for all the feedback! It seems there is some interest, so I thought I'd try to summarize discussions so far, and provide patches for closer inspection. I'm not sure if patches should end up here or on a different list in this instance, so if I should instead send this to a different list, I'm happy to do so. - Is diversity needed, or are existing protections sufficient? As