You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Brent R. Matzelle" <bm...@yahoo.com> on 2002/08/24 17:10:12 UTC
SvnCpp Subversion Client C++ API Released!
Greetings,
After two straight weeks of designing and hacking the SvnCpp C++ API
has now been added to the RapidSVN repository. All C API
functionality is supported except for the Log class and a couple
lesser Modify methods. These will be added soon. SvnCpp should
provide an object-oriented programming interface to any project that
uses C++ or a SWIG-compatible language like Python or Java. If you
want to see the API documentation, made with Doxygen, it can be
viewed here:
http://rapidsvn.tigris.org/svncpp/docs
To download the API download the source from the RapidSVN repository
(under /src/svncpp):
http://svn.collab.net/repos/svn/clients/rapidsvn/trunk
Regards,
Brent.
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SvnCpp Subversion Client C++ API Released!
Posted by "Brent R. Matzelle" <bm...@yahoo.com>.
--- Scott Lamb <sl...@slamb.org> wrote:
> Justin Erenkrantz wrote:
> > On Sat, Aug 24, 2002 at 10:10:12AM -0700, Brent R. Matzelle
> wrote:
> >
> >>To download the API download the source from the RapidSVN
> repository
> >>(under /src/svncpp):
> >>
> >>http://svn.collab.net/repos/svn/clients/rapidsvn/trunk
> >
> > And, the hungarian notation is, well, antiquated. Not to mention
> > some of the code formatting is a bit weird (what's up with
> > Status::LoadPath?)
>
> Okay, since coding style issues have been mentioned and no flamewar
> has
> resulted, I'm going to be daring. Hopefully this strange magic will
>
> continue.
>
> I try to write all my C++ code and doxygen doc comments to adhere
> to
> Sun's standards, which I find work equally well for C++/doxygen as
> for
> Javadoc:
>
> <http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html>
>
<http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#styleguide>
>
> I think a lot of their decisions are arbitrary, but there are a
> couple
> big advantages to following these documents:
>
> - They are well-understood. Anyone who does anything with Java will
> have
> some intuitive understanding of these, because they see them in all
> the
> standard API stuff. And lots of people do stuff with Java.
>
> - They are really thorough, mentioning a lot of things people do
> inconsistently without a second thought.
>
> I noticed the SvnCpp stuff isn't following these in at least a
> couple ways:
>
> - Case issues: Svn::Client::GetError() vs. svn::Client::getError()
> (Namespaces likethis, classes LikeThis, method names likeThis.) It
> makes
> it a little bit easier to glance at a name and tell what it is.
>
> - Grammar conventions for Javadoc: they always use third person.
> The
> SvnCpp stuff mostly does, but there are a few second-person bits:
> "Initialize the primary memory pool" vs. "Initializes the primary
> memory
> pool".
>
> IMHO it would be worthwhile to switch to their conventions.
I did some research and many major C++ API projects use this
convention. The class already matches this format with its
documentation and variable naming. The API has not yet been
implemented in RapidSVN (save one place) so there would not be many
changes. So after a lot of thought and research I made those
suggested changes.
Regards,
Brent.
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SvnCpp Subversion Client C++ API Released!
Posted by Scott Lamb <sl...@slamb.org>.
Justin Erenkrantz wrote:
> On Sat, Aug 24, 2002 at 10:10:12AM -0700, Brent R. Matzelle wrote:
>
>>To download the API download the source from the RapidSVN repository
>>(under /src/svncpp):
>>
>>http://svn.collab.net/repos/svn/clients/rapidsvn/trunk
>
> And, the hungarian notation is, well, antiquated. Not to mention
> some of the code formatting is a bit weird (what's up with
> Status::LoadPath?)
Okay, since coding style issues have been mentioned and no flamewar has
resulted, I'm going to be daring. Hopefully this strange magic will
continue.
I try to write all my C++ code and doxygen doc comments to adhere to
Sun's standards, which I find work equally well for C++/doxygen as for
Javadoc:
<http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html>
<http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#styleguide>
I think a lot of their decisions are arbitrary, but there are a couple
big advantages to following these documents:
- They are well-understood. Anyone who does anything with Java will have
some intuitive understanding of these, because they see them in all the
standard API stuff. And lots of people do stuff with Java.
- They are really thorough, mentioning a lot of things people do
inconsistently without a second thought.
I noticed the SvnCpp stuff isn't following these in at least a couple ways:
- Case issues: Svn::Client::GetError() vs. svn::Client::getError()
(Namespaces likethis, classes LikeThis, method names likeThis.) It makes
it a little bit easier to glance at a name and tell what it is.
- Grammar conventions for Javadoc: they always use third person. The
SvnCpp stuff mostly does, but there are a few second-person bits:
"Initialize the primary memory pool" vs. "Initializes the primary memory
pool".
IMHO it would be worthwhile to switch to their conventions.
--
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SvnCpp Subversion Client C++ API Released!
Posted by Scott Lamb <sl...@slamb.org>.
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
Re: SvnCpp Subversion Client C++ API Released!
Posted by Greg Hudson <gh...@MIT.EDU>.
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.
> 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'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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SvnCpp Subversion Client C++ API Released!
Posted by Scott Lamb <sl...@slamb.org>.
Brent R. Matzelle wrote:
> --- Justin Erenkrantz <je...@apache.org> wrote:
>>I also would consider that the pool should be passed to the
>>constructor of each class. I'm not entirely happy that it does a
>>svn_pool_create(NULL). The issue is that pools are hierarchical
>>and
>>you're going to lose that aspect. At the very least, allow for a
>>constructor where the pool parameter is passed in.
>
> I am not sure what advantage using hierarchical pools would make
> here.
I'm not very familiar with APR, I'm afraid, so here I'm stating what is
possibly obvious to everyone else. Please correct me if it's incorrect.
The purpose of APR pools is to remove the need for explicit cleanup,
correct? You create and destroy a pool in the same scope (around a loop
over calls to a function that uses it, for example). Memory allocation
automatically causes a matching deallocation when the containing pool is
destroyed. Other operations allocating per-pool resources have common
patterns where you allocate and do a apr_pool_register_destructor() (or
whatever its called) at the same point in the code. They are
hierarchical - pools can have subpools, etc.
C++ has a common pattern called "guards" or "monitors" - you create a
small class that handles the allocation and deallocation.
boost::scoped_ptr<> for memory, boost::mutex::scoped_lock for mutexes,
etc. They are on the main program stack, so returning or throwing an
exception or whatever implicitly calls the destructor and makes the
deallocation happen. They are also hierarchical, since the stack is.
When writing pure C++ code, APR's pool concept is pretty redundant. The
guards accomplish the same thing in a slightly simpler/less error-prone
way - there's no need to ever explicitly remove the pool, it happens
automatically when you leave the scope.
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. I think it's more important to
hide the pool stuff as much as possible - it's not the C++ way of doing
things, and making this feel more C++-like is the whole point of SvnCpp.
--
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SvnCpp Subversion Client C++ API Released!
Posted by "Brent R. Matzelle" <bm...@yahoo.com>.
--- Justin Erenkrantz <je...@apache.org> wrote:
> On Sat, Aug 24, 2002 at 10:10:12AM -0700, Brent R. Matzelle wrote:
> > To download the API download the source from the RapidSVN
> repository
> > (under /src/svncpp):
> >
> > http://svn.collab.net/repos/svn/clients/rapidsvn/trunk
>
> Hmm. I'm concerned that by using this API you lose access to the
> svn_error_t structure. Most of the functions simply return a true
> or a false. That's completely useless to me as a developer. I
> want to know *why* it failed and I think this API loses that.
> I think I'd have to call GetError after a function returns false.
> Ick.
>
> In a true C++ API, I would expect the errors to be handled via
> exceptions rather than a bool true/false value. The concept of a
> global value called Err is frightening to me. Errors in C++ ought
> not to be handled that way. (Please don't say that exceptions are
> slow - if that's a concern, then don't use C++.)
>
> For example, Status::LastChanged should return an unsigned long
> (given that SVN does not have negative revision numbers). On an
> error, it might throw SVNEntryNotVersioned exception or something
> like that.
You are getting a little ahead of me. I plan on making a hierarchy
of exception classes in the next revision of SvnCpp.
> I also would consider that the pool should be passed to the
> constructor of each class. I'm not entirely happy that it does a
> svn_pool_create(NULL). The issue is that pools are hierarchical
> and
> you're going to lose that aspect. At the very least, allow for a
> constructor where the pool parameter is passed in.
I am not sure what advantage using hierarchical pools would make
here.
> And, the hungarian notation is, well, antiquated. Not to mention
> some of the code formatting is a bit weird (what's up with
> Status::LoadPath?)
The strange Status::LoadPath formatting has been eliminated. You are
right about the Hungarian notation. It's just an old habit of mine
;) I just made a check in today that removed it.
> My curmudgeonly $.02 off a cursory code review. -- justin
Thanks!
Brent.
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SvnCpp Subversion Client C++ API Released!
Posted by Justin Erenkrantz <je...@apache.org>.
On Sat, Aug 24, 2002 at 10:10:12AM -0700, Brent R. Matzelle wrote:
> To download the API download the source from the RapidSVN repository
> (under /src/svncpp):
>
> http://svn.collab.net/repos/svn/clients/rapidsvn/trunk
Hmm. I'm concerned that by using this API you lose access to the
svn_error_t structure. Most of the functions simply return a true
or a false. That's completely useless to me as a developer. I
want to know *why* it failed and I think this API loses that.
I think I'd have to call GetError after a function returns false.
Ick.
In a true C++ API, I would expect the errors to be handled via
exceptions rather than a bool true/false value. The concept of a
global value called Err is frightening to me. Errors in C++ ought
not to be handled that way. (Please don't say that exceptions are
slow - if that's a concern, then don't use C++.)
For example, Status::LastChanged should return an unsigned long
(given that SVN does not have negative revision numbers). On an
error, it might throw SVNEntryNotVersioned exception or something
like that.
I also would consider that the pool should be passed to the
constructor of each class. I'm not entirely happy that it does a
svn_pool_create(NULL). The issue is that pools are hierarchical and
you're going to lose that aspect. At the very least, allow for a
constructor where the pool parameter is passed in.
And, the hungarian notation is, well, antiquated. Not to mention
some of the code formatting is a bit weird (what's up with
Status::LoadPath?)
My curmudgeonly $.02 off a cursory code review. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org