search for: createwithargrang

...thing consistent. That sounds reasonable. Please keep the "Value* + num elements" ctor as well though. Here's another crazy idea. Instead of overloading the callinst ctor, why not just add a static function to create the call (like binaryoperator and friends): C = CallInst::CreateWithArgRange(X, B, V.begin(), V.end()); That way you can completely avoid the overloading issues. -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Thursday 05 July 2007 11:54, Chris Lattner wrote: > Here's another crazy idea. Instead of overloading the callinst ctor, why > not just add a static function to create the call (like binaryoperator and > friends): > > C = CallInst::CreateWithArgRange(X, B, V.begin(), V.end()); > > That way you can completely avoid the overloading issues. What's the relationship of this idea to LLVMBuilder? -Dave

...ass Value, Value+num). I'd rather not maintain two interfaces with identical semantics. > Here's another crazy idea. Instead of overloading the callinst ctor, why > not just add a static function to create the call (like binaryoperator and > friends): > > C = CallInst::CreateWithArgRange(X, B, V.begin(), V.end()); > > That way you can completely avoid the overloading issues. That's not a bad idea. In fact, we ought to think about creating factories for everything. Bare new/delete usually comes back to haunt one later on. I'll get what I've got working and che...

On Wednesday 04 July 2007 22:37, David A. Greene wrote: > On Wednesday 04 July 2007 15:46, Chris Lattner wrote: > > > Since array doesn't have begin/end members we'd need some kind of > > > specialization for that case. Iterators nicely avoid this issue. > > > > We should just keep the existing constructor, so this isn't a problem. > > These

...second step is to migrate clients, third step is to remove the old one. >> Here's another crazy idea. Instead of overloading the callinst ctor, why >> not just add a static function to create the call (like binaryoperator and >> friends): >> >> C = CallInst::CreateWithArgRange(X, B, V.begin(), V.end()); >> >> That way you can completely avoid the overloading issues. > > That's not a bad idea. In fact, we ought to think about creating factories > for everything. Bare new/delete usually comes back to haunt one later on. Yep, I agree. > I...

On Wednesday 04 July 2007 15:46, Chris Lattner wrote: > > Since array doesn't have begin/end members we'd need some kind of > > specialization for that case. Iterators nicely avoid this issue. > > We should just keep the existing constructor, so this isn't a problem. > These clients don't have the "dereference end" problem. Duh. Yep, ok, this