Thread (26 messages) flat view 26 messages, 11 authors, 2016-06-15

Re: linking libgit.a in C++ projects

From: Petr Baudis <hidden>
Date: 2016-06-15 22:45:05

On Thu, Jul 31, 2008 at 02:57:27PM +0400, Dmitry Potapov wrote:
On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
quoted
I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
than being lame and parsing the output the various git commands, I'm
using libgit.a to provide all of the needed functionality for my app.
Don't do that! libgit.a is an internal library used solely to build
git binaries. It means that its interface can be cahnged at any time.
I don't think this is that big a problem; there are applications that
are doing this already, e.g. cgit, and if you tie your application to
a particular git version by for example making git a submodule of your
source, this is pretty safe; it will just mean that you will have to
do some non-trivial porting of your code to the new interface each time
you update - but I think large changes in the interface are pretty rare
in practice by now, and there shouldn't be much on the horizon either(?).
quoted
However, the git source uses a few reserved C++ keywords; namely
'typename', and 'new'.
Because this source code are meant to be compiled by C and not by C++!
Even if we will have real git library for other applications to use,
it still be compiled only by C. Thus, C++ keywords are not issue.
What would be the reason to disallow C++ users? The costs aren't that
high, and (modulo, say, extern "C" { }) there should be no C-C++
compatibility issues, right?

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help