Date: Wed, 13 Dec 2023 17:13:43 -0300
On Wednesday, 13 December 2023 07:21:11 -03 Frederick Virchanza Gotham via
Std-Proposals wrote:
> (1) Reading fields from a header from a file or network card
> (2) Conserving RAM / EEPROM
>
> On a desktop PC, if you had a million strings in a vector, you could
> possibly instead use an 'unaligned_vector' which would wrap T in 'aligned'.
I don't think this is a reasonable requirement.
Compacting data is fine if you want to store it on disk or other mass storage,
even though you usually have far more of that than of RAM. And then it may
make sense to have an on-disk format that matches the in-memory, thus making
it case (1).
But this means you don't have pointers and you may not have random iteration
either. Fast memory access and packing/unaligned are incompatible
requirements.
> This would save some space if std::string has any tail padding.
It doesn't, in the three big Standard Library implementations. I'd question
the quality of any implementation that did, given just how often those types
are used.
> Of course though if we were to have an object of 'packed_str', it would
> need to be memcpy'd back to an std:: string before performing any operation
> on it.
Which makes this DoA because you need a copy constructor to keep the validity.
libstdc++'s C++11 std::string contains a pointer that points back to the
object, so this std::string isn't trivially relocatable.
If you were trying to conserve memory on C strings, you would use just the
char pointer, not a std::string. The length does not need to be stored if it
can be recalculated and you don't need to keep the allocator or the capacity
either. Removing the allocator and the capacity would probably meet your
design goals of reducing memory, without needing to remove the length too.
Therefore, I find that the use-case is a non-starter. If you want to reduce
memory consumption, you don't use arbitrary types provided by the Standard
Library that are designed to be fast.
Std-Proposals wrote:
> (1) Reading fields from a header from a file or network card
> (2) Conserving RAM / EEPROM
>
> On a desktop PC, if you had a million strings in a vector, you could
> possibly instead use an 'unaligned_vector' which would wrap T in 'aligned'.
I don't think this is a reasonable requirement.
Compacting data is fine if you want to store it on disk or other mass storage,
even though you usually have far more of that than of RAM. And then it may
make sense to have an on-disk format that matches the in-memory, thus making
it case (1).
But this means you don't have pointers and you may not have random iteration
either. Fast memory access and packing/unaligned are incompatible
requirements.
> This would save some space if std::string has any tail padding.
It doesn't, in the three big Standard Library implementations. I'd question
the quality of any implementation that did, given just how often those types
are used.
> Of course though if we were to have an object of 'packed_str', it would
> need to be memcpy'd back to an std:: string before performing any operation
> on it.
Which makes this DoA because you need a copy constructor to keep the validity.
libstdc++'s C++11 std::string contains a pointer that points back to the
object, so this std::string isn't trivially relocatable.
If you were trying to conserve memory on C strings, you would use just the
char pointer, not a std::string. The length does not need to be stored if it
can be recalculated and you don't need to keep the allocator or the capacity
either. Removing the allocator and the capacity would probably meet your
design goals of reducing memory, without needing to remove the length too.
Therefore, I find that the use-case is a non-starter. If you want to reduce
memory consumption, you don't use arbitrary types provided by the Standard
Library that are designed to be fast.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-12-13 20:13:49