[Caml-list] Efficient C++ interfacing?

[Caml-list] Efficient C++ interfacing?

[Brandon J. Van Every]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

On the subject of C++, the archive is daunting and not terribly
informative.  If this has been asked before and good answers have been
given, I'm happy for pointers.  Otherwise, I figure it doesn't hurt to
ask the same questions at some repeating time interval.

If one wants to interface native OCaml code to native C++ code for
performance reasons, what is a good way to go about it?  Are there any
automated binders for this native-native linkage?  I've been looking at
SWIG but am unsure if it's native-native.  The OCaml SWIG author
suggested that the performance is more on par with calling a scripting
language, but maybe I misunderstood.  I'd be interested in optimizing
that, but only if it's a reasonable architectural approach.  I really
don't have a handle on what C++ <--> OCaml efforts are out there.
Anything other than SWIG?

My challenge problem is providing OCaml bindings for The Nebula Device
2.  http://nebuladevice.cubik.org.  I do not wish to use their script
server interface.  It looks like a relatively low performance binding -
adequate for scripts that aren't supposed to be fast, but really not
intended for native-native communication.  Also, script servers can only
interface nRoot objects, leaving a whole class of nNode objects that
must be accessed from C++.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
 

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2592 bytes --]

RE: [Caml-list] Efficient C++ interfacing?

[ronniec95]

Hi,

I've done a fair amount of C interfacing with Ocaml. Although the auto-conversion
tools are ok, it's usually simpler (and definitely faster in terms of performance)
to roll your own I've found. And it's actually not that complicated for
most things.

Also with handrolling your own interface you'll get something that is more
ocaml like and makes more sense (from a usability perspective) than auto
generated ones most of the time. This is from my experience only, and YMMV.

If you want specific examples, I can send you.

Ronnie
>-- Original Message --
>From: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
>To: "caml" <caml-list@inria.fr>
>Subject: [Caml-list] Efficient C++ interfacing?
>Date: Sun, 30 May 2004 00:41:31 -0700
>
>
>On the subject of C++, the archive is daunting and not terribly
>informative.  If this has been asked before and good answers have been
>given, I'm happy for pointers.  Otherwise, I figure it doesn't hurt to
>ask the same questions at some repeating time interval.
>
>If one wants to interface native OCaml code to native C++ code for
>performance reasons, what is a good way to go about it?  Are there any
>automated binders for this native-native linkage?  I've been looking at
>SWIG but am unsure if it's native-native.  The OCaml SWIG author
>suggested that the performance is more on par with calling a scripting
>language, but maybe I misunderstood.  I'd be interested in optimizing
>that, but only if it's a reasonable architectural approach.  I really
>don't have a handle on what C++ <--> OCaml efforts are out there.
>Anything other than SWIG?
>
>My challenge problem is providing OCaml bindings for The Nebula Device
>2.  http://nebuladevice.cubik.org.  I do not wish to use their script
>server interface.  It looks like a relatively low performance binding -
>adequate for scripts that aren't supposed to be fast, but really not
>intended for native-native communication.  Also, script servers can only
>interface nRoot objects, leaving a whole class of nNode objects that
>must be accessed from C++.
>
>
>Cheers,                     www.indiegamedesign.com
>Brandon Van Every           Seattle, WA
>
>"The pioneer is the one with the arrows in his back."
>                          - anonymous entrepreneur
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004
>
>
>Attachment: winmail.dat
>


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Efficient C++ interfacing?

[Brandon J. Van Every]

Ronnie wrote:
>
> I've done a fair amount of C interfacing with Ocaml.
> 
> If you want specific examples, I can send you.

Sure, I wouldn't mind taking a look at your typical strategies.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

On Sunday 30 May 2004 14:47, you wrote:
> Hi,
>
> I've done a fair amount of C interfacing with Ocaml. Although the
> auto-conversion tools are ok, it's usually simpler (and definitely faster
> in terms of performance) to roll your own I've found. And it's actually not
> that complicated for most things.
>
> Also with handrolling your own interface you'll get something that is more
> ocaml like and makes more sense (from a usability perspective) than auto
> generated ones most of the time. This is from my experience only, and YMMV.

What if we would like to generate bindings for a huge moving target like Qt or 
KDE libraries? It would take an inordinate amount of time to update such 
bindings manually. Do you suggest that SWIG sucks as far as ocaml goes?

Best Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[skaller]

On Sun, 2004-06-06 at 02:45, Eray Ozkural wrote:
> On Sunday 30 May 2004 14:47, you wrote:

> What if we would like to generate bindings for a huge moving target like Qt or 
> KDE libraries? 

Hehe .. that's a *small* target.

http://felix.sourceforge.net/flxcc.html

has a slightly larger target .. every library on your system :)

Would you like to build a wrapper for Python? 

recincdir /usr/local/include/python2.3
exclude /usr/local/include/python2.3/pymactoolbox.h

[the second line is because I'm not on a Mac ..]


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Efficient C++ interfacing?

[Brandon J. Van Every]

I hope this makes it through.  I'm having inordinate difficulty getting
anything posted lately.

Eray Ozkural wrote:
>
> What if we would like to generate bindings for a huge moving
> target like Qt or KDE libraries?

I was just tossed this link:
"C Mania: KDE 3 Offers C Bindings"
http://dot.kde.org/1003877941/
Somehow, C++ was automatically wrapped with C and mostly worked.
Creating a C layer seems to be half the problem, so I've been asking on
comp.lang.c++.moderated about automated C wrappers.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.693 / Virus Database: 454 - Release Date: 5/31/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

Skaller, as a KDE developer I beg you. Please do it for Qt and KDE as well.

Best Regards,

On Saturday 05 June 2004 22:07, skaller wrote:
> On Sun, 2004-06-06 at 02:45, Eray Ozkural wrote:
> > On Sunday 30 May 2004 14:47, you wrote:
> >
> > What if we would like to generate bindings for a huge moving target like
> > Qt or KDE libraries?
>
> Hehe .. that's a *small* target.
>
> http://felix.sourceforge.net/flxcc.html
>
> has a slightly larger target .. every library on your system :)
>
> Would you like to build a wrapper for Python?
>
> recincdir /usr/local/include/python2.3
> exclude /usr/local/include/python2.3/pymactoolbox.h
>
> [the second line is because I'm not on a Mac ..]

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[John Goerzen]

On Sun, Jun 06, 2004 at 03:31:04AM +0300, Eray Ozkural wrote:
> Skaller, as a KDE developer I beg you. Please do it for Qt and KDE as well.

The other nice thing is this: if we get Qt bindings, then OCaml
suddenly becomes a viable language for developing embedded
applications thanks to Qt/Embedded.  That would be excellent.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[skaller]

On Sun, 2004-06-06 at 13:33, John Goerzen wrote:
> On Sun, Jun 06, 2004 at 03:31:04AM +0300, Eray Ozkural wrote:
> > Skaller, as a KDE developer I beg you. Please do it for Qt and KDE as well.
> 
> The other nice thing is this: if we get Qt bindings, then OCaml
> suddenly becomes a viable language for developing embedded
> applications thanks to Qt/Embedded.  That would be excellent.

Well, there are two obstacles at the moment:

(1) Flxcc can't parse C++ yet
(2) Flxcc can't target Ocaml yet

Parsing C++ - templates is quite easy:
I've already made the mods to Frontc parser.
However, the parse tree is processed by Cil,
which does some complex transformations to regularise
the representation, and modifying that isn't so easy.
Cil handles the whole of C, whereas we actually only need
to process interfaces -- expressions could be useful
(default arguments, template arguments, and typeof)

Generating Ocaml should be easy. However the program
will need to be factored to have a selectable backend.
It will need to do a bit more work than the Felix
backend however: Ocaml has separate compilation, 
Felix doesn't. Ocaml can't do general recursion,
Felix has trouble doing anything else.

But I have no doubt it can be done, even if the
result isn't perfect. 

What's needed is developers.
Wrapper generators need extensive testing by experts in 
the wrapped libraries, and the code has to be lifted
out of Felix and put into a new project (and then
Felix will have to re-integrate it).

I guess we need 4 developers to start off.
And a better name than 'flxcc' before registering
a new project :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[David Fox]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

skaller wrote:

>On Sun, 2004-06-06 at 02:45, Eray Ozkural wrote:
>  
>
>>On Sunday 30 May 2004 14:47, you wrote:
>>    
>>
>
>  
>
>>What if we would like to generate bindings for a huge moving target like Qt or 
>>KDE libraries? 
>>    
>>
>
>Hehe .. that's a *small* target.
>
>http://felix.sourceforge.net/flxcc.html
>
>has a slightly larger target .. every library on your system :)
>
>Would you like to build a wrapper for Python? 
>
>recincdir /usr/local/include/python2.3
>exclude /usr/local/include/python2.3/pymactoolbox.h
>
>[the second line is because I'm not on a Mac ..]
>
>
>  
>

My guess is that the set of all C libraries on my system is smaller than 
the two C++ libraries Qt + KDE.  Anyway, Qt + KDE sure *feels* bigger...

-david


--

This message contains information which may be confidential and privileged. Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone 
the message or any information contained in the message. If you have received the message in error, 
please advise the sender and delete the message.  Thank you.

[-- Attachment #2: Type: text/html, Size: 1739 bytes --]

Re: [Caml-list] Efficient C++ interfacing?

[David Fox]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

skaller wrote:

>On Sun, 2004-06-06 at 13:33, John Goerzen wrote:
>  
>
>>On Sun, Jun 06, 2004 at 03:31:04AM +0300, Eray Ozkural wrote:
>>    
>>
>>>Skaller, as a KDE developer I beg you. Please do it for Qt and KDE as well.
>>>      
>>>
>>The other nice thing is this: if we get Qt bindings, then OCaml
>>suddenly becomes a viable language for developing embedded
>>applications thanks to Qt/Embedded.  That would be excellent.
>>    
>>
>
>Well, there are two obstacles at the moment:
>
>(1) Flxcc can't parse C++ yet
>(2) Flxcc can't target Ocaml yet
>
>Parsing C++ - templates is quite easy:
>I've already made the mods to Frontc parser.
>However, the parse tree is processed by Cil,
>which does some complex transformations to regularise
>the representation, and modifying that isn't so easy.
>Cil handles the whole of C, whereas we actually only need
>to process interfaces -- expressions could be useful
>(default arguments, template arguments, and typeof)
>
>Generating Ocaml should be easy. However the program
>will need to be factored to have a selectable backend.
>It will need to do a bit more work than the Felix
>backend however: Ocaml has separate compilation, 
>Felix doesn't. Ocaml can't do general recursion,
>Felix has trouble doing anything else.
>
>But I have no doubt it can be done, even if the
>result isn't perfect. 
>
>What's needed is developers.
>Wrapper generators need extensive testing by experts in 
>the wrapped libraries, and the code has to be lifted
>out of Felix and put into a new project (and then
>Felix will have to re-integrate it).
>
>I guess we need 4 developers to start off.
>And a better name than 'flxcc' before registering
>a new project :)
>
>  
>

There's a third obstacle.  Qt code is preprocessed by moc, which adds 
additional unparsable features to the already unparsable C++ syntax.



--

This message contains information which may be confidential and privileged. Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone 
the message or any information contained in the message. If you have received the message in error, 
please advise the sender and delete the message.  Thank you.

[-- Attachment #2: Type: text/html, Size: 2716 bytes --]

Re: [Caml-list] Efficient C++ interfacing?

[David Fox]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

Brandon J. Van Every wrote:

>I hope this makes it through.  I'm having inordinate difficulty getting
>anything posted lately.
>
>Eray Ozkural wrote:
>  
>
>>What if we would like to generate bindings for a huge moving
>>target like Qt or KDE libraries?
>>    
>>
>
>I was just tossed this link:
>"C Mania: KDE 3 Offers C Bindings"
>http://dot.kde.org/1003877941/
>Somehow, C++ was automatically wrapped with C and mostly worked.
>Creating a C layer seems to be half the problem, so I've been asking on
>comp.lang.c++.moderated about automated C wrappers.
>
>  
>
Unfortunately, those bindings are over three years old, and despite the 
claim of being generated automatically, are continually becoming stale 
and rarely work.  There are now tools called "Kalyptus"and "Smoke" in 
the kdebindings module of the kde.org CVS server, which is used to 
generate several language bindings, none of which is C, but one of which 
is Smoke.  In the smoke directory it looks like there are now 
conversions for both Qt and KDE.  So maybe the pieces are all there now.


--

This message contains information which may be confidential and privileged. Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone 
the message or any information contained in the message. If you have received the message in error, 
please advise the sender and delete the message.  Thank you.

[-- Attachment #2: Type: text/html, Size: 2033 bytes --]

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

On Sunday 06 June 2004 10:00, skaller wrote:
> On Sun, 2004-06-06 at 13:33, John Goerzen wrote:
> > On Sun, Jun 06, 2004 at 03:31:04AM +0300, Eray Ozkural wrote:
> > > Skaller, as a KDE developer I beg you. Please do it for Qt and KDE as
> > > well.
> >
> > The other nice thing is this: if we get Qt bindings, then OCaml
> > suddenly becomes a viable language for developing embedded
> > applications thanks to Qt/Embedded.  That would be excellent.
>
> Well, there are two obstacles at the moment:
>
> (1) Flxcc can't parse C++ yet

I had started writing a modern top-down C++ parser using the combinatorial 
parser library Parsec in Haskell, but I had failed due to lack of time with 
the project. I had stumbled upon the two major C++ ambiguity resolutions 
which require the parser to know something about the semantics early on and 
was frustrated with the amount of work required... Let me know how I can help 
with this. There are freely available parser models [LL(k), not LR(k)] which 
we can build upon. I think I was following the model from tendra but it's 
been ages, now I see that I've written about 15k of Parsec code, I think I've 
had a fair amount of C++ parser experience sometime in the past :)

There is also the language extensions of Qt MOC, but after doing C++ it would 
be possible to cope with a few simple keywords.

> (2) Flxcc can't target Ocaml yet

This one wouldn't be hard.

> Parsing C++ - templates is quite easy:
> I've already made the mods to Frontc parser.
> However, the parse tree is processed by Cil,
> which does some complex transformations to regularise
> the representation, and modifying that isn't so easy.
> Cil handles the whole of C, whereas we actually only need
> to process interfaces -- expressions could be useful
> (default arguments, template arguments, and typeof)

So, you do have a rudimentary C++ parser?

> Generating Ocaml should be easy. However the program
> will need to be factored to have a selectable backend.
> It will need to do a bit more work than the Felix
> backend however: Ocaml has separate compilation,
> Felix doesn't. Ocaml can't do general recursion,
> Felix has trouble doing anything else.

Ok.

> But I have no doubt it can be done, even if the
> result isn't perfect.

I guess so, too. I dropped my project when I saw SWIG adding Ocaml support. 
They even have some Qt examples in their new manual. Again, I have no idea 
how well their stuff works. I used SWIG only once, and that was because a 
compile required it.

> What's needed is developers.
> Wrapper generators need extensive testing by experts in
> the wrapped libraries, and the code has to be lifted
> out of Felix and put into a new project (and then
> Felix will have to re-integrate it).

Yes. However, doing this wrapper generator is considerably valuable. For 
instance, if we can add Qt C++ syntax support, then we can target every KDE 
program installed!

> I guess we need 4 developers to start off.
> And a better name than 'flxcc' before registering
> a new project :)

You find the name. I think this list will be a good place to recruit 
developers :) I will try to contribute. I was trying to find a way to 
contribute to KDE in a useful way now that Qt 4 will feature MVC support that 
I was working on :)

Cheers,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

On Sunday 06 June 2004 19:18, David Fox wrote:
> Unfortunately, those bindings are over three years old, and despite the
> claim of being generated automatically, are continually becoming stale
> and rarely work.  There are now tools called "Kalyptus"and "Smoke" in
> the kdebindings module of the kde.org CVS server, which is used to
> generate several language bindings, none of which is C, but one of which
> is Smoke.  In the smoke directory it looks like there are now
> conversions for both Qt and KDE.  So maybe the pieces are all there now.
>

Yes, the smoke lib is favored among kdebindings developers. They too wish to 
eliminate the manual labor that was needed before to patch the C libs... I 
wonder how well the python bindings perform right now. Python too is a quite 
high level language.

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[skaller]

On Mon, 2004-06-07 at 04:44, Eray Ozkural wrote:
> On Sunday 06 June 2004 10:00, skaller wrote:

> >
> > (1) Flxcc can't parse C++ yet
> 
> I had started writing a modern top-down C++ parser using the combinatorial 
> parser library Parsec in Haskell, but I had failed due to lack of time with 
> the project.

> There are freely available parser models [LL(k), not LR(k)] which 
> we can build upon. 

C++ *interfaces* can probably be parsed with LALR
tool like ocamlyacc. At least, I hope so!

The needs of a wrapper generator are considerably weaker
than a compiler. For example given the construction:

int x = expr;

we can parse 'expr' by as a list of tokens followed by semi.
We don't care about the RHS at all, we just need to know 'x'
is an 'int'.

Even if we can't quite parse everything, there are
ways a wrapper generator can handle that (eg just
ignore the declaration, and allow the user to fix
it by hand writing the wrapper for that function).

> > (2) Flxcc can't target Ocaml yet
> 
> This one wouldn't be hard.

I agree, but I haven't tried it.

> So, you do have a rudimentary C++ parser?

I have a sophisticated C parser (frontc/Cil)
which handles GNU and MSVC extensions.

Extending frontc to handle C++ seems easy.
Cil converts the representation to one
more amenable to analysis. Hacking Cil
to accept the new constructors is harder.
For example it checks for redeclarations 
of functions:

void f();
void f() { printf("Hello world"); }

and knows there are the same .. but of course
C++ allows overloading.

> > What's needed is developers.

> Yes. However, doing this wrapper generator is considerably valuable. 

I agree. It would be a great boost for Ocaml I think.
And Ocaml people helping get it to work will also be
helping it to work for Felix .. 

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

On Sunday 06 June 2004 23:41, skaller wrote:
> On Mon, 2004-06-07 at 04:44, Eray Ozkural wrote:
> > On Sunday 06 June 2004 10:00, skaller wrote:
> > > (1) Flxcc can't parse C++ yet
> >
> > I had started writing a modern top-down C++ parser using the
> > combinatorial parser library Parsec in Haskell, but I had failed due to
> > lack of time with the project.
> >
> > There are freely available parser models [LL(k), not LR(k)] which
> > we can build upon.
>
> C++ *interfaces* can probably be parsed with LALR
> tool like ocamlyacc. At least, I hope so!

Well, the interface language isn't that easy, but yes you are basically right. 
g++ was still using the old bison thing; they were talking about writing a 
parser from scratch.  I haven't followed the developments lately, though.

> The needs of a wrapper generator are considerably weaker
> than a compiler. For example given the construction:
>
> int x = expr;
>
> we can parse 'expr' by as a list of tokens followed by semi.
> We don't care about the RHS at all, we just need to know 'x'
> is an 'int'.

You can skip code blocks, assignment statements, etc., but that means you have 
to parse them. :) My idea was that you first needed a complete C++ syntax 
analyzer, and then you can build whatever minimal semantic analyzer you want 
to. Here, we need just a (possibly) full C++ static type analyzer. I was 
venturing in that direction and saw it was so much harder than C, naturally. 
The C++ type system and *syntax* is a mess, especially with templates.

At any rate, I strongly suggest that we (whoever is interested) don't try to 
write the parser from scratch. Just take a known, working and complete 
(supports ISO C++ syntax 100%) model, and translate it into concise 
notation... Of course it'd be great if we could have an LALR parser that we 
wouldn't care about later, but I have no idea how practical that would be. My 
impression with g++ was "ouch", for instance. And in other freely available 
C++ parsers, which are embedded in compilers, I was scrolling up and down 
100kbs of parser code. I left the whole thing a little confused :) Even if 
you have the ISO standard in front of you, you'd be in a lot of trouble 
coding a C++ parser. It's the most stinking PL syntax ever invented. 

I believe my course of action had a merit: use a combinatorial parser system 
so that you have the entire C++ syntax with a 20-30kb code or maybe even 
less. All the compilers I saw were written in the horrible C or C++ languages 
themselves, and even browsing the syntax analyzer code was a nightmare. 
Another bonus you get with these modern parser libs is that it may be easier 
to recover from errors, etc.

program = many declarationExternal

See, that was easy wasn't it? I'm now looking at the Parsec parser I've 
written and it's not quite comprehensible. However, I've at least noted that 
it is adapted from PCCTS. Are there any decent combinatorial parser packages 
for ocaml? (Or is ocaml not abstract enough to do that? *grin*)

The thing to decide is what kind of parser you want. LALR doesn't seem the 
right choice for me. It'd probably take an LR(1) [or even LR(k)] parser to 
write it in a nice way, or LL(k) which might be the more fashionable among 
compiler designers nowadays... (odd as it sounds) Then find a really good 
open source compiler which works that way, and strip its parser logic.

Here are some links about parsing C++
http://www.empathy.com/pccts/
http://www.nobugs.org/developer/parsingcpp/
http://sourceforge.net/projects/opencxx/
http://www.antlr.org/  ---> Does it support C++ now?

I've now recollected the history of my development. I started out with 
Tendra's parser, and after being frustrated with what I thought was a little 
hackish solution, I switched to the approach of PCCTS.

Funny thing, maybe the easiest would be just write the translator code in Java 
using ANTLR, but I've no idea how acceptable that is to ocaml hackers :->

> Even if we can't quite parse everything, there are
> ways a wrapper generator can handle that (eg just
> ignore the declaration, and allow the user to fix
> it by hand writing the wrapper for that function).

Yes, but I'd prefer automatic operation.

> > > (2) Flxcc can't target Ocaml yet
> >
> > This one wouldn't be hard.
>
> I agree, but I haven't tried it.
>
> > So, you do have a rudimentary C++ parser?
>
> I have a sophisticated C parser (frontc/Cil)
> which handles GNU and MSVC extensions.
>
> Extending frontc to handle C++ seems easy.

I believe I had checked FrontC, but I think it is not easy at all because in 
general you shouldn't proceed that way with C++. The two languages are 
unbelievably different! As I said, look around for commentary on writing C++ 
parsers, there are some non-trivial problems that the parser has to solve, 
and I hadn't found them fun :) [Though it was easy enough to write the lexer 
haha]

> Cil converts the representation to one
> more amenable to analysis. Hacking Cil
> to accept the new constructors is harder.
> For example it checks for redeclarations
> of functions:
>
> void f();
> void f() { printf("Hello world"); }
>
> and knows there are the same .. but of course
> C++ allows overloading.

Well, I guess Cil wouldn't be so nice for all the advanced features of C++ 
like classes, class/function templates, member templates, etc.

> > > What's needed is developers.
> >
> > Yes. However, doing this wrapper generator is considerably valuable.
>
> I agree. It would be a great boost for Ocaml I think.
> And Ocaml people helping get it to work will also be
> helping it to work for Felix ..

A parser generator that can cope with C++ adequately is most definitely a 
great boost. As I said, I lack experience with the new features of SWIG, but 
you seem to think it is inadequate. Have you tried it out with any real-world 
C++ libs, does it have serious shortcomings?

Regards,


-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Benjamin Geer]

Eray Ozkural wrote:
> g++ was still using the old bison thing; they were talking about writing a 
> parser from scratch.  I haven't followed the developments lately, though.

The C++ parser in g++ was rewritten as a handcrafted, top-down parser; I 
think work on it was completed last year or the year before.

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

On Monday 07 June 2004 10:41, you wrote:
> Eray Ozkural wrote:
> > g++ was still using the old bison thing; they were talking about writing
> > a parser from scratch.  I haven't followed the developments lately,
> > though.
>
> The C++ parser in g++ was rewritten as a handcrafted, top-down parser; I
> think work on it was completed last year or the year before.

If you would compare the top-down parser in g++ and ANTLR C++ grammar (2003 
release on www.antlr.org), which would be easier to work with for writing a 
translator that needs type analysis? g++ is still written in C, so I guess 
it'd be harder to extract anything useful.

Best Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Basile Starynkevitch local]

On Mon, Jun 07, 2004 at 08:41:11AM +0100, Benjamin Geer wrote:
> Eray Ozkural wrote:
> >g++ was still using the old bison thing; they were talking about writing a 
> >parser from scratch.  I haven't followed the developments lately, though.
> 
> The C++ parser in g++ was rewritten as a handcrafted, top-down parser; I 
> think work on it was completed last year or the year before.

In addition to other suggestions, I would add the possibility to use
GCC XML. See http://www.gccxml.org/ for more.

I don't know much about gcc XML, and I never used it. I just heard
about it, it is apparently a patch to GCC to dump some form of syntax
tree into some form of XML.


-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - Inria Rocquencourt (temporarily)
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

On Monday 07 June 2004 17:18, Basile Starynkevitch local wrote:
> On Mon, Jun 07, 2004 at 08:41:11AM +0100, Benjamin Geer wrote:
> > Eray Ozkural wrote:
> > >g++ was still using the old bison thing; they were talking about writing
> > > a parser from scratch.  I haven't followed the developments lately,
> > > though.
> >
> > The C++ parser in g++ was rewritten as a handcrafted, top-down parser; I
> > think work on it was completed last year or the year before.
>
> In addition to other suggestions, I would add the possibility to use
> GCC XML. See http://www.gccxml.org/ for more.
>
> I don't know much about gcc XML, and I never used it. I just heard
> about it, it is apparently a patch to GCC to dump some form of syntax
> tree into some form of XML.

If it's got all the type info, then it could be used. There is no shortage of 
XML tools in Ocaml, either. [Or is there? :)]

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[skaller]

On Mon, 2004-06-07 at 13:04, Eray Ozkural wrote:

> You can skip code blocks, assignment statements, etc., but that means you have 
> to parse them. :) 

Indeed, but it is enough to do stuff like track matching
brackets to do that. The other tokens don't affect the parse
and just get dropped.

> My idea was that you first needed a complete C++ syntax 
> analyzer, and then you can build whatever minimal semantic analyzer you want 
> to. Here, we need just a (possibly) full C++ static type analyzer. I was 
> venturing in that direction and saw it was so much harder than C, naturally. 
> The C++ type system and *syntax* is a mess, especially with templates.

The syntactic problem itself isn't quite so bad. The real difficulty
is that you need to know, as in C, if a name is a type. In both
C and C++, this means keeping track of typenames. The difference
is that in C this is a simple dictionary lookup. In C++, with
overloading and namespaces and templates etc, the lookup rules are
quite nasty .. so the real problem is that you can't parse
without a structured symbol table and complex lookup rules.

>  Are there any decent combinatorial parser packages 
> for ocaml? (Or is ocaml not abstract enough to do that? *grin*)

Good question. Be nice to have some alternative parsers around.

> A parser generator that can cope with C++ adequately is most definitely a 
> great boost. As I said, I lack experience with the new features of SWIG, but 
> you seem to think it is inadequate. Have you tried it out with any real-world 
> C++ libs, does it have serious shortcomings?

The problem with SWIG for me isn't that it can't parse C++:
there are two problems:

(1) it isn't built for automation (wrapping many libraries
all at once).

(2) It can't dynamically load the SWIG felix module
and the developers won't put it in CVS, so it becomes
a nightmare to build.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Efficient C++ interfacing?

[Eray Ozkural]

On Monday 07 June 2004 17:29, Eray Ozkural wrote:
> If it's got all the type info, then it could be used. There is no shortage
> of XML tools in Ocaml, either. [Or is there? :)]

Of course, to support Qt, we might have to extend gcc XML,which wouldn't be 
too nice.

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners