On Tue, 22 Jun 2004 14:14:04 +0300
Eray Ozkural <exa@kablonet.com.tr> wrote:

> On Tuesday 22 June 2004 09:41, art yerkes wrote:
> > On Mon, 21 Jun 2004 22:24:07 +0300
> >
> > Eray Ozkural <exa@kablonet.com.tr> wrote:
> > > On Saturday 19 June 2004 10:29, art yerkes wrote:
> > > > The SWIG module for Ocaml has support for a few STL
> > > > types.  If you use those interfaces as a guide, you
> > > > could add support for more if the automatic wrapping
> > > > doesn't suit.
> > > >
> > > > SWIG isn't perfect for everyone but some needs are
> > > > met very well, including using templates.
> > > >
> > > > Look at http://www.swig.org/
> > >
> > > How does it handle convert C++ templates to ocaml code, I wonder. I had a
> > > design in my mind, but it required quite a bit of monkeying around.
> > > What's their solution?
> >
> > The current solution is to specify which specializations of a given
> > template will be needed, after which the specialized template classes are
> > treated as ordinary classes.
> 
> OK. Imagine client ocaml code that uses template class C < T >. I had imagined 
> that the specializations in the ocaml code ( C < int >, C < vector<float> 
> >, ... ) could be determined automatically, after which the specializations 
> are generated in C++ stub code, and linked in... So I guess I had in mind a 
> more generic version of SWIG's approach, however I doubt this won't be a good 
> mapping.... Can you guys imagine any other alternatives, or should we avoid 
> templates in C++ libraries that want an ocaml binding (like KDE) ?

In my experience, the C++ and ocaml type systems are different enough that
determining specializations from caml code won't work well.

Consider that:

std::set<const char *>
std::set<char [18]>
std::set<std::string>

are all different specializations of std::set on various representations of
string in C++.  The syntax to choose among them may not be easy for a user
to write and keep track of.
-- 
Hey, Adam Smith, keep your invisible hands to yourself!

-------------------
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