Date: Sun, 10 Nov 2024 12:51:17 +0000
On Sun, 10 Nov 2024 at 11:47, André Offringa via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 10/11/2024 12:02, Jonathan Wakely wrote:
>
>
> On Sun, 10 Nov 2024, 10:54 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>
>>
>> On Sun, 10 Nov 2024, 10:06 André Offringa via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Dear all,
>>>
>>> I'd like to float the idea to make it possible to construct a
>>> std::complex and a std::vector uninitialized. [..]
>>>
>>> std::ifstream file("myfile.bin");
>>> std::vector<char> buffer(buffer_size);
>>> file.read(&buffer[0], buffer_size);
>>>
>>
>> This is exactly the use case that string::resize_for_overwrite solves. I
>> think there is already a proposal to add a similar function to vector.
>>
>> The committee has seen lots of proposals for a tag that says to leave a
>> container uninitialised, and has always decided we don't want that because
>> it's too error-prone and risky.
>>
>
> Actually I misremembered, there was support for a tag type, but
> resize_for_overwrite was preferred for string. See the discussion in
>
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r10.html#alternatives
>
>
> Thanks for the response and the link, nice to see there seems support.
>
> Has the complex type ever been mentioned in such discussions? Imho it is
> currently a more fundamental problem that can't be worked around. It might
> be simpler to solve since there's no allocator involved. For complex I also
> don't see a way around a tag, which might be another reason to introduce
> such a tag.
>
Do you really care about the cost of initializing one std::complex variable?
Surely it's only a problem when initializing large arrays or containers or
std::complex? So if std::vector allowed you to avoid the default
initialization of its lements, then std::vector<std::complex<double>>
would be able to avoid initializing any std::complex values until you need
them. No changes to std::complex are required.
N.B. I think std::bit_cast<std::complex<double>> already allows you to get
a std::complex<T> from T[2], and std::start_lifetime_as might do too. So
the problems you describe with reinterpret_cast can be avoided, by not
using reinterpret_cast. There are better tools for what you want to do
there.
>
> Also, do you happen to have a link to report where the discussion for
> vector takes place?
>
ISO meeting discussions are not publicly available, sorry.
>
> I had seen the method name resize_and_overwrite() but I had not realized
> it was intended to solve this problem. It doesn't have an easy name...
>
That's intentional, because it's easy to misuse and create undefined, so it
should require a verbose and non-ergonomic name, so that people only use it
when they really need it and they know what they're doing.
> But if vector had it, it would solve the problem I have. It's imho not as
> readable as a tag constructor but still a good solution.
>
> Regards,
> André
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> On 10/11/2024 12:02, Jonathan Wakely wrote:
>
>
> On Sun, 10 Nov 2024, 10:54 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>
>>
>> On Sun, 10 Nov 2024, 10:06 André Offringa via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Dear all,
>>>
>>> I'd like to float the idea to make it possible to construct a
>>> std::complex and a std::vector uninitialized. [..]
>>>
>>> std::ifstream file("myfile.bin");
>>> std::vector<char> buffer(buffer_size);
>>> file.read(&buffer[0], buffer_size);
>>>
>>
>> This is exactly the use case that string::resize_for_overwrite solves. I
>> think there is already a proposal to add a similar function to vector.
>>
>> The committee has seen lots of proposals for a tag that says to leave a
>> container uninitialised, and has always decided we don't want that because
>> it's too error-prone and risky.
>>
>
> Actually I misremembered, there was support for a tag type, but
> resize_for_overwrite was preferred for string. See the discussion in
>
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r10.html#alternatives
>
>
> Thanks for the response and the link, nice to see there seems support.
>
> Has the complex type ever been mentioned in such discussions? Imho it is
> currently a more fundamental problem that can't be worked around. It might
> be simpler to solve since there's no allocator involved. For complex I also
> don't see a way around a tag, which might be another reason to introduce
> such a tag.
>
Do you really care about the cost of initializing one std::complex variable?
Surely it's only a problem when initializing large arrays or containers or
std::complex? So if std::vector allowed you to avoid the default
initialization of its lements, then std::vector<std::complex<double>>
would be able to avoid initializing any std::complex values until you need
them. No changes to std::complex are required.
N.B. I think std::bit_cast<std::complex<double>> already allows you to get
a std::complex<T> from T[2], and std::start_lifetime_as might do too. So
the problems you describe with reinterpret_cast can be avoided, by not
using reinterpret_cast. There are better tools for what you want to do
there.
>
> Also, do you happen to have a link to report where the discussion for
> vector takes place?
>
ISO meeting discussions are not publicly available, sorry.
>
> I had seen the method name resize_and_overwrite() but I had not realized
> it was intended to solve this problem. It doesn't have an easy name...
>
That's intentional, because it's easy to misuse and create undefined, so it
should require a verbose and non-ergonomic name, so that people only use it
when they really need it and they know what they're doing.
> But if vector had it, it would solve the problem I have. It's imho not as
> readable as a tag constructor but still a good solution.
>
> Regards,
> André
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-11-10 12:52:37