Re: [boost] C function adaptor.

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-04-20 20:35:17

AMDG

Rene Rivera <grafikrobot <at> gmail.com> writes:

> 
> struct tag
> {
>    boost::mutex lock;
> };
> 
> tag tag_;
> 
> void f(int (&array)[100][3], unsigned key_index)
> {
>    assert(key_index < 3);
>    boost::mutex::scoped_lock l(tag_.lock);
>    std::qsort(array,100,sizeof(int[3]),
>      make_c_function<tag,void(const void*,const void*)>(
>        ll::static_cast_≤const int*>(_1)[key_index] <
>        ll::static_cast_≤const int*>(_1)[key_index]));
> }
> 
> Not that the use case makes any sense to me  So I'm still guessing as 
> to what you want to achieve with thread safety here.

That's basically what I said needs to be done:
retain the lock until you are done with the
function.  The critical section is now way
bigger than I would like.  The only way I know
to avoid this is to create a fixed pool of functions
and have an additional routine that releases a
function pointer so that it can be safely reused.

struct tag {};

void f(int (&array)[100][3], unsigned key_index)
{
   assert(key_index < 3);
   void (*f)(const void*,const void*) =
     make_c_function<tag,void(const void*,const void*)>(
       ll::static_cast_<const int*>(_1)[key_index] <
       ll::static_cast_<const int*>(_1)[key_index]);
   std::qsort(array,100,sizeof(int[3]),f);
   release_c_function<tag>(f);
}

If I ever use make_c_function it would
probably be in some use like this (to
circumvent the fact that a function pointer
cannot have data associated) rather than
for callacks that are created once and
never changed (such as for
ios_base::register_callback)

In Christ,
Steven Watanabe