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

Re: Higher level languages as part of the core of SVN

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-10-21 23:08:55 CEST

On 10/21/06, Branko Èibej <brane@xbc.nu> wrote:
> Garrett Rooney wrote:
> > On 10/21/06, Branko Èibej <brane@xbc.nu> wrote:
> >> Garrett Rooney wrote:
> >> > I'd like to propose another idea for how we could write parts of
> >> > Subversion itself (not just the command line clients, but actual
> >> > portions of the libraries) in a higher level language, but still
> >> > expose a C level interface to the rest of the world, without dealing
> >> > with the binary compatibility and other issues that come with C++.
> >>
> >>
> >> I am continually amazed by the thousands of otherwise quite competent
> >> programmers who still believe that "C++" and "binary incompatibility"
> >> are two sides of the same coin, or that you can't expose a completely
> >> C-like interface from something compiled as C++.
> >>
> >> You can, and you can even provide a C++ API that has *no* binary
> >> compatibility issues, ever, on any platform (heh, that is, no more than
> >> any C API).
> >>
> >> Of course "API" and "implementation language" aren't related either,
> >> that's another bugaboo.
> >
> > No argument there, it's certainly possible to write in C++ yet avoid
> > the various types of binary incompatibility (i.e. don't expose
> > anything that depends on the STL).
>
> You mean, like, "don't expose anything that depends on APR?" :)
>
> Sorry, couldn't resist ...

It is certainly a problem of similar scope, although not exposing
stuff like the STL probably also means not using it internally, since
it's kind of tricky to require the linking in of multiple STL
implementations if we use one and the app using our libraries uses
another. Not saying it's impossible, just hard.

-garrett
Received on Sat Oct 21 23:09:08 2006

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.