search for: value_type

Akshay Jain <jivan.molu at gmail.com> writes: > I have tried it, but I always end up with some kind of error. Can you > explain how can I get a function type for function which returns void > (nothing) and it's arguments are (int, int, int, void *, void *, ...) ?? Instead of getting something to cut&paste, you would be much more enriched if the problematic code and the

On Wed, May 5, 2010 at 5:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: >> >> The logic to handle this has to go somewhere, putting it in the MCStreamer >> *implementation* that needs it is the most logical place.  We also aim to >> implement an assembler, it doesn't make sense to duplicate this

On Friday 15 May 2009 05:50, Jay Foad wrote: > > 3. Any comments on the patch itself? > > > > The one major thing to be aware of is that it isn't safe to use &V[0] > > when V is an empty std::vector > > Oh dear. That's a bit of a flaw in the plan. I suppose the solution is > to switch to SmallVector whenever this might be a problem. Or use iterators.

Full_Name: Alexander L. Belikoff Version: 2.8.1 OS: Ubuntu 9.04 (x86_64) Submission from: (NULL) (67.244.71.200) I'm trying to reshape the following data frame: ID DATE1 DATE2 VALUE_TYPE VALUE 'abcd1233' 2009-11-12 2009-12-23 'TYPE1' 123.45 ... VALUE_TYPE is a string and is a factor with only 2 values (say TYPE1 and TYPE2). I need to transform it into the following data frame ("wide" transpose) based on common ID and DA...

I have tried it, but I always end up with some kind of error. Can you explain how can I get a function type for function which returns void (nothing) and it's arguments are (int, int, int, void *, void *, ...) ?? Thanks in advance. On Tue, Apr 16, 2013 at 7:22 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Akshay Jain <jivan.molu at gmail.com> writes: > > > I am

...atching function for call to ‘std::vector<llvm::Type*>::push_back(const llvm::IntegerType*) const’ /home/akshay/llvm/llvm-2.9/lib/Transforms/AliasPass/pass2.cpp:108:62: note: candidate is: /usr/include/c++/4.6/bits/stl_vector.h:826:7: note: void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = llvm::Type*, _Alloc = std::allocator<llvm::Type*>, std::vector<_Tp, _Alloc>::value_type = llvm::Type*] <near match> /usr/include/c++/4.6/bits/stl_vector.h:826:7: note: no known conversion for argument 1 from ‘const llvm::IntegerType*’ to ‘llvm::Type* const&...

On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: > > The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > > Assembly language has often been *the* intermediate

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 advance_end(difference_type n) Would you be open to those? -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attach...

...egin()), End(seq.end()) { } Iter begin() { return Begin; } Iter end() { return End; } // ... other Sequence methods ... }; And encapsulate the logic to deal with the empty sequence problem in a function: template<typename ConvertibleToRange> range<typename ConvertibleToRange::value_type*> ptr_range(ConvertibleToRange &seq) { typename ConvertibleToRange::iterator i = seq.begin(), e = seq.end(); if (i == e) return range<typename ConvertibleToRange::value_type*>(); return range<typename ConvertibleToRange::value_type*>(&*i, &*i + (e - i)); }...

> 3. Any comments on the patch itself? > > The one major thing to be aware of is that it isn't safe to use &V[0] when V > is an empty std::vector Oh dear. That's a bit of a flaw in the plan. I suppose the solution is to switch to SmallVector whenever this might be a problem. I'm a bit concerned that any new &empty[0] problems that are introduced will go unnoticed.

...Ty.getAsOpaquePtr(), TC)); ~~~~~~~~~~~^~~~~~~~~ /usr/include/c++/v1/vector:676:36: note: candidate function not viable: no known conversion from 'pair<typename __make_pair_return<void *>::type, typename __make_pair_return<DIType &>::type>' to 'const value_type' (aka 'const std::__1::pair<void *, llvm::WeakVH>') for 1st argument; _LIBCPP_INLINE_VISIBILITY void push_back(const_reference __x); ^ /usr/include/c++/v1/vector:678:36: note: candidate function not viable: no known conversion from...

...k together a custom vector-like object with the >> "small string" optimization. > > Not important, but I'm missing something: what're you picturing that > would be different from/better than SmallVector? > Data storage would be: struct Data { struct value_type { unsigned Tag; TrackingMDNodeRef MD; }; unsigned Capacity; union { unsigned LargeSize; unsigned SmallTag; } Unsigned; AlignedCharArrayUnion< value_type *, // LargeArray TrackingMDNodeRef // SmallMD &...

...<Instruction*>, Yea, I've noticed that. However, it looks like inst_iterator is iterator over pointers. Oh, wait a minite, that's the current code: inline IIty operator*() const { return BI; } inline IIty operator->() const { return operator*(); } So operator* works as if value_type is Instruction*, but operator-> works as if value_type is Instruction. Hmm ;-) > so it's not possible to just assign a new > instruction* through an iterator. In other words: *iit = new > Instruction(...) doesn't make any sense. > > Probably the right thing to do would...

...> >> "small string" optimization. > > > > Not important, but I'm missing something: what're you picturing that > > would be different from/better than SmallVector? > > > > Data storage would be: > > struct Data { > struct value_type { > unsigned Tag; > TrackingMDNodeRef MD; > }; > > unsigned Capacity; > union { > unsigned LargeSize; > unsigned SmallTag; > } Unsigned; > > AlignedCharArrayUnion< > value_type *, //...

..., I've noticed that. However, it looks like inst_iterator is iterator over > pointers. Oh, wait a minite, that's the current code: > > inline IIty operator*() const { return BI; } > inline IIty operator->() const { return operator*(); } > > So operator* works as if value_type is Instruction*, but operator-> works as > if value_type is Instruction. Hmm ;-) Yeah, fishy huh? :) > > Probably the right thing to do would be to make the inst_iterator return a > > reference to the *instruction* itself, rather than a reference to the > > pointer. This...

...ol pop3 { ??? mail_plugins = $mail_plugins last_login ... } And dovecot-last-login.conf: connect = host=127.0.0.1 port=3306 dbname=vmail user=vmailadmin password=xxxxxxxxxxxxxxxxxx map { ??? pattern = shared/last-login/$user/$domain ??? table = last_login ??? value_field = last_login ??? value_type = uint ??? fields { ??????? username = $user ??????? domain = $domain ?????? rip = $rip ??? } } And the table criated in mysql: CREATE TABLE IF NOT EXISTS `last_login` ( ??? `username` VARCHAR(255) NOT NULL DEFAULT '', ??? `domain` VARCHAR(255) NOT NULL DEFAULT '', ??? `...

...> >> "small string" optimization. > > > > Not important, but I'm missing something: what're you picturing that > > would be different from/better than SmallVector? > > > > Data storage would be: > > struct Data { > struct value_type { > unsigned Tag; > TrackingMDNodeRef MD; > }; > > unsigned Capacity; > union { > unsigned LargeSize; > unsigned SmallTag; > } Unsigned; > > AlignedCharArrayUnion< > value_type *, //...

Hi, I'm part of an engineering team doing research on persistent memory support and we have stumbled upon an interesting problem. The issue is, we would like to be able to use the standard library containers in a persistent memory context (think NVDIMM-N). What I mean is that you allocate a container from said memory, use it like you normally would. After the application terminates, expectedly

.../ADT/StringRef.h:13: /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/STLExtras.h:139:13: error: no type named 'type' in 'std::__1::result_of<std::__1::pointer_to_unary_function<llvm::DSNode *, llvm::DSNode &> (llvm::DSNode &)>' ::type value_type; ~~^~~~ /Users/jaredcarlson/Projects/crab-llvm/dsa-seahorn/include/dsa/DSGraphTraits.h:122:25: note: in instantiation of template class 'llvm::mapped_iterator<llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::DSNode, true, false, void>, false, false>, st...

...rrors: table is not writable, INSERT failed. Why is the insert required? The plugin should only UPDATE the column for existing rows. Or am i missing some configuration options? Here is my dictionary config: map { pattern = shared/last-login/$user table = mailbox value_field = x_last_login value_type = uint fields { username = $user } } Dovecot: 2.2.27 (c0f36b0) Kind regards, Thomas