llvm dev - Jul 2007 - [LLVMdev] API design (and Boost and tr1)

On Wednesday 04 July 2007 14:57, Chris Lattner wrote:
> >  template<typename InputIterator>
> >  CallInst(Value *Func, InputIterator ArgBegin, InputIterator ArgEnd,
> >           const std::string &Name = "", Instruction
*InsertBefore = 0,
>
> Is it acceptable to just make the template argument be the container?
> That way you could pass:
>
> std::vector.. V;
> ...
>
> new CallInst(Callee, V, "foo");
>
> etc.  The disadvantage is that you lose the ability to pass a subrange.
> However, if you know you're using a subrange, you should be able to use
> another ctor form.
I have to think about this a bit but one complication is that clients aren't
always using std-like containers.  There are several places that look like
this:

   Value *array = { v1, v2, v3, v4};
   blah = new CallInst(...,&array[0], 4,...);

Since array doesn't have begin/end members we'd need some kind of 
specialization for that case.  Iterators nicely avoid this issue.

I agree that the SFINAE technique is complicated and esoteric.  I'd rather 
find something more intuitive.  But then again, it is the way "modern
C++" is
heading.  It's actually a quite common technique in C++ generic programming.
So it's not really so out of the mainstream.

                                     -Dave

On Wed, 4 Jul 2007, David A. Greene wrote:
> I have to think about this a bit but one complication is that clients
aren't
> always using std-like containers.  There are several places that look like
> this:
>
>   Value *array = { v1, v2, v3, v4};
>   blah = new CallInst(...,&array[0], 4,...);
>
> 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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

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