RFR: 8319117: GrowableArray: Allow for custom initializer instead of copy constructor
Quan Anh Mai
qamai at openjdk.org
Tue Oct 31 10:14:30 UTC 2023
On Tue, 31 Oct 2023 10:01:26 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:
>> Hi,
>>
>> When using at_put and at_put_grow you can provide a value which will be supplied to the constructor of each element. In other words, you can intialize each element through a copy constructor.
>>
>> I suggest that we also provide a function equivalent where the function is provided a pointer to the memory to be initialized. This can be used for `NONCOPYABLE` classes, for example.
>>
>> This is implemented using a SFINAE pattern because `nullptr` introduces ambiguity if you use static overload.
>>
>> Currently running tier1-tier4.
>
>> I think a more preferable approach is to do emplace-like filling
>>
>> ```
>> template <class... Args>
>> E& at_grow(int i, Args... args) {
>> assert(0 <= i, "negative index %d", i);
>> if (i >= this->_len) {
>> if (i >= this->_capacity) {
>> grow(i);
>> }
>> for (int j = this->_len; j <= i; j++) {
>> _data[j].~E();
>> new (&_data[j]) E(args...);
>> }
>> this->_len = i + 1;
>> }
>> return _data[i];
>> }
>> ```
>
> I think you might be right. If I understand this correctly we can pick between copy construction (having `Args` be equal to `E`) and "regular" construction depending on the arguments provided?
>
> @stefank, @dean-long. Re: tests, yes, I should add tests. The goal here is to avoid copy construction, and I chose to provide a function so that you can yourself pick how to initialize the memory. I think @merykitty's solution might be preferable to mine.
@jdksjolen Yes you are right, note that the idiom for standard C++ looks like this
template <class... Args>
void emplace(Args&&... args) {
call(std::forward<Args>(args)...);
}
And I'm not really sure what this would become without move semantics.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16409#issuecomment-1786906761
More information about the hotspot-dev
mailing list