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 sounds good. -Dave
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 clients don't have the "dereference end" problem. > > Duh. > > Yep, ok, this sounds good.Grr. That's no so easy either, because it conflicts with the one-argument specialized constructor. Either I have to write separate constructors for std::vector<ValType> and SmallVector<ValType, Size> or I take an alternate approach. I've opted for the alternate approach: make all clients pass iterators. That is, get rid of the specialized one- and two-argument constructors entirely. This gets rid of all of these headaches while at the same time reducing code size and maintenance costs. It does require that clients store their arguments in an array of some sort, but it's probably not a bad tradeoff. It at least makes everything consistent. What do you think? -Dave
On Thursday 05 July 2007 11:35, David Greene wrote:> I've opted for the alternate approach: make all clients pass iterators. > That is, get rid of the specialized one- and two-argument constructors > entirely.Actually, I just got rid of the two-argument version, because that's the one that interference with the iterator template version. -Dave
On Thu, 5 Jul 2007, David Greene wrote:>>> 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 sounds good. > > Grr. That's no so easy either, because it conflicts with the one-argument > specialized constructor. > > Either I have to write separate constructors for std::vector<ValType> and > SmallVector<ValType, Size> or I take an alternate approach. > > I've opted for the alternate approach: make all clients pass iterators. That > is, get rid of the specialized one- and two-argument constructors entirely. > > This gets rid of all of these headaches while at the same time reducing code > size and maintenance costs. It does require that clients store their > arguments in an array of some sort, but it's probably not a bad tradeoff. > It at least makes everything 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/