similar to: [LLVMdev] [RFC] Add empty() method to iterator_range.

On Mar 19, 2014, at 11:32 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Mar 19, 2014 at 2:13 PM, Lang Hames <lhames at gmail.com> wrote: >> Hi all, >> >> As RFCs go this is short and sweet - I think it would be nice to add an >> empty method to iterator_range. Something like: >> >> bool empty() const { return begin() != end();

Hi Chandler, Agreed - ranges aren't containers, just views of sequences. Still, that's all many algorithms want, and it's just as valid to ask whether a sequence is empty as it is to ask that of a container. No contest on points 2 or 3, but I'm confused about point 4. When are ranges not pairs of iterators? I mean in a way that would clash with the proposal for empty() to be

Hello, Our llvm::iterator_range is quite minimalist in design, it does not even have an "empty" method. Is that because we want it to work on all iterators (including those dirty OutputIterator)? Maybe we can add a little bit to it? I recently needed: - bool empty() - value_type& font() - value_type& back() - void advance_begin(difference_type n) - void

If you're interested in the evolution of C++'s memory model, here are some papers on the topic: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html A working draft for the next C++ standard is also available:

Hello fans of the auto keyword! We now have a policy on how LLVM toolchains get updated <https://reviews.llvm.org/rL351765>! Let’s put that policy to good use, and talk about how we’ll move all monorepo projects past C++11. Previous Discussions LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond! <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>" A Short

On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello folks (except fans of April 1st: this is *not* a joke), > > We discussed migrating past C++11 > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html> recently > and got consensus. This led us to bump our minimum toolchain requirements >

Hello, I think there's a rather subtle problem with the inst_iterator. It declares its iterator category as std::bidirectional_iterator_tag but C++ standard requirements for forward iterator (which are included in requirements for bidirection iterator), say that the type of expression *r; should be T&, where 'r' is the iterator and T is its value type. The inst_iterator,

Hi all, This is just a PSA that as of r302752, 3 parallel algorithms (for_each, for_each_n, and sort) are available in llvm/Support/Parallel.h. Effort was made to match the C++ Parallelism TS N4507 [ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4507.pdf] as closely as possible, but some aspects were intentionally omitted. No support is added for the executor proposal N4406 [

> On Apr 1, 2019, at 4:10 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Apr 1, 2019, at 4:07 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote: >> >> On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

It's hard to say. By definition it appears undefined (in the sense that the TS literally does not define it), but on the other hand it is a TS and this issue would (hopefully) come up and be specified before it made it to standardization. Supporting recursive parallel calls certainly seems like desirable behavior, so from my point of view it would be nice to make sure it works. Not sure if

+1, thanks again for driving this. On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The discussion seems to have died down and gotten good consensus. I’ve > therefore create a patch which applies the proposed soft-errors: > > https://reviews.llvm.org/D57264 > > > We’ll only migrate to hard-error (and start using new

> On May 6, 2019, at 11:02 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I know you'll be shocked that we've slipped in our efforts. ;] I don't have a super meaningful ETA update though -- a bunch of unknows have been found and addressed, and again, I feel like we might finish this in roughly a month. > > On the flip side, I do want to clarify the

On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > I don’t have the C/C++ standards in front of me but IIRC whether a char/short/int/long/long long bitfield is signed or unsigned is implementation defined. You need to explicitly specify signed or unsigned in order to have any guarantee of the signedness, e.g. signed int. Section 3.9.1 of the C++11 standard [1]

On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: > >> In many places there is code that looks like: >> >> MBBI = next(MBBI); >> >> In C++0X there is a std::next that is likely to be in scope when these >> calls are made. And due to ADL the above call becomes ambiguous: >>

Howard Hinnant wrote: > On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > >> "next" is a popular name; if it breaks llvm, I'd expect this standards change to break a lot of existing code. Do you really want to do that? >> > > I'm happy to open an LWG issue for you on this subject. Here are directions on submitting an issue: > >

On Mon, May 6, 2019 at 2:44 PM James Y Knight <jyknight at google.com> wrote: > Given the small number of library features added by c++14, and given that > they were mostly already implemented in libstdc++ 4.9 [1], I suspect that > moving to c++14 with that stdlib as the minimum probably will not actually > cause friction for developers who are using normal toolchains to be able

Hi Mon Wang, As I understand it the C++0x memory model will, by default, be similar to Java's in that it will assume sequential consistency, using acquire/release atomics (similar to Java's volatile), for all programs that do not contain data races. Unlike Java in the case when a program contains a data race, the program behavior is undefined. Adopting this model allows many sequential

Hi, I’ve made my own version of std::vector which is called il::Vector. Due to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html>, LLVM can optimise away memory allocation. Therefore, the following code optimise away all memory allocation for w resulting in a single allocation during the whole program (for

On May 27, 2008, at 2:01 PM, Dale Johannesen wrote: > On May 27, 2008, at 1:40 PM, Mike Stump wrote: >> >> From n2461: >> >>> 8 The insert members shall not affect the validity of iterators and >>> references to the container, and the erase members shall invalidate >>> only iterators and references to the erased elements. >> >> Pretty

C says that plain bit-fields could be either signed or unsigned. C++ removed this allowance in core issue 739: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739 On Sat, Nov 16, 2013 at 1:55 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > > > I don’t have the C/C++