> Right, but in this case why not put capacity at the end where
`push_back` try access memory? :D

Or even better: place the capacity right before the beginning of the array... But wait, the specification of the array form of the _new expression_ already gives permission to call operator new[] with an additional overhead to hold the size of the array and put it right before the array (at least for non trivially destructible types). So we likely already have this piece of data somewhere.

What we are missing is a standard way to access this information. At least we should have a member function `size()` in std:: unique_ptr<T[]> if the allocation overhead is available. That way we would have to manually keep track of the number of elements.



-------- Original Message --------
From: Marcin Jaczewski via Std-Discussion <std-discussion_at_[hidden]>
Sent: April 14, 2026 10:30:41 a.m. EDT
To: Jan Schultke <janschultke_at_[hidden]>
Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>, std-discussion_at_[hidden]
Subject: Re: [std-discussion] Size of heap allocated array

wt., 14 kwi 2026 o 16:11 Jan Schultke <janschultke_at_[hidden]> napisał(a):
>
>
>>
>> Real usage for me of this feature would be reduce size of
>> `std::vector` as in this case you could avoid `capacity` duplication
>> in vector.
>> Of corse this will work only if allocator used `new[]` instead other
>> manual handling, but even in this case allocator should perhaps know
>> how big array is?
>
>
> Any container can already do this by rebinding and putting additional header information in front of the allocation. However, it's more work and means that accessing the capacity requires memory indirection, which probably slows down operations like push_back that need to check whether the capacity is sufficient.
>

Right, but in this case why not put capacity at the end where
`push_back` try access memory? :D
```
cap = *(int*)&data[size];
```
bit hackly but only touches the same cache region as the rest of
`push_back` code.

>
>>
>> Another case is recent `std-big-int` discursion on proposal mailing
>> list and its reference implantation:
>> https://github.com/eisenwave/std-big-int
>>
>> where we have members like:
>> ```
>> std::uint32_t m_capacity; //
>> 0 = static storage, >0 = heap capacity
>> std::uint32_t m_size_and_sign; //
>> bit 31 = sign, bits 0-30 = limb count
>> data_type m_storage;
>> BEMAN_BIG_INT_NO_UNIQUE_ADDRESS allocator_type m_alloc;
>> ```
>> Idea was if we have static storage then `m_capacity` is pointless, if
>> we have heap then it could be on heap too.
>> But then if its on heap do it not already have this value to handle `delete[]`?
>
>
> It's not pointless; it's a trade-off. In the 64-bit case, removing the capacity here is also buying you no size reduction because m_storage is aligned to 64 bits anyway, so you'd end up with a 32-bit size and 32 bits of padding.
>
> In the 32-bit case, it's not so obvious, but having direct and unconditional access to the capacity buys you something.

Ok, probably in the case of a tagged pointer it could make more sense
to try to compress it.

-- 
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
-- Julien Villemure
Sent from my Android device with K-9 Mail.