search for: sometype

...N on the SmallVector does not carry the > intent the same way, and is too easy to miss in review (or while reading > code). > > I'm not quite following here - what sort of problems do you anticipate > by readers missing the default value for N? > Reading code `SmallVector<SomeType>` does not express that it is *intentional* to leave of the value for N. It can easily be just forgotten, and it could easily be implicitly `0`, and as a reviewer (or code reader later) I don't know if this is was intentional or not. This is why I am quite opposed to "loosen" the c...

Here''s my problem... Suppose you have a page that lists some data. You also have some URLs that can be used to filter that data. Lets say you have a few links that filter by type. When you click on them you get URLs like this one: http://localhost/controller/action?type=SOMETYPE Then you click on a link that filters by date. When you click on this url you would normally get something like this: http://localhost/controller/action?date=SOMEDATE But since I previously clicked on another URL I want to get something like this: http://localhost/controller/action?type=SOMETYP...

...t the same way, and is too easy to miss in review (or while > reading code). > >> > >> I'm not quite following here - what sort of problems do you anticipate > >> by readers missing the default value for N? > > > > > > Reading code `SmallVector<SomeType>` does not express that it is > *intentional* to leave of the value for N. It can easily be just forgotten, > and it could easily be implicitly `0`, and as a reviewer (or code reader > later) I don't know if this is was intentional or not. This is why I am > quite opposed to &quo...

...mallVector does not carry the intent the same way, and is too easy to miss in review (or while reading code). >> >> I'm not quite following here - what sort of problems do you anticipate >> by readers missing the default value for N? > > > Reading code `SmallVector<SomeType>` does not express that it is *intentional* to leave of the value for N. It can easily be just forgotten, and it could easily be implicitly `0`, and as a reviewer (or code reader later) I don't know if this is was intentional or not. This is why I am quite opposed to "loosen" the c...

...ile >>> reading code). >>> >> >>> >> I'm not quite following here - what sort of problems do you anticipate >>> >> by readers missing the default value for N? >>> > >>> > >>> > Reading code `SmallVector<SomeType>` does not express that it is >>> *intentional* to leave of the value for N. It can easily be just forgotten, >>> and it could easily be implicitly `0`, and as a reviewer (or code reader >>> later) I don't know if this is was intentional or not. This is why I am &g...

...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)' because I don't have to think about if the element type has spec...

...asy to miss in review (or while >> reading code). >> >> >> >> I'm not quite following here - what sort of problems do you anticipate >> >> by readers missing the default value for N? >> > >> > >> > Reading code `SmallVector<SomeType>` does not express that it is >> *intentional* to leave of the value for N. It can easily be just forgotten, >> and it could easily be implicitly `0`, and as a reviewer (or code reader >> later) I don't know if this is was intentional or not. This is why I am >> quite...

...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)' because I don't > have to think about if t...

I''m trying to extend the standard ''user'' type to add maintenance of some of the contents of a user''s home directory, and I''m trying to avoid creating an entirely new custom type if I can. The approach I''m taking is to create a site::user defined type which in turns calls the standard user type. I''m having a problem figuring out

On Mon, Nov 16, 2020 at 12:55 PM David Blaikie <dblaikie at gmail.com> wrote: > I will say I'm not a huge fan of adding even more names for things in > this fairly core/common use case (now we'll have even more vector > names to pick from) - can we use default template arguments so we can > write SmallVector<T> instead of SmallVector<T, N> and would that >

Hi, I'm trying to add function calls in the LLVM IR using the IRBuilder class. I've read both tutorials about functions but I still get assertion errors. I allocate memory for all function arguments and pass them as explained in the tutorial. My code is (this function is supposed to add a call to f in bb at pos): void addCallSite(Function *f, BasicBlock *bb, BasicBlock::iterator pos)

On Oct 6, 2011, at 10:25 AM, David A. Greene wrote: > greened at obbligato.org (David A. Greene) writes: > >> So here's why I think the for loop proposal can't be a preprocessing >> phase. Down in the guts of this I fundamentally need to be able to do >> this: >> >> multiclass blah<list<int> Values> { >> for v = Values { >>

For the following code: Type * type = IntegerType::getInt32Ty(getGlobalContext()); IRBuilder<> builder(BB); std::set<Value *> Vset; Value * Vresult=0; for(std::set<Value*>::iterator Vit=Vset.begin();Vit!=Vset.end();Vit++) { Vresult=builder.CreateOr(Vit, Vresult, "WaitOr"); } Vset is inserted in previous loop by 0 or 1 The error

greened at obbligato.org (David A. Greene) writes: > So here's why I think the for loop proposal can't be a preprocessing > phase. Down in the guts of this I fundamentally need to be able to do > this: > > multiclass blah<list<int> Values> { > for v = Values { > def DEF#v : base_class<v>; > } > } > > Will that work? Is the for

On Thu, 2005-21-04 at 10:28 -0400, Vyacheslav Akhmechet wrote: > The problem is that I do not know the type of a target function at > compile time. If you consider my code example, I don't know the type > of 'i' until runtime (in fact, I can't even know a possible range of > types 'i' may assume). I don't think I properly understand what the issue is here.

I do agree that sign-extension is the right thing to do. Unlike bit-fields, llvm::PointerIntPair has asserts checking that the int value is within range. So if you assign an out of range value, it should fail with an assertion: llvm::PointerIntPair<SomeType*, 3, int> pip; pip.setInt(7); // can be made to fail as the valid range // of signed 3-bit values is [-4:3] The above code does not currently fail and instead fails for pip.setInt arguments with values in [-4:-1] which is actually unexpected and the reason I started this email th...

...iterator begin() { return iterator(ListBase::begin()); } iterator end() { return iterator(ListBase::end()); } void insert(iterator P, ListNodeBase &N) { ListBase::insert(P, N); } void erase(iterator N) { ListBase::erase(N); } }; In case it's not clear, to use `List<SomeType>`, `SomeType` has to inherit from `ListNodeBase`. There are a few nice properties here. 1. Traversal logic requires no knowledge of the downcast nodes. 2. `List<T>` owns none of the nodes (clear ownership semantics). 3. There are no branches (outside of asserts). 4. We never touch th...

Evan, The problem is that I do not know the type of a target function at compile time. If you consider my code example, I don't know the type of 'i' until runtime (in fact, I can't even know a possible range of types 'i' may assume). Thanks, - Slava. On 4/21/05, Evan Jones <ejones at uwaterloo.ca> wrote: > On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet

Hi Martin, Thank you for sending the script. I can reproduce the issue with it. It looks like the program crashes when it tries to call std::vector<sometype>'s ctor from a static initializer. I don't fully understand what is causing the issue yet, but here are my observations. - Since you are creating a temporary object file using `ld.gold -r`, your object file contains multiple weak definitions with the same name, as two or more input fi...

...oder, it is language design and not really relevant here, but I am curious on thoughts regardless). The broken (non-first, the second and on) tasklet function signature would probably just be something along the lines of: schedulerRelevantEnum aTaskletFunctionName(topOfStackOrContinuationPtr *ptr, someType ReturnValueFromFunctionBreak) Basically it would follow sabre's document in this regard pretty closely. The top most call of a tasklet function (before splitting) would not contain the return value (since something is calling it, nor would other tasklet function calls that return nothing. As...