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?


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.



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