[Vt] Add iterator construction for arrays.

[superfunc]

Discussed this one offline with @gitamohr , seems like a nice addition. Its useful
for us when constructing VtArrays from foreign data sources (Maya APIs, etc) which
return T*s or vector<T>s.

Description of Change(s)

VtArray mimics much of std::vector's interface. This adds
iterator construction, which had been previously omitted.
In the past, VtArray supported dimensions, which made such
construction unwieldy; it is now a flat container, making
this a viable option.

Fixes Issue(s)

• None filed

[jtran56]

Filed as internal issue #USD-4809.

[c64kernal]

Hey @superfunc here's the feedback for this one:

• The constructor needs to be properly constrained so it's not ambiguous with the (size_t, value_type)
  constructor when value_type is integral. It should behave the same as
  the std::vector ctors.

• It should accept "LegacyInputIterators" not just ForwardIterators.

• It should be written to avoid filling the array with default-initialized values only to destroy and overwrite them immediately.

Thanks!

[superfunc]

Hey @c64kernal for the third note, I may just not be seeing it, as far as I can tell its the same way other constructors are doing this, e.g.

289     /// Initialize array from the contents of a \p initializerList.                                                     
290     VtArray(std::initializer_list<ELEM> initializerList)                                                                
291         : VtArray() {                                                                                                   
292         assign(initializerList);                                                                                        
293     }

Its calling into the VtArray() constructor which just does _data(nullptr) as far as I can tell.

[c64kernal]

Hey @superfunc -- no worries about the 3rd point, I'll file an internal bug to address that, as you point out, the rest of the constructors have the same issue.

[superfunc]

Ok, I think that should fix it, @c64kernal . Sorry the template constraint is so ugly, didn't know another way to do it haha.

[c64kernal]

Hi @superfunc -- apologies on the delay on this one, but I had a hard time getting it to compile in our environment and needed to find time to figure it out. I fixed the is_same<size_t,...> check with is_integral<...> because is_same<size_t,...> doesn't quite catch all the cases. Also had to change a use of auto in the test that was breaking on strict builds.

Thanks again for PR, should be merged on the next push.

[superfunc]

Thanks for poking at this, sorry I've been too swamped to clean it up properly.