Increase usefulness of InlinedVector about abseil-cpp

[derekmauro]

I don't think we've ever hit upon that specific use case.

Have you looked at absl::Span? It isn't exactly what you are looking for, but you can use it as a function parameter to accept a view into generic array data. It isn't specific to vector (so there is no push_back() method, for instance), but it might work depending on your use case.

[stayprivate]

That would only work if the objet is read only. In my example, foo() could grow the vector to size beyond the initial capacity, moving data from the stack to the heap.A span would definitely not apply here.

[derekmauro]

I feared that was the case. Sounds like something @JonathanDCohen could consider as an enhancement to InlinedVector.

[tituswinters]

The contents of Span are mutable - if you need to grow beyond the input Span into a vector (moving data from stack to heap) that's doable, no?

Or is the point that you want to actually resize the underlying vector/InlineVector?

[stayprivates]

The content is mutable ok, but all the capability of InlinedVector, like resizing are lost. I don't see how the function using the Span is able to grow it safely, given that if it goes over the threshold that data is moved around. And all while keeping the InlinedVector object valid?

[JonathanDCohen]

You can't grow the vector through a Span. However, I'll pint out that even if we used a proxy template Impl class, we make no guarantees about the stability of internal APIs and wouldn't support clients making functions with the kind of signature you suggest.

Typically for this I'll do something like

template <typename Vector>
void foo(Vector* v) {}

if you need push_back, emplace_back, etc, or just

void foo(Span<int> v) {} if you just need access to the data.

[stayprivates]

Johathan,

You seems to suggest that because I refered to an "Impl" class, that is it part of the internal API, but that does not have to be the case. I should have you a different name ;-) Check what llvm has to say about SmallVectorImpl:

Even though it has "Impl" in the name, this is so widely used that it really isn't "private to the implementation" anymore. A name like SmallVectorHeader would be more appropriate.

As for:

template <typename Vector>
void foo(Vector* v) {}

I fail to see how the implementation of foo can compile without knowing about Vector, which would be "impossible" if foo is provided as an API/library.

The more I think about it the more I see that if I was to write new code, I would not need that feature that much. But what I,m trying to do is switching from std::vector/llvm::SmallVector to InlinedVector, with as little change as possible in existing code. It's when the InlinedVector is passed by referenced as an output that I hit a wall.

I'm mostly surprise that no one ever saw the need for this in something like absl, which makes me doubt my own sanity, lol!

Thanks for the feedback!

[JonathanDCohen]

Let me make sure we're on the same page -- you're worried about if foo() was provided as an interface in a precompiled library. Then there's no way the compiler could generate foo<InlinedVector<MyType, N>>.

That's a case we don't really hit at Google because we compile everything from source and use static linking for most of our binaries.

[stayprivates]

There is that, yet but most importantly for me, don't want to force anyone using InlineVector in their API to force usage of template on their user.

Also, unfortunately we don't have access to a compiler farm to build stuff quickly, so cutting down on recompile, dependancies and stuff is of importance.

Thanks.