search for: emplace_back

> > > From yesterday discussion, Daniel Berlin proposed using emplace_back > everywhere to make code easier to maintain. I think it is valid argument, > but I believe it would reduce readability. > Just to be clear; I proposed not trying to switch uses back and forth without real data, and to come to some agreement about what should be written in the first place...

...dev < > cfe-dev at lists.llvm.org> wrote: > >> Thanks for very accurate responses. >> - I totally agree what Dave and Chandler said about explicit and implicit >> operations, this is what I meant my first email. >> I believe there are places like >> v.emplace_back(A, B); >> istead of >> v.push_back(make_pair(A, B));b >> That can make code simpler. >> > > Do you have examples? The only ones i can come up with are the ones where > the push_back variant literally can't compile because the type isn't > movable....

> On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > From yesterday discussion, Daniel Berlin proposed using emplace_back everywhere to make code easier to maintain. I think it is valid argument, but I believe it would reduce readability. > > Just to be clear; I proposed not trying to switch uses back and forth without real data, and to come to some agreement about what should be written in the first place, pre...

...8 AM Piotr Padlewski via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Thanks for very accurate responses. > - I totally agree what Dave and Chandler said about explicit and implicit > operations, this is what I meant my first email. > I believe there are places like > v.emplace_back(A, B); > istead of > v.push_back(make_pair(A, B));b > That can make code simpler. > Do you have examples? The only ones i can come up with are the ones where the push_back variant literally can't compile because the type isn't movable. Perhaps it would be useful to bre...

...lization > struct A { > void *ptr = nullptr; > }; > > (instead of doing it in constructor) > > - use default, override, delete > - skip "virtual" with override > > The last point is to get to consensus with > > push_back({first, second}) > or > emplace_back(first ,second); > It might be a bit noisy, but I'd be inclined to start a separate thread for each of these on llvm-dev with a clear subject line relevant to each one. So they don't get lost and some of them don't get drowned out by the discussion of others, etc. > > 2016-1...

...-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: >> >> >> From yesterday discussion, Daniel Berlin proposed using emplace_back everywhere to make code easier to maintain. I think it is valid argument, but I believe it would reduce readability. >> >> Just to be clear; I proposed not trying to switch uses back and forth without real data, and to come to some agreement about what should be written in the first pl...

On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > From yesterday discussion, Daniel Berlin proposed using emplace_back > everywhere to make code easier to maintain. I think it is valid argument, > but I believe it would reduce readability. > > > Just to be clear; I proposed not trying to switch uses back and forth > without real data, and to come to some agreement about what should be > written...

...om> wrote: > > > > On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > From yesterday discussion, Daniel Berlin proposed using emplace_back > everywhere to make code easier to maintain. I think it is valid argument, > but I believe it would reduce readability. > > > Just to be clear; I proposed not trying to switch uses back and forth > without real data, and to come to some agreement about what should be > written...

...at you agree/disagree with the others. One of the things that I would like to propose, is using push_back whenever the inserted type is the same or it implicitly casts itself. std::vector<Value*> v; Instr *I; Value *V; IntrinsicInstr *II; v.push_back(I); v.push_back(V); v.push_back(II); Use emplace_back only if we insert temporary object like: std::vector<SomeType> v2; v2.emplace_back(a, b, c); // instead of v.push_back(SomeType(a, b, c)); The first reason is make code simple and more readable. I belive that code 'v.push_back(I)' is more readable than 'v.emplace_back(I)' be...

Somewhat unfortunately, we have two discussions here: - Clang-tidy has checks that might improve code -- should we deploy them? If so which? I'll address this in a separate email, and focus this one on: - Should we have coding standards around 'push_back' and 'emplace_back', and if so, what should they say? I think the amount of confusion makes a coding standard useful. As for what it should say, I tend to agree with Dave here. In particular: On Thu, Dec 29, 2016 at 12:03 PM David Blaikie via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Thu, Dec...

Dave pointed out that I didn't complete one aspect of my argument on the push_back vs. emplace_back: On Thu, Dec 29, 2016 at 2:04 PM Chandler Carruth <chandlerc at gmail.com> wrote: > Still another way to see the consequence of this is to look at the nature > of compiler errors when a programmer makes a mistake. > > With emplace_back, if you fail to call the constructor correc...

Thanks for very accurate responses. - I totally agree what Dave and Chandler said about explicit and implicit operations, this is what I meant my first email. I believe there are places like v.emplace_back(A, B); istead of v.push_back(make_pair(A, B));b That can make code simpler. I think in cases like this we can leave it for judgement of contributor. Having said that I think the case Chandler and Dave mentioned should be in LLVM style guide. @Daniel does this argument seem good enough t...

...ngs that I would like to propose, is using push_back > whenever the inserted type is the same or it implicitly casts itself. > > std::vector<Value*> v; > Instr *I; > Value *V; > IntrinsicInstr *II; > v.push_back(I); > v.push_back(V); > v.push_back(II); > > Use emplace_back only if we insert temporary object like: > > std::vector<SomeType> v2; > v2.emplace_back(a, b, c); // instead of v.push_back(SomeType(a, b, c)); > > The first reason is make code simple and more readable. I belive that code > 'v.push_back(I)' is more readable than ...

...9; instead of "typedef" > - use default member initialization > - use default, override, delete > - skip "virtual" with override I thought we had all of those already... > The last point is to get to consensus with > > push_back({first, second}) > or > emplace_back(first ,second); I second Chandler's opinion on this. cheers, --renato

...on addressing them. * Piotr Padlewski has kicked off a discussion on [enforcing or further encouraging the use of clang-tidy in LLVM development](http://lists.llvm.org/pipermail/llvm-dev/2016-December/108559.html). The thread also includes a related but somewhat parallel discussion on the use of `emplace_back` in LLVM. * Vedant Kumar has provided a [really helpful description](http://lists.llvm.org/pipermail/llvm-dev/2016-December/108577.html) of the definition of clobber and local dependence in the context of DeadStoreElimination. * Davide Italiano has put out a [call for testers](http://lists.llvm.o...

On Tue, Oct 31, 2017 at 1:57 PM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Last time we discussed this, the consensus was "I think we can survive > another year without generalized constexpr and variable templates". > > Well, we did indeed survive. And it's been exactly a year! So > naturally, it only makes sense to revive this :)

Hi, The code in Support/Timer.cpp has strangely inconsistent behavior for printAll vs printJSONValues. The former can work multiple times, while the latter calls prepareToPrintList(), which stops all timers, hence making all further attempts to print timers crash. Would it be possible not to call prepareToPrintList on printJSONValues, or at least make it optional? I am trying to serialize

...pool::open("path/to/file", ...); using pvector = std::vector<foo, persistent_allocator<foo>>; { auto tx = transaction::start(handle); // transactions are per pool file auto vec_ptr = allocate_from_persistent_memory<pvector>(); vec_ptr->emplace_back(foo, parameters); } } The problem occurs when standard library containers have metadata. For example rb tree nodes carry their color, which will not be included in the transaction's undo log. To address this we propose to define a new type in the std::pointer_traits, which could be used to...

...loader gained basic support for COFF ARM. [r273682](http://reviews.llvm.org/rL273682). ## Clang commits * `constexpr if` support has been added to Clang. [r273602](http://reviews.llvm.org/rL273602). * clang-tidy has a new `modernize-use-emplace` check that will replace calls of `push_back` to `emplace_back`. [r273275](http://reviews.llvm.org/rL273275). * The CMake build system for Clang gained a `ENABLE_X86_RELAX_RELOCATIONS` option. [r273224](http://reviews.llvm.org/rL273224). ## Other project commits * Basic support for versioned symbols was added to LLD. [r273143](http://reviews.llvm.org/rL273...

...t (e.g [7][8][9][10]), and I already > praised this at the time it happened [11] !! > > I have never seen any push back on such commits and I don’t want to see > this changing at all. > > > > 3) "if people want to make global pattern-based cleanups (push_back -> > emplace_back, range-based-for, etc), we should just raise it on llvm-dev > and make a decision about the value of the cleanup.” > > This seems to me to be in line with existing practices. > > However I’d like to be very careful about this: there is already a lot of > things that are accepted (...