Why do we have __valarray_get_memory?

[Jonathan Wakely]

On 15/01/18 00:09 -0800, Gabriel Dos Reis wrote:
>[ sorry for the slow mail ]

And same here :-)

>On Tue, Dec 5, 2017 at 8:18 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
>
>> Does the first function here really serve any purpose?
>>
>>  // We get memory by the old fashion way
>>  inline void*
>>  __valarray_get_memory(size_t __n)
>>  { return operator new(__n); }
>>
>>  template<typename _Tp>
>>    inline _Tp*__restrict__
>>    __valarray_get_storage(size_t __n)
>>    {
>>      return static_cast<_Tp*__restrict__>
>>         (std::__valarray_get_memory(__n * sizeof(_Tp)));
>>    }
>>
>>  // Return memory to the system
>>  inline void
>>  __valarray_release_memory(void* __p)
>>  { operator delete(__p); }
>>
>> Is there any benefit to doing that, instead of just making a direct
>> call to operator new?
>>
>
>None, now.  I don't remember the exact reasons why I introduced that
>intermediate function - in the old days, one needed to be "tactical" with
>__restrict__.
>Please, feel free to fold it into its sole caller and burn it.

OK thanks.


>>
>>  template<typename _Tp>
>>    inline _Tp*
>>    __valarray_get_storage(size_t __n)
>>    { return static_cast<_Tp*>(operator new(__n * sizeof(_Tp))); }
>>
>> As I said in another thread, I don't think the __restrict__ does
>> anything there, but maybe it should use __attribute__((malloc))
>> instead.
>>
>
>Sorry, was I copied on the other thread?

No, sorry, that was this mail, about fixing warnings in our headers:
https://gcc.gnu.org/ml/libstdc++/2017-12/msg00015.html

>In any case, __attribute__((malloc)) is probably the right thing.

Thanks for the confirmation.