This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Why do we have __valarray_get_memory?
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, Gabriel Dos Reis <gdr at axiomatics dot org>
- Date: Mon, 15 Jan 2018 00:09:17 -0800
- Subject: Re: Why do we have __valarray_get_memory?
- Authentication-results: sourceware.org; auth=none
- References: <20171205161814.GF31922@redhat.com>
[ 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