C++ Logo

std-proposals

Advanced search

Re: [std-proposals] copy constructor of std::vector

From: Federico Kircheis <federico_at_[hidden]>
Date: Tue, 13 Jun 2023 19:31:36 +0200
On 13/06/2023 19.12, Thiago Macieira via Std-Proposals wrote:
> On Tuesday, 13 June 2023 08:19:56 PDT Federico Kircheis via Std-Proposals
> wrote:
>>> This will fix nothing, as the vector needs to behave the same
>>> whether the type is forward declared or not. You do not control it
>>> as in some TU it will use forward declared type and in others it will not.
>>> You will get multiple ODR problems where you check this condition.
>>
>> I am not sure I get your point.
>>
>> The behavior of vector would not change, as "auto s2 = s1;" would
>> continue not to compile.
>
> You didn't get the point.
>
> There's an ODR violation because the expansion differed when it was forward-
> declared versus when it wasn't.
>
> std::is_copy_assignable_v<vector<ForwardDeclared>> necessarily has to be true,
> because it can't know whether ForwardDeclared is copy-assignable or not. That
> means code in one TU will make use of that true, whereas in another TU it
> might already be false and go down a different code path.
>
> Plus, there's the case when ForwardDeclared is declared in this TU, but later
> than this point here. So the value changes from true to false within one TU,
> but only with some compilers (the Standard does allow reaching the end of the
> TU before beginning the template instantiation and I know of one compiler that
> uses that).
>

OK, I see your point....

Is there no situation where we can talk only about types where we know
if those are not copyable? (I fear I know the answer)

For example std::vector<std::unique_ptr<T>>, no matter what T is.

(every time I get the error I cannot copy some class that has a
copy-constructor is because there is somewhere a vector of unique_ptr of
something as member variable...)

Obviously whitelisting types is not a scalable approach...

Received on 2023-06-13 17:31:43