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/20 02:02:12 UTC
New Subversion Client C++ API
Hello Everyone,
I have been happily hacking away at RapidSVN. The code written by
the original author was written with the Subversion C API mixed in,
which made for some really arcane and difficult to debug code.
Finally I decided to write a C++ API that would provide a nice clean
interface. It is a wrapper of the C API code. There is tons of data
hiding done so you can barely tell it's using C underneath. I called
the API SvnCpp for obvious reasons.
About 75% of the C API has been completed so far. All functions are
documented with the help of Doxygen. I wrote unit tests for each
method with CppUnit.
I was wondering if it should be placed in the Subversion repository
under bindings/svncpp or if I should just put it in the RapidSVN
project. It is useful for any project so I would expect the former.
Hopefully one of the people writing a TortoiseCVS-like clone might
use it.
Either way, I'll post the documentation and code on the RapidSVN
site.
Best regards,
Brent.
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.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
SvnCpp Subversion Client C++ API Released!
Posted by "Brent R. Matzelle" <bm...@yahoo.com>.
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: New Subversion Client C++ API
Posted by "Brent R. Matzelle" <bm...@yahoo.com>.
--- Greg Hudson <gh...@MIT.EDU> wrote:
> On Tue, 2002-08-20 at 16:06, Brent R. Matzelle wrote:
> > You summed up my feelings exactly. And yes, I did perform much
> more
> > data hiding than the original C API. For instance, all of the
> APR
> > memory allocation is performed internally.
>
> subversion/clients/cmdline has a whopping two calls to
> apr_palloc(),
> both for batons it uses. What memory allocation does our C
> interface
> not do internally?
>
> I'm not asking for a huge debate here, but a little justification
> would
> be helpful. If it's purely a matter of syntactic consistency,
> that's
> okay, but it seems like you're claiming there's some deeper issue
> with
> the C API.
Absolutely not. There is nothing wrong with the C API. I want to
make that perfectly clear. Consistency is the important issue here.
Brent.
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Subversion Client C++ API
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2002-08-20 at 16:06, Brent R. Matzelle wrote:
> You summed up my feelings exactly. And yes, I did perform much more
> data hiding than the original C API. For instance, all of the APR
> memory allocation is performed internally.
subversion/clients/cmdline has a whopping two calls to apr_palloc(),
both for batons it uses. What memory allocation does our C interface
not do internally?
I'm not asking for a huge debate here, but a little justification would
be helpful. If it's purely a matter of syntactic consistency, that's
okay, but it seems like you're claiming there's some deeper issue with
the C API.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Subversion Client C++ API
Posted by "Brent R. Matzelle" <bm...@yahoo.com>.
--- Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On Tue, Aug 20, 2002 at 11:13:54AM -0700, Greg Stein wrote:
>
> > (I believe) Greg Hudson's question has nothing to do with C vs
> C++. Instead,
> > it is questioning why you are having problems putting C code into
> your C++
> > code. By design, C++ was supposed to be able to mix in vanilla C
> code.
> >
> > So what were you seeing that caused a problem?
> >
> > However, your followup talks about "data hiding". The SVN
> interface is
> > already pretty good about data hiding. Which did you feel needed
> to be
> > hidden? Or needed more hiding? etc
>
> personally, even though one can call c directly from c++, doing so
> often in a large c++ application can feel 'icky'. there's
> something
> to be said for having an API more in the spirit of c++. i mean
> there's a reason that the gtkmm people have gone to so much trouble
> to
> wrap gtk in c++.
You summed up my feelings exactly. And yes, I did perform much more
data hiding than the original C API. For instance, all of the APR
memory allocation is performed internally.
> > You had mentioned that you would post a reference or somesuch on
> the
> > RapidSVN site. I don't see that right now... It is kind of hard
> to provide
> > feedback about your C++ APIs :-)
>
> yeah, i'd also like to take a look at this ;-)
Well, I was waiting until the SvnCpp code found a home but since you
asked I gladly posted it:
http://rapidsvn.tigris.org/svncpp/docs/index.html
I placed a news blurb on the RapidSVN homepage too if you forget this
link.
Regards,
Bretn
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Subversion Client C++ API
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Tue, Aug 20, 2002 at 11:13:54AM -0700, Greg Stein wrote:
> (I believe) Greg Hudson's question has nothing to do with C vs C++. Instead,
> it is questioning why you are having problems putting C code into your C++
> code. By design, C++ was supposed to be able to mix in vanilla C code.
>
> So what were you seeing that caused a problem?
>
> However, your followup talks about "data hiding". The SVN interface is
> already pretty good about data hiding. Which did you feel needed to be
> hidden? Or needed more hiding? etc
personally, even though one can call c directly from c++, doing so
often in a large c++ application can feel 'icky'. there's something
to be said for having an API more in the spirit of c++. i mean
there's a reason that the gtkmm people have gone to so much trouble to
wrap gtk in c++.
> You had mentioned that you would post a reference or somesuch on the
> RapidSVN site. I don't see that right now... It is kind of hard to provide
> feedback about your C++ APIs :-)
yeah, i'd also like to take a look at this ;-)
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Subversion Client C++ API
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Aug 19, 2002 at 07:39:49PM -0700, Brent R. Matzelle wrote:
> --- Greg Hudson <gh...@MIT.EDU> wrote:
> > On Mon, 2002-08-19 at 22:02, Brent R. Matzelle wrote:
> > > I have been happily hacking away at RapidSVN. The code written by
> > > the original author was written with the Subversion C API mixed in,
> > > which made for some really arcane and difficult to debug code.
> >
> > Could you explain how the "really arcane and difficult to debug code"
> > follows from the "code... with the Subversion C API mixed in?"
> >
> > (No opinion on whether we want a C++ binding in general; I'm just
> > puzzled why C++ code using a C API would be intrinsically bad.)
>
> You are asking for a debate that I do not want to get into. Let's
> just say that I enjoy the data hiding that C++ OO offers. To each
> his own! I am just looking for feedback on the classes, not on my
> preferences ;-)
(I believe) Greg Hudson's question has nothing to do with C vs C++. Instead,
it is questioning why you are having problems putting C code into your C++
code. By design, C++ was supposed to be able to mix in vanilla C code.
So what were you seeing that caused a problem?
However, your followup talks about "data hiding". The SVN interface is
already pretty good about data hiding. Which did you feel needed to be
hidden? Or needed more hiding? etc
You had mentioned that you would post a reference or somesuch on the
RapidSVN site. I don't see that right now... It is kind of hard to provide
feedback about your C++ APIs :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Excellent list (was Re: New Subversion Client C++ API)
Posted by "Eric W. Sink" <er...@sourcegear.com>.
Brent wrote:
> You are asking for a debate that I do not want to get into. Let's
> just say that I...
Wow. On any other list this would have mushroomed into a big
waste of time.
I don't remember saying it before so I'll say it now: Kudos to
the CollabNet guys for fostering such a civilized environment.
In addition to all the ways that Subversion is intrinsically
cool, it is also cool because its developers consistently act
like grownups.
--
Eric W. Sink
eric@sourcegear.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Subversion Client C++ API
Posted by "Brent R. Matzelle" <bm...@yahoo.com>.
--- Greg Hudson <gh...@MIT.EDU> wrote:
> On Mon, 2002-08-19 at 22:02, Brent R. Matzelle wrote:
> > I have been happily hacking away at RapidSVN. The code written
> by
> > the original author was written with the Subversion C API mixed
> in,
> > which made for some really arcane and difficult to debug code.
>
> Could you explain how the "really arcane and difficult to debug
> code"
> follows from the "code... with the Subversion C API mixed in?"
>
> (No opinion on whether we want a C++ binding in general; I'm just
> puzzled why C++ code using a C API would be intrinsically bad.)
You are asking for a debate that I do not want to get into. Let's
just say that I enjoy the data hiding that C++ OO offers. To each
his own! I am just looking for feedback on the classes, not on my
preferences ;-)
Brent
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Subversion Client C++ API
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2002-08-19 at 22:02, Brent R. Matzelle wrote:
> I have been happily hacking away at RapidSVN. The code written by
> the original author was written with the Subversion C API mixed in,
> which made for some really arcane and difficult to debug code.
Could you explain how the "really arcane and difficult to debug code"
follows from the "code... with the Subversion C API mixed in?"
(No opinion on whether we want a C++ binding in general; I'm just
puzzled why C++ code using a C API would be intrinsically bad.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org