On Mon, 4 Jan 2021 09:41:01 GMT, Kim Barrett <kbarr...@openjdk.org> wrote:
>> I suppose the constructor would be invoked before the copy assignment
>> operator. That is `_vdui` gets initialized already in the ctor
>> `DUIterator_Fast()` for `operator=` case. Right?
>> Take the following code snippet as an example.
>> DUIterator_Fast t1, t2;
>> t2 = t1; // assignment operator
>> DUIterator_Fast t3 = t1; // copy constructor. same as "t3(t1)"
>> My point is that, the ctor for `t2` has already invoked, i.e. initializing
>> `_vdui` as false. That's why `operator=` works well.
>>
>>
>> Yes. For our newly-added copy constructor for `DUIterator_Fast`, we should
>> initialize `_vdui` as `false`. It may be defined as below.
>> DUIterator_Fast(const DUIterator_Fast& that)
>> { _outp = that._outp; debug_only(_vdui = false;
>> reset(that)); }
>
> That's true on the first assignment of `t2`. But what if `t2` is reassigned
> to some other iterator. That assignment sees `_vdui` true, and keeps the old
> value of `_last` rather than updating the value from that other iterator. Is
> that really correct? It certainly seems strange. I'm trying to find someone
> who understands this code to get involved, but holidays.
Thanks for your explanation. Yes, you're right. I didn't realize the
re-assignment scenario.
However, I noticed that there does NOT exist such re-assignment cases.
Simply grep `= DUIterator_Last(` and `= DUIterator_Fast(`.
Is there anything I missed?
-------------
PR: https://git.openjdk.java.net/jdk/pull/1874
