[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SvnCpp Subversion Client C++ API Released!

From: Scott Lamb <slamb_at_slamb.org>
Date: 2002-08-26 07:39:07 CEST

Greg Hudson wrote:
> On Sun, 2002-08-25 at 20:06, Scott Lamb wrote:
>
>>When C++ code calls C code...is using subpools important? I would say
>>no, because the constructor/destructor thing will already make sure the
>>"subpool" is destroyed appropriately.
>
>
> That's only true if the lifetime of the pool (or object) is the same as
> the lifetime of a block of code. If that's not true, then you're back
> to remembering to do an explicit delete.

Block of code or an owning object. Whenever an object is destroyed,
everything it owns is destroyed, too. You could make a class like this:

     /** @internal Self-destroying APR pool **/
     class Pool {
         private:
             Pool(Pool *parent) { me = svn_pool_create(parent->me); }
         public:
             Pool() : Pool(NULL) {}
             Pool(Pool &parent) : Pool(&parent) {}
             ~Pool() { svn_pool_destroy(me); }
             operator apr_pool_t*() { return me; }
         private:
             apr_pool_t *me;
     };

then

     class MyPoolUser {
             ...
         private:
             Pool mypool;
     };

if you want hierarchical pools, you'd do something like this:

     MyPoolUser::MyPoolUser(MyParentPoolUser &p) : mypool(p.mypool) {}

Incidentally, I never have any explicit 'delete's or any kind of cleanup
work in my C++ code, because of this pattern. (A couple classes in
particular I didn't mention yet - boost::shared_ptr<> and
boost::weak_ptr<>.)

>>I think it's more important to hide the pool stuff as much as possible
>>- it's not the C++ way of doing things
>
> I'll buy that, but there is still an efficiency concern if this decision
> reaches fine-grained interfaces like strings. Putting each svn string
> in its own APR pool means spending 8K per string, which is pretty bad if
> the application uses a lot of them.

I didn't realize that. That seems like a pretty good argument for using
subpools, actually. (Which is why I included them in my example above.)

> (I'm not really sold on APR pools in the first place, but it's a maybe a
> tiny bit late to think about going back on that.)

I don't understand how anyone does a significant amount of plain C
without them. (Of course, I haven't done much with them, so maybe "I
don't understand how anyone does a significant amount of plain C" is an
equivalent statement. ;)

-- 
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 26 07:39:46 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.