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

[Eray Ozkural <exa@kablonet.com.tr>]

On Wednesday 09 June 2004 00:19, £ukasz Dobrek wrote:
> On Tue, Jun 08, 2004 at 11:49:18PM +0300, Eray Ozkural wrote:
> > Date: Tue, 8 Jun 2004 23:49:18 +0300
> > From: Eray Ozkural <exa@kablonet.com.tr>
> > Subject: Re: [Caml-list] Re: Efficient C++ Interfacing?
> > To: Fritz Wuehler <fritz@spamexpire-200406.rodent.frell.eu.org>
> > Cc: caml-list@inria.fr
> >
> > On Tuesday 08 June 2004 18:02, Fritz Wuehler wrote:
> > > > Sure but this is a C++ code generator
> > >
> > > No, see the Overview.
> > > "OpenC++ is a toolkit for C++ translators and analyzers."
> >
> > Good. I had checked out OpenC++ but I don't know the current state so let
> > me ask.
> >
> > 1. Is it 100% ISO C++ compatible?
>
> Nope, appart of the fact that I have not seen a 100% ISO compatibile
> compiler yet, this one is for shure not one of them.
>
> I watched it once carefully, now I don't remember so well all the
> problems, but for the record:
> - It won't parse namespaces aliases.
>         ( namespace identifier = org_namespace_name ; )
> - It's mechanism of type resolution is not supporting typedefs.
> - It's mechanism which is suppose to find for a member template function
>   definition its declaration in the class definition, will not work
>   if the names of the template parameters differ in this two cases:
>    template< class T >
>    class A
>    {
>     int f();
>     }
>
>     template<class NOT_T>
>     int A<NOT_T>::f(){ return 1 ; }
>
> there was more but It is all I could find out again now.

Okay, thank you very much for the information. The member template function 
bug should not matter too much, because as discussed in another thread, 
interfacing C++ templates from ocaml is awkward and unreliable, it seems 
practically impossible at the moment. I wonder what the INRIA team thinks 
about it, is it theoretically impossible to interface C++ template functions? 
The other bugs do not sound nasty, but in a large library, a host of typedefs 
and aliases are likely to be found. Namespaces aren't used like as in boost, 
in Qt/KDE libs, but I expect their use to increase (as in KDevelop code), and 
there is probably a lot of typedefs (although I can't tell just how much in 
the interfaces), especially the latter would be a serious problem.

I think the best for me is to try these parsers systematically on the target 
code, and see if they fail. There does not seem a better recourse. The ANTLR 
C++ parser seems impressive, it's said to actually parse MFC libraries IIRC, 
it was also being used in KDevelop (the C++ support is a critical component 
apparently). The only sad thing about these systems is that they are not 
written in ocaml. :) 

> Anyway I think it is an excellent project and can be very usefull.
> In hope it helps

Thanks again. I'm now getting the impression that I need to complete my 
self-training of ANTLR parser generator as well as OpenC++.

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