[Edbrowse-dev] extern "C"{}

[Edbrowse-dev] extern "C"{}

[Karl Dahlke]

Actually the .p files can't be autogenerated any more.
Some of the functions in jsdom.cpp we declare in eb.p
for general use; most we declare in ebjs.p for the js layer.
So we need to maintain them ourselves, which isn't hard.
I may remove the lines from the makefile,
so people aren't tempted to try to generate them.
And if they are source files indeed, then no harm in moving extern C to eb.p.
I could even remove mkproto.c from the tools directory, if we aren't using it.
Let me know if I should or shouldn't move in this direction.

Karl Dahlke

Re: [Edbrowse-dev] extern "C"{}

[Adam Thompson]

On Sun, Feb 16, 2014 at 06:40:57PM -0500, Karl Dahlke wrote:
> Actually the .p files can't be autogenerated any more.
> Some of the functions in jsdom.cpp we declare in eb.p
> for general use; most we declare in ebjs.p for the js layer.
> So we need to maintain them ourselves, which isn't hard.

Ah ok.

> I may remove the lines from the makefile,
> so people aren't tempted to try to generate them.
> And if they are source files indeed, then no harm in moving extern C to eb.p.
> I could even remove mkproto.c from the tools directory, if we aren't using it.
> Let me know if I should or shouldn't move in this direction.

Sounds like a good idea as otherwise things could get confusing.

Cheers,
Adam.

Re: [Edbrowse-dev] extern "C"{}

[Adam Thompson]

On Sat, Feb 15, 2014 at 03:52:37AM -0500, Karl Dahlke wrote:
> I've seen it manyh times, but I don't understand what this does.
> I would guess that the prototypes enclosed are C functions,
> not C++, so the C++ compiler will call them with the C conventions.

Yes, this construct prevents c++ name mangling,
and is necessary for linking between c and c++ code.
> That would make sense, but then
> 
> 1. Couldn't we just put it around eb.p?
> We don't really need it in eb.h.
> That would let us indent eb.h if we like, and be a bit clearer perhaps.

It depends if eb.p is ever regenerated, I guess this'd be a change in mkproto?
> 
> 2. there are a few functions like set_global_property_string
> that are C++ functions, but are declared in eb.p, in eb.h,
> and inside extern "C"{}.
> In fact this one is declared twice, in eb.p and ebjs.p, one inside extern "C"{}
> and the other time not.
> So I guess I don't know what this does,
> and why we seem to get away with using it inconsistently.

I was going to say that needed cleaning up but it looks like that's already been done.
As for why it didn't explode, probably because the parts of the code using it
were using the c++ signature (with the JS::handle stuff)
and gcc is a fairly friendly compiler.

Cheers,
Adam.

[Edbrowse-dev] extern "C"{}

[Karl Dahlke]

I've seen it manyh times, but I don't understand what this does.
I would guess that the prototypes enclosed are C functions,
not C++, so the C++ compiler will call them with the C conventions.
That would make sense, but then

1. Couldn't we just put it around eb.p?
We don't really need it in eb.h.
That would let us indent eb.h if we like, and be a bit clearer perhaps.

2. there are a few functions like set_global_property_string
that are C++ functions, but are declared in eb.p, in eb.h,
and inside extern "C"{}.
In fact this one is declared twice, in eb.p and ebjs.p, one inside extern "C"{}
and the other time not.

So I guess I don't know what this does,
and why we seem to get away with using it inconsistently.

Karl Dahlke