This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why do we have __valarray_get_memory?


[ sorry for the slow mail ]

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.


>
>  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?
In any case, __attribute__((malloc)) is probably the right thing.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]