`Option<Vec>` without freeing memory when setting to `None`

[chrefr]

I have a struct member vector that might be presented and might not. The obvious choice is to put it behind Option.

But if I do that, when I'll set the option to None, I'll free the vector. The next time it will have to be re-allocated.

This is bad. I want to re-use the capacity from the previous time.

I can build a container that does that, but is there a built-in way to do this?

[2e71828]

You can use Option::take() to get the old value of the vector and store it somewhere for reuse, and Vec::clear() to empty the vector without reducing its capacity.

[nologik]

How do you plan on using the Vector?

[chrefr]

Exactly like the previous time; I process input and in some parts of it I need access to the vector.

[chrefr]

I can also store the vector without Option and also store a boolean indicating whether the vector is accessible; However, I don't want to manually deal with storing/restoring the vector.

[2e71828]

@chrefr

I process input and in some parts of it I need access to the vector.

Have you considered having a different type for each state your algorithm can be in that only has the fields valid in that state?

@chrefr

I don't want to manually deal with storing/restoring the vector.

Well, that’s the global allocator’s job; if you don’t like how it behaves, you either need to implement the alternative manually or find a crate that does.

[chrefr]

@2e71828

Have you considered having a different type for each state your algorithm can be in that only has the fields valid in that state?

This doesn't work this way. I don't have other data accessible for each state (then I could define an enum), but instead data that is always available and data that's available based on certain conditions (that may overlap).

@2e71828

Well, that’s the global allocator’s job; if you don’t like how it behaves, you either need to implement the alternative manually or find a crate that does.

I don't understand what you say, I replied to your idea:

@2e71828

You can use Option::take() to get the old value of the vector and store it somewhere for reuse, and Vec::clear() to empty the vector without reducing its capacity.

And said that using this way I'll have to manually store the vector in a different field and keep track on where it's available.

[chrefr]

@nologik, That's exactly why I said I can implement it myself but looking for a built-in way

[2e71828]

My point was that, aside from exceptional situations, giving the vector’s memory back to the allocator when you’re not using it and allocating a new one when you need it again is performant enough.

If your situation is one of the exceptional ones, it’s unreasonable to expect to not write at least some memory-management code specific to your use case. And writing a thin wrapper around a 2-field struct isn’t that much effort in the grand scheme of things.

[chrefr]

Got it