[macstl-dev] Questions on valarray use : non-aligned buffers

[Ilya Lipovsky]

Glen Low wrote:

>>
>>
>> How about renaming the already existing refarray into 
>> "aligned_refarray" and naming the upcoming one as "refarray". 
>> Sometimes, I think, it's necessary to break the API (which should be 
>> ok here as it's very recent) to do things right rather than be 
>> constantly confused later on.
>>
>> P.S. if not, then arbarray should do it. I don't think you want to 
>> make the names similar (for the aligned and the "unknown alignment"
>> versions), since this can confuse future novices.
>
>
> I'm hoping to eliminate some epilogue code in the next version of 
> macstl. Particular valarray expressions can stand to use all SIMD 
> instead of wasting time in the tail of the array calling scalar 
> functions -- e.g. where it can be established that there's enough 
> "slop" in the source and target arrays. This would be true of valarray 
> and statarray and all strictly parallel functions and operators, but 
> unfortunately won't be true for refarray and arbarray/ urefarray -- I 
> can't guarantee there's nothing "important" after the end of data in a 
> refarray or arbarray/urefarray. I don't want a runtime check, not just 
> because it's (slightly) slower but because I'm hoping to eventually 
> target the Cell and other embedded scenarios where non-use/non-linking 
> of the Standard Library would be an advantage.
>
> Not sure how to address that in the design of refarray. I'm now 
> thinking it'd be better to use some default template non-type params 
> (similar to policies) to do this e.g.
>
> refarray <float> -- non-aligned, no slop (the default case should be 
> the hardest to stuff up, as per Ilya's thinking)
> refarray <float, aligned, sloppy>
> refarray <float, aligned>
>
> etc.
>
> "sloppy" doesn't accurately capture what I'm thinking, I mean it's an 
> assert that the data passed in will have a length divisible by 4 (for 
> floats).
>
> What do you think?
>
>
Maybe "native" is better? Some kind of an enum type of variable, perhaps?

-Ilya