He he. I'm failing to communicate by trying to be terse. (Time is tres short this week.)

Basically, under my projected change, if you use a non-nulling release fn, you can call like this:

  scoped_handle<void*>  sh(::malloc(10), ::free);

or this:

  void *pv = ::malloc(10);

  scoped_handle<void*>  sh(pv, ::free);

If you're using a nulling release func, then you must call it like this:

  void free_set_null(void **);

  void *pv = ::malloc(10);

  scoped_handle<void*>  sh(&pv, free_set_null);

Note that you will pass &pv, not pv, in the second case. In other words, you pass a pointer to your variable. That way, all issues of const/non-const / temp/non-temp just disappears. The "cost" is just that we will remove the (recently added) ability to write:

  scoped_handle<void*>  sh(::malloc(10), free_set_null);

I'm of the opinion that that cost is worth paying. Thoughts?


As for my mood, well, I'm nearing the point where the final draft of XSTLv1 will be dispatched to the publishers - just tidying up, and waiting for cover quotes from reviewers ... - my boys (Bob luv 'em) are both back at school - so I can concentrate a bit better - and I have had very fruitful discussions with my editor about getting XSTLv2 trimmed down and therefore likely to be written in half the time I expected.

:-)

  "Adi Shavit" <adish@gentech.co.il> wrote in message news:45C24A13.9010603@gentech.co.il...


    You're right. I'd already considered this, and so decided that the "nulling" ctor overload would take an address of the handle. This has the big advantage that there can be no such confusion, and the small disadvantage that you can't "inline" the allocation function invocation with the scoped_handle ctor. ;-)
  Actually, I'm not sure I understand what you mean.
  The problem I mentioned was specifically related to and assumed taking a reference.
  Do you mean something like taking a reference as opposed to taking a const reference to not compile (or select another ctor) when a temp is given?

    This should all work ticketyboo (LOL, don't you love the silly English and our daft expressions!). Just give me a few days to get over the last book push.

    BigBoy
  You're in a good mood :-).
  Adi

I've implemented this now, and it works fine. I'll include this in the next beta.

  "Matthew Wilson" <matthew@hat.stlsoft.dot.org> wrote in message news:eptn32$22tc$1@digitaldaemon.com...
  He he. I'm failing to communicate by trying to be terse. (Time is tres short this week.)

  Basically, under my projected change, if you use a non-nulling release fn, you can call like this:

    scoped_handle<void*>  sh(::malloc(10), ::free);

  or this:

    void *pv = ::malloc(10);

    scoped_handle<void*>  sh(pv, ::free);

  If you're using a nulling release func, then you must call it like this:

    void free_set_null(void **);

    void *pv = ::malloc(10);

    scoped_handle<void*>  sh(&pv, free_set_null);

  Note that you will pass &pv, not pv, in the second case. In other words, you pass a pointer to your variable. That way, all issues of const/non-const / temp/non-temp just disappears. The "cost" is just that we will remove the (recently added) ability to write:

    scoped_handle<void*>  sh(::malloc(10), free_set_null);

  I'm of the opinion that that cost is worth paying. Thoughts?


  As for my mood, well, I'm nearing the point where the final draft of XSTLv1 will be dispatched to the publishers - just tidying up, and waiting for cover quotes from reviewers ... - my boys (Bob luv 'em) are both back at school - so I can concentrate a bit better - and I have had very fruitful discussions with my editor about getting XSTLv2 trimmed down and therefore likely to be written in half the time I expected.

  :-)

    "Adi Shavit" <adish@gentech.co.il> wrote in message news:45C24A13.9010603@gentech.co.il...


      You're right. I'd already considered this, and so decided that the "nulling" ctor overload would take an address of the handle. This has the big advantage that there can be no such confusion, and the small disadvantage that you can't "inline" the allocation function invocation with the scoped_handle ctor. ;-)
    Actually, I'm not sure I understand what you mean.
    The problem I mentioned was specifically related to and assumed taking a reference.
    Do you mean something like taking a reference as opposed to taking a const reference to not compile (or select another ctor) when a temp is given?

      This should all work ticketyboo (LOL, don't you love the silly English and our daft expressions!). Just give me a few days to get over the last book push.

      BigBoy
    You're in a good mood :-).
    Adi

Got it!
Makes perfect sense.
Thanks.
Sounds good.
Adi

Matthew Wilson wrote:
> He he. I'm failing to communicate by trying to be terse. (Time is tres short this week.)
>  Basically, under my projected change, if you use a non-nulling release fn, you can call like this:
>    scoped_handle<void*>  sh(::malloc(10), ::free);
>  or this:
>    void *pv = ::malloc(10);
>    scoped_handle<void*>  sh(pv, ::free);
>  If you're using a nulling release func, then you must call it like this:
>    void free_set_null(void **);
>    void *pv = ::malloc(10);
>    scoped_handle<void*>  sh(&pv, free_set_null);
>  Note that you will pass &pv, not pv, in the second case. In other words, you pass a pointer to your variable. That way, all issues of const/non-const / temp/non-temp just disappears. The "cost" is just that we will remove the (recently added) ability to write:
>    scoped_handle<void*>  sh(::malloc(10), free_set_null);
>  I'm of the opinion that that cost is worth paying. Thoughts?
>   As for my mood, well, I'm nearing the point where the final draft of XSTLv1 will be dispatched to the publishers - just tidying up, and waiting for cover quotes from reviewers ... - my boys (Bob luv 'em) are both back at school - so I can concentrate a bit better - and I have had very fruitful discussions with my editor about getting XSTLv2 trimmed down and therefore likely to be written in half the time I expected.
>  :-)
>  
>
>     "Adi Shavit" <adish@gentech.co.il <mailto:adish@gentech.co.il>>
>     wrote in message news:45C24A13.9010603@gentech.co.il...
>
>>     You're right. I'd already considered this, and so decided that
>>     the "nulling" ctor overload would take an address of the handle.
>>     This has the big advantage that there can be no such confusion,
>>     and the small disadvantage that you can't "inline" the allocation
>>     function invocation with the scoped_handle ctor. ;-)
>     Actually, I'm not sure I understand what you mean.
>     The problem I mentioned was specifically related to and assumed
>     taking a reference.
>     Do you mean something like taking a reference as opposed to taking
>     a const reference to not compile (or select another ctor) when a
>     temp is given?
>>     This should all work ticketyboo (LOL, don't you love the silly
>>     English and our daft expressions!). Just give me a few days to
>>     get over the last book push.
>>          BigBoy
>     You're in a good mood :-).
>     Adi
>

"Adi Shavit" <adish@gentech.co.il> wrote in message news:epv15g$1175$1@digitaldaemon.com...
> Got it!
> Makes perfect sense.
> Thanks.
> Sounds good.
> Adi

Still going to be a while before I can do STLSoft release, so am including new scoped_handle here. No guarantees on its quality.

Matty