[LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray)

Talin viridia at gmail.com
Fri May 15 17:21:16 PDT 2009


Chris Lattner wrote:
> On May 15, 2009, at 10:52 AM, Gordon Henriksen wrote:
>   
>> On 2009-05-15, at 07:26, David Greene wrote:
>>     
>>> On Friday 15 May 2009 05:50, Jay Foad wrote:
>>>       
>>>>> 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.  That's why they're there.
>>>       
>> The reason to use the pointer-length pair in preference to iterators
>> is that iterators make templates of everything, causing code bloat. In
>> my code, rather than pass the separate parameters I use a range<Iter>
>> class something like this:
>>     
>
> I tend to prefer ranges as well, but iterators don't cause bloat.   
> Just have something like this:
>   
I tend to prefer begin/end iterators (or first/last for subranges, 
following the naming conventions of STL) for things like this - if the 
argument types are declared correctly, you should be able to use 
std::vector, SmallVector, or just regular POD pointers. I tend to prefer 
iterators for the (admittedly minor) reason that converting from a 
SmallVector to a start+size pair involves taking size(), which requires 
a scaling operation, whereas converting to first/last is just a bitcast 
at most.
>    template <typename iter>
>    ... create(iter start, iter end) {
>      if (start != end)
>        return create(&*start, end-start);
>      return create(0,0);
>    }
>
> which inlines away.  This requires the iterators to be sequential in  
> memory, which is perfectly reasonable IMO.
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>   




More information about the llvm-dev mailing list