Best FFI?
rao...@gmail.com
(since I haven't found any 3D engines _in_ a functional language - at
least, ones that could be used to make a 'real' game). Rather than
saying "I love X, I'll suffer through the FFI it has" I'd like to take
a pragmatic approach and say "Which functional language has the
sweetest spot of an easy FFI and sufficient performance?" I would love
to hear any opinions / experiences.
[I guess I'm ideally seeking something that can automagically generate
as much of the FFI junk as possible, or somehow obviates the need for
it, and - of course - doesn't get slow when doing FFI. I do not yet
know if being able to call from C-to-FP is required, but if it is
available I'm sure it would be a plus. Also, it would be super nice if
it were a cross-platform (Win/Vista, Mac OS X, Linux) language.]
Things I've stumbled across:
* Crystal Space 3D has a scripting setup, via Python. Looks neat.
Dunno if it works out to be usable to really write a full-on game in
it?
* Bigloo Scheme sounded like it might have not-as-painful-as-most FFI?
sincerely.
Jon Harrop
> I dream of using some C/C++ 3D engine via some functional language
There are tools like camlidl but, to be honest, I can't think of any
functionality provided by existing free "3D engines" that you can't
implement much more effectively and productively in the FPL yourself
without too much difficulty.
Such libraries tend to consist of a scene graph that imposes mutability and
even OOP with little benefit. Compare that to the much more powerful and
elegant scene graphs implemented in FPLs:
http://www.ffconsultancy.com/products/smoke_vector_graphics/
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
Carlo Capelli
It uses Python as scriting interface to a fast rendering engine.
Anyway, these are complex systems, VPython could be a better toy...
Bye Carlo
<rao...@gmail.com> ha scritto nel messaggio
news:1182290996.7...@g4g2000hsf.googlegroups.com...
Joachim Durchholz
> rao...@gmail.com wrote:
>> I dream of using some C/C++ 3D engine via some functional language
>
> There are tools like camlidl but, to be honest, I can't think of any
> functionality provided by existing free "3D engines" that you can't
> implement much more effectively and productively in the FPL yourself
> without too much difficulty.
Rendering efficiency, possibly.
Optimizing the rendering stage can take quite some time, and not having
to reinvent that wheel could be a real bonus.
If the 3D engine doesn't offer anything beyond that, it might still be
interesting to wrap it just above the rendering level and ignore the
scene description stuff.
> Such libraries tend to consist of a scene graph that imposes
> mutability and even OOP with little benefit.
I agree that OOP isn't very useful in an FPL context.
OTOH I'm not so sure that mutability is a realy problem there.
Wouldn't access to the scene graph and anything below it be
single-threaded anyway? If so, the usual mutability problems (aliasing
in particular) wouldn't matter.
Hmm... I *can* imagine that reusing parts of a scene elsewhere could
still benefit from immutability. I'm thinking stuff like textures, or
the generic standard tree that's planted a gazillion times (and possibly
at different growth states with every position). Is that what you're after?
What else plays a role?
Regards,
Jo
Jon Harrop
> Jon Harrop schrieb:
>> There are tools like camlidl but, to be honest, I can't think of any
>> functionality provided by existing free "3D engines" that you can't
>> implement much more effectively and productively in the FPL yourself
>> without too much difficulty.
>
> Rendering efficiency, possibly.
The rendering efficiency of non-professional engines is typically very poor.
Smoke is many times faster than Cairo and even Windows Presentation
Foundation, for example.
> Optimizing the rendering stage can take quite some time, and not having
> to reinvent that wheel could be a real bonus.
A one-liner in an FPL using iter and lazy filter.
> If the 3D engine doesn't offer anything beyond that, it might still be
> interesting to wrap it just above the rendering level and ignore the
> scene description stuff.
If there are low-level bittwiddling functions then these are best written in
C. However, that is a tiny part of your typical 3D engine.
> OTOH I'm not so sure that mutability is a realy problem there.
Mutability is a huge problem here. Mutability is absolutely crippling here.
I cannot overemphasize this...
> Wouldn't access to the scene graph and anything below it be
> single-threaded anyway?
It is well known that graph manipulation in compiler writing hits all of the
strong points of modern FPLs.
Scene graph manipulation is exactly the same. Garbage collection, sum types,
pattern matching, functional programming, declarative style and
immutability are overwhelmingly beneficial here. This is an application
perfectly suited to modern functional programming languages.
> If so, the usual mutability problems (aliasing in particular) wouldn't
> matter.
Referential transparency is still vitally important in single-threaded
applications.
> Hmm... I *can* imagine that reusing parts of a scene elsewhere could
> still benefit from immutability. I'm thinking stuff like textures, or
> the generic standard tree that's planted a gazillion times (and possibly
> at different growth states with every position).
Font glyphs are an obvious example. I'm not sure what you mean by "growth
states".
> Is that what you're after?
Declarative style is one of the main benefits, yes.
> What else plays a role?
As you've mentioned, concurrency is of increasing importance. In reality,
the scene graph is only immutable from the users point of view. Internally,
it lazily memoizes computations (like bounds).
In addition to the scene graph itself, trees are ubiquitous. A scene graph
is viewed for efficient culling by the renderer via a k-D or BSP tree. Even
the individual elements of a scene graph are often themselves trees, e.g.
in the case of hierarchical subdivision surfaces. A GUI toolkit that sits
atop a vector graphics library is itself another tree of widgets/"controls"
(hboxes, vboxes, scrolled views etc.).
Smoke uses all of these features and was originally written in C++. It is
the perfect example of a commercial application ideally suited to
functional programming that showed huge improvements in all areas (most
notably performance) compared to a conventional implementation in a
conventional language. The redevelopment of Smoke in OCaml was the
revelation that justified our move into functional programming. We have
never looked back.
Just look at the examples on the Smoke page:
http://www.ffconsultancy.com/products/smoke_vector_graphics/
Every one is written declaratively and can reuse styles, geometries, objects
and other scene graphs at will without having to worry about them changing.
The conventional approach is very delicate and easily broken. This approach
is totally robust.
rao...@gmail.com
but, i really am looking for FP + FFI + C/C++ + Already-existing 3D
engine :-) and would love to hear things along the lines of "I used
Gambit FFI and it was <review>" or "there's an amazing automagic FFI
system for <FP>".
a guy can hope.
sincerely.
rao...@gmail.com
ah, interesting, thanks - i'll check into gameblender.org
sincerely.
rao...@gmail.com
Looks like Mz/PLT Scheme might be a good first candidate to try out.
http://wmfarr.blogspot.com/2007/04/why-use-ffi-for-simple-numerical.html
http://download.plt-scheme.org/doc/foreign/foreign-Z-H-1.html#node_chap_1
Marcin 'Qrczak' Kowalczyk
> "Which functional language has the sweetest spot of an easy FFI
> and sufficient performance?" I would love to hear any opinions / experiences.
Haskell has a very nice FFI; actually the best FFI I've ever seen.
Glue code is generally written in Haskell, not in C.
Achieving good performance can be tricky though (this is unrelated to
FFI). It can be great (with GHC as a compiler), it can also be awful
if you are not careful. The problem is not language implementation:
laziness might be hard to reason about.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Jon Harrop
> hi, thanks for the reference, Smoke does look neat!
Thanks. :-)
> but, i really am looking for FP + FFI + C/C++ + Already-existing 3D
> engine :-) and would love to hear things along the lines of "I used
> Gambit FFI and it was <review>" or "there's an amazing automagic FFI
> system for <FP>".
>
> a guy can hope.
I've only written bindings for OCaml and F# but both were quite reasonable.
F# is better but OCaml already has more bindings.
Here are F# bindings to the FFTW library that lets you do FFTs in F# code,
for example:
module Primitive =
open System.Runtime.InteropServices
open Microsoft.FSharp.NativeInterop
[<dllimport(@"libfftw3-3.dll", entrypoint="fftw_malloc">]
extern double *fftw_malloc(int size);
[<dllimport(@"libfftw3-3.dll", entrypoint="fftw_free">]
extern void fftw_free(double *data);
[<dllimport(@"libfftw3-3.dll", entrypoint="fftw_plan_r2r_1d">]
extern void *fftw_plan_r2r_1d(int n, double *i, double *o,
int kind, int flags);
[<dllimport(@"libfftw3-3.dll", entrypoint="fftw_destroy_plan">]
extern void destroy_plan(void *plan);
[<dllimport(@"libfftw3-3.dll", entrypoint="fftw_execute">]
extern void execute(void *plan);
open Primitive
let make n =
let ptr = fftw_malloc(8*n)
let na = NativeArray.FromPtr(ptr, n)
ptr, na
let dst a =
let n = Array.length a
let ptr, arr = make n
Array.iteri (fun i x -> arr.[i] <- x) a
let plan = fftw_plan_r2r_1d(n, ptr, ptr, 7, 0)
execute plan
destroy_plan plan
let s = 1. / sqrt(float(2*(n + 1)))
let a = Array.init n (fun i -> s * arr.[i])
fftw_free ptr
a
So you do little more than present the C declarations to F# (you have to
alter some types) and then the rest is F# code to wrap the library nicely.
rao...@gmail.com
> F# is better but OCaml already has more bindings.
maybe i will break down / cave in and go with come .Net-based engine
for starters; the XNA stuff with F# would probably be not that bad a
life.
Joachim Durchholz
> Joachim Durchholz wrote:
>> Jon Harrop schrieb:
>>> There are tools like camlidl but, to be honest, I can't think of any
>>> functionality provided by existing free "3D engines" that you can't
>>> implement much more effectively and productively in the FPL yourself
>>> without too much difficulty.
>> Rendering efficiency, possibly.
>
> The rendering efficiency of non-professional engines is typically very poor.
> Smoke is many times faster than Cairo and even Windows Presentation
> Foundation, for example.
Windows as a "non-professional engine"...
You made my day!
:-)
>> Optimizing the rendering stage can take quite some time, and not having
>> to reinvent that wheel could be a real bonus.
>
> A one-liner in an FPL using iter and lazy filter.
That's the computational optimization.
I had more the drop-down-to-assembly-where-needed kinds of optimization
(the ones you don't get in C either).
>> If the 3D engine doesn't offer anything beyond that, it might still be
>> interesting to wrap it just above the rendering level and ignore the
>> scene description stuff.
>
> If there are low-level bittwiddling functions then these are best written in
> C. However, that is a tiny part of your typical 3D engine.
Yes, but an important one (the algorithmic stuff is even more important,
of course, but you'd do that anyway regardless of implementation
technology).
>> Wouldn't access to the scene graph and anything below it be
>> single-threaded anyway?
>
> It is well known that graph manipulation in compiler writing hits all of the
> strong points of modern FPLs.
>
> Scene graph manipulation is exactly the same. Garbage collection, sum types,
> pattern matching, functional programming, declarative style and
> immutability are overwhelmingly beneficial here. This is an application
> perfectly suited to modern functional programming languages.
>
>> If so, the usual mutability problems (aliasing in particular) wouldn't
>> matter.
>
> Referential transparency is still vitally important in single-threaded
> applications.
OK, I buy the other aspects, but what are the advantages of immutability
and declarative style in this case?
>> Hmm... I *can* imagine that reusing parts of a scene elsewhere could
>> still benefit from immutability. I'm thinking stuff like textures, or
>> the generic standard tree that's planted a gazillion times (and possibly
>> at different growth states with every position).
>
> Font glyphs are an obvious example. I'm not sure what you mean by "growth
> states".
"Age", really. Not being a native English speaker shows.
(I also now see there's another potential confusion here: I meant the
things with the gree leaves that you see in a scene, not a data structure.)
I.e. the idea is to represent a tree via a closure that takes the tree's
age as a parameter.
One tree function to display thousands of trees :-)
> Smoke uses all of these features and was originally written in C++. It is
> the perfect example of a commercial application ideally suited to
> functional programming that showed huge improvements in all areas (most
> notably performance) compared to a conventional implementation in a
> conventional language. The redevelopment of Smoke in OCaml was the
> revelation that justified our move into functional programming. We have
> never looked back.
Do you know what made the reimplementation faster?
> Just look at the examples on the Smoke page:
>
> http://www.ffconsultancy.com/products/smoke_vector_graphics/
I get a 403 Forbidden when trying to access the tiger's head's OCaml
sources. (I didn't look further, the problem may affect just this one or
other links as well.)
> Every one is written declaratively and can reuse styles, geometries, objects
> and other scene graphs at will without having to worry about them changing.
What kinds of changes would apply to all these objects?
I'm giving lots of questions here. That's not scepticism, I'm genuinely
curious.
Regards,
Jo
Jon Harrop
Yes. Don't forget Managed DirectX and Windows Presentation Foundation as
well. We have F# MDX demos on our site:
http://www.ffconsultancy.com/dotnet/fsharp/
Jon Harrop
> Jon Harrop schrieb:
>> poor. Smoke is many times faster than Cairo and even Windows Presentation
>> Foundation, for example.
>
> Windows as a "non-professional engine"...
> You made my day!
> :-)
:-)
>> If there are low-level bittwiddling functions then these are best written
>> in C. However, that is a tiny part of your typical 3D engine.
>
> Yes, but an important one
Not really. In anything but the simplest applications, memory accesses are
no longer sequential so the dominant cost is the memory gap. That dwarfs
the performance hit of accessing float arrays from a decent high-level
language like OCaml.
So the benefit from doing that is tiny compared to the benefit from
rearranging data structures to improve cache coherency, for example.
>> Referential transparency is still vitally important in single-threaded
>> applications.
>
> OK, I buy the other aspects, but what are the advantages of immutability
> and declarative style in this case?
Reasoning. Inside the library, I can cache results straightforwardly. With
the old mutable approach, every mutation was responsible for working out
which caches it invalidated and then invalidating them explicitly. The
design grew too complex too quickly and that obviated any chance I had of
doing more productive high-level optimizations.
Outside the library, a declarative style has all the usual benefits of
functional programming. Trees are easier to build in a declarative style:
a + b * c
vs
t := c
t *= b
t += a
return t
and so on.
> I.e. the idea is to represent a tree via a closure that takes the tree's
> age as a parameter. One tree function to display thousands of trees :-)
We had actually implemented this in our "F# for Visualizaton" library but we
took it out again. I couldn't see how to reconcile having arbitrary
closures in the scene graph with the assurances that many optimizations
need.
>> Smoke uses all of these features and was originally written in C++. It is
>> the perfect example of a commercial application ideally suited to
>> functional programming that showed huge improvements in all areas (most
>> notably performance) compared to a conventional implementation in a
>> conventional language. The redevelopment of Smoke in OCaml was the
>> revelation that justified our move into functional programming. We have
>> never looked back.
>
> Do you know what made the reimplementation faster?
Incremental collection and locality mostly. Having a garbage collector tuned
for that kind of work beats all other practical options hands down.
Then data structures. OCaml made it trivial to try far more data structures
than C++ even has, and I found some rather obscure ones that work extremely
well.
Boxing. My recent experiments in C# suggest that many programs run faster if
you box values, rather than unbox them. Surprisingly, I found that unboxing
a complex number type given a significant performance boost as expected but
unboxing a 3D vector type degraded performance slightly. So conventional
C++ wisdom is just plain wrong now.
>> Just look at the examples on the Smoke page:
>>
>> http://www.ffconsultancy.com/products/smoke_vector_graphics/
>
> I get a 403 Forbidden when trying to access the tiger's head's OCaml
> sources. (I didn't look further, the problem may affect just this one or
> other links as well.)
Thanks. Should be fixed now. :-)
>> Every one is written declaratively and can reuse styles, geometries,
>> objects and other scene graphs at will without having to worry about them
>> changing.
>
> What kinds of changes would apply to all these objects?
If everything was mutable, anything could be changed under your feet and you
could no longer rely upon any kind of consistency. Everything you do, you
would either have to check that nothing had been changed or convince
yourself that it should not have been changed. You have to know the entire
call-graph to do anything non-trivial.
Joachim Durchholz
> Joachim Durchholz wrote:
>> Jon Harrop schrieb:
>>> in C. However, that is a tiny part of your typical 3D engine.
>>
>> Yes, but an important one
>
> Not really. In anything but the simplest applications, memory accesses are
> no longer sequential so the dominant cost is the memory gap. That dwarfs
> the performance hit of accessing float arrays from a decent high-level
> language like OCaml.
>
> So the benefit from doing that is tiny compared to the benefit from
> rearranging data structures to improve cache coherency, for example.
I wouldn't have thought that that were practical (or even possible) from
a high-level language.
>> I.e. the idea is to represent a tree via a closure that takes the tree's
>> age as a parameter. One tree function to display thousands of trees :-)
>
> We had actually implemented this in our "F# for Visualizaton" library but we
> took it out again. I couldn't see how to reconcile having arbitrary
> closures in the scene graph with the assurances that many optimizations
> need.
I see.
The old "guarantees vs. flexibility" tradeoff.
>>> Just look at the examples on the Smoke page:
>>>
>>> http://www.ffconsultancy.com/products/smoke_vector_graphics/
>>
>> I get a 403 Forbidden when trying to access the tiger's head's OCaml
>> sources. (I didn't look further, the problem may affect just this one or
>> other links as well.)
>
> Thanks. Should be fixed now. :-)
Indeed.
Not that I could understand much of that OCaml code... well, I'd have to
really get down and learn OCaml, probably :-)
>>> Every one is written declaratively and can reuse styles, geometries,
>>> objects and other scene graphs at will without having to worry about them
>>> changing.
>>
>> What kinds of changes would apply to all these objects?
>
> If everything was mutable, anything could be changed under your feet and you
> could no longer rely upon any kind of consistency. Everything you do, you
> would either have to check that nothing had been changed or convince
> yourself that it should not have been changed. You have to know the entire
> call-graph to do anything non-trivial.
OK. I suspected so much, but I wasn't sure whether there were additional
aspects to this.
Very interesting. Thank you very much.
Regards,
Jo
Simon Richard Clarkstone
> Joachim Durchholz wrote:
>
>>OTOH I'm not so sure that mutability is a realy problem there.
>
> Mutability is a huge problem here. Mutability is absolutely crippling here.
> I cannot overemphasize this...
>
>>Wouldn't access to the scene graph and anything below it be
>>single-threaded anyway?
>
> It is well known that graph manipulation in compiler writing hits all of the
> strong points of modern FPLs.
>
> Scene graph manipulation is exactly the same. Garbage collection, sum types,
> pattern matching, functional programming, declarative style and
> immutability are overwhelmingly beneficial here. This is an application
> perfectly suited to modern functional programming languages.
Also, a scene graph will often change only slightly between frames. The
presence of *first-class* mutable cells in many FPLs mean that you can
place mutable parts only where you need to in the graph, and pass around
the mutable cells to the functions that change the scene graph, or pass
around closures that mutate them. In C you might have to pass around
pointers to the fields that were to be mutated, which can lead to nasty
bugs. In Java you would have to pass around the object that contained
the field that needed to be mutated. (Note: the library will of course
need to support the inserting of mutable cells for each of the places
that you will want to insert them; where you don't use a mutable cell,
it can be much more liberal in its caching of values between frames.)
For example, you could have a function that builds a clock. It takes in
and two mutable cells that will contain the angle of the two hands, and
returns the scenegraph containing the shape of the clock. Between each
frame, you mutate the mutable cells to the correct angles for the time
you want to show. If you want several clocks to show the same time, you
just pass the same pair of cells when creating each of them.
In Haskell, the type signature would be:
> makeClock :: IORef Angle -> IORef Angle -> SceneGraph
Possibly, in OCaml (which I don't know much about):
> makeClock : (angle ref, angle ref) -> sceneGraph
--
Simon Richard Clarkstone:
s.r.cl?rkst?n?@durham.ac.uk/s?m?n.cl?rkst?n?@hotmail.com
"August 9 - I just made my signature file. Its only 6 pages long.
I will have to work on it some more." -- _Diary of an AOL User_
Ivan Jager
There's an amazing automagic FFI system for OCaml. Well, kind of. I've
been using ocamlidl. It takes as input something that looks a lot like a
C header file, and it produces a .ml file with external declations and a
C stub file with functions to translate the C types to OCaml.
Unfortunately, if you're using C++ rather than C, and don't have a C
interface to your C++ code, there isn't going to be a lot of things that
will support the C++ ABI. C has a good stable ABI on most platforms,
whereas C++ doesn't, and trying to support an ever changing or
ill-specified ABI is not going to be fun.
Ivan
rao...@gmail.com
> interface to your C++ code, there isn't going to be a lot of things that
> will support the C++ ABI.
Per a note on LtU, I've started looking at http://felix.sourceforge.net/
in the hopes that it is the bee's knees. (I'm saddened by how many
better languages proclaim they are great because they interface with
<drum roll> C. Whereas all the real new work that I would care about
is being done in C++.)
Joachim Durchholz
Well, C++ is far more difficult to interface with.
And the majority of interfaces is still C, not C++.
Actually I'm surprised that C++ is more important than C for anybody at
all; care to give a description how that comes?
Regards,
Jo
Markus E Leypold
I'm not the OP, but I imagine there is a lot of C++ only libraries
around (especially in the GUI domain, like FLTK or Qt).
Regards -- Markus
Joachim Durchholz
> I'm not the OP, but I imagine there is a lot of C++ only libraries
> around (especially in the GUI domain, like FLTK or Qt).
I don't know FLTK, but I'm pretty sure that Qt has a C interface (in
addition to the C++ one).
Since the OO stuff is relatively irrelevant for FPLs anyway, I'd assume
that an FPL wrapper for such a library wouldn't care whether it's going
through C or C++ (and in fact I'd prefer C because it's simpler to
interface with).
Regards,
Jo
Neelakantan Krishnaswami
Joachim Durchholz <j...@durchholz.org> wrote:
> Markus E Leypold schrieb:
>> I'm not the OP, but I imagine there is a lot of C++ only libraries
>> around (especially in the GUI domain, like FLTK or Qt).
>
> I don't know FLTK, but I'm pretty sure that Qt has a C interface (in
> addition to the C++ one).
Casual googling didn't turn it up -- do you have a link?
--
Neel R. Krishnaswami
ne...@cs.cmu.edu
Jon Harrop
> I don't know FLTK, but I'm pretty sure that Qt has a C interface (in
> addition to the C++ one).
> Since the OO stuff is relatively irrelevant for FPLs anyway, I'd assume
> that an FPL wrapper for such a library wouldn't care whether it's going
> through C or C++ (and in fact I'd prefer C because it's simpler to
> interface with).
F# is very interesting in this respect. It compiles functional constructs
into object oriented constructs for .NET, giving you seamless, efficient
and safe interoperability with existing object oriented libraries (like Win
Forms) without having to drop to C. In contrast, writing safe C libraries
for OCaml programs is a nightmare.
Scala probably offers the same advantages for Swing programmers.
Joachim Durchholz
Couldn't find anything either.
Which means it's either trivial (as in "you can call C++ from any C
program with this compiler") or not supported.
OK, found a reference:
http://www.bibsonomy.org/bibtex/207dce109b1f1b297762eb9281993755d/gregor
Regards,
Jo
Markus E Leypold
> Markus E Leypold schrieb:
>> I'm not the OP, but I imagine there is a lot of C++ only libraries
>> around (especially in the GUI domain, like FLTK or Qt).
>
> I don't know FLTK, but I'm pretty sure that Qt has a C interface (in
> addition to the C++ one).
Has it? I don't think so: It extends C++ and is preprocessed to C++. I
don't think there will be any luck using it with C. Didn't find any
hint on a pure C interface at the Trolltech site too, so ... (but I
was in a hurry).
> Since the OO stuff is relatively irrelevant for FPLs anyway, I'd
> assume that an FPL wrapper for such a library wouldn't care whether
> it's going through C or C++ (and in fact I'd prefer C because it's
> simpler to interface with).
Just right, I agree mostly (my experience with LablGtk says you're
right). But you'd have to implement a "projection" to C first and then
write the binding: Some people dislike that, it looks like more
work. So I think the OPs motivation lies there.
Regards -- Markus
Markus E Leypold
> Joachim Durchholz wrote:
>> I don't know FLTK, but I'm pretty sure that Qt has a C interface (in
>> addition to the C++ one).
>> Since the OO stuff is relatively irrelevant for FPLs anyway, I'd assume
>> that an FPL wrapper for such a library wouldn't care whether it's going
>> through C or C++ (and in fact I'd prefer C because it's simpler to
>> interface with).
>
> F# is very interesting in this respect. It compiles functional constructs
> into object oriented constructs for .NET, giving you seamless, efficient
> and safe interoperability with existing object oriented libraries (like Win
> Forms) without having to drop to C. In contrast, writing safe C libraries
> for OCaml programs is a nightmare.
Doesn't SWIG (http://www.swig.org/Doc1.3/Ocaml.html) work for OCaml
any more, or is wrapping the interface just not enough?
>
> Scala probably offers the same advantages for Swing programmers.
Regards -- Markus
Markus E Leypold
Once there was a "binding" called qtc in KDE.
Regards -- Markus
rao...@gmail.com
> write the binding: Some people dislike that, it looks like more
> work. So I think the OPs motivation lies there.
Ja, pretty much.
The research I've done so far indicates that either Irrlicht or Ogre3D
are the ones for me, because they both offer abstractions over either
OpenGL or DirectX, and because both are under active development. The
actually have some bindings to other languages (Java, .Net,
Python, ...), but all the bindings I've seen look kinda under-
supported, so I was hoping to hook up some 'real' language via FFI -
except for how that is probably no fun.
I guess I'm trying to optimize too many variables (graphics that can
theoretically run on my PPC iBook & also on an XBox some day; doing my
code development in something with GC and with a REPL; trying to use
software that is the most actively used and developed and supported in
the graphics engine arena; not spending my time working on yucky glue
code). I might just end up writing my code in C++ after all to get a
hacked up demo going. But lordy I dislike that idea.
Felix looked nice but it is not really a coherent project yet for
anybody other than the main developers, as far as I can tell - it
hasn't built for me yet. So even if Felix worked really well with C++
some day, I don't really want to get side-tracked away from just
actually writing the bloody game. (But then when I'm stuck writing
things out longhand in C++ and doing the compile-run-debug-edit cycle
I'm going to be sad.)
"ack, barf."
raould
http://www-rn.informatik.uni-bremen.de/software/elk/split/cprog/cprog.html
Ivan Jager
Um, any work that cares to be interfaced with is not being written in
C++. In the general case, you can't even link C++ code from C. (Even
though compatibility with C is often touted as a strong point of C++.)
On certain architecture/compiler combinations, if you are careful about
what C++ features you use (eg. no static initializers) you can link C++
code from C and have it "work". Even then, I think it just happens to work
rather than actually being supported. The only direction that *is*
supported is a C++ program linking against C code.
In addition, just about every architecture these days has a good,
stable, C ABI, while pretty much every C++ compiler has their own ABI,
and in some cases it isn't even compatible accross different versions of
the same compiler. Now, why on earth would anyone try to be compatible
with that???
Perhaps it's worth pointing out that even most C++ compilers don't bother
interfacing with code from other C++ compilers. So even C++ is an
example of one of those languages that only interfaces with C, and
unlike many others, it doesn't even bother supporting both directions.
Ivan
raould
> C++. In the general case, you can't even link C++ code from C. (Even
> though compatibility with C is often touted as a strong point of C++.)
I hear ya... yet the interesting 3D engines are in C++. C'est la vie
for me. :) I'll post a Felix demo when I get the time to work it up.
Markus E Leypold
> On 2007-07-07, rao...@gmail.com <rao...@gmail.com> wrote:
>>> Unfortunately, if you're using C++ rather than C, and don't have a C
>>> interface to your C++ code, there isn't going to be a lot of things that
>>> will support the C++ ABI.
>>
>> Per a note on LtU, I've started looking at http://felix.sourceforge.net/
>> in the hopes that it is the bee's knees. (I'm saddened by how many
>> better languages proclaim they are great because they interface with
>><drum roll> C. Whereas all the real new work that I would care about
>> is being done in C++.)
>
> Um, any work that cares to be interfaced with is not being written in
> C++. In the general case, you can't even link C++ code from C. (Even
> though compatibility with C is often touted as a strong point of C++.)
My understanding of this was, that "compatible" meant "you can
continue to use your old C code with C++". C++ folks, as I percieve
it, mostly consider C++ as the better C (which gives pretty flame wars
at comp.lang.c and caomp.std.c at times :-).
Regards -- Markus
Ivan Jager
Was it actually portable, or did it just happen to work with g++/gcc?
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html#faq-32.1
Ivan
Markus E Leypold
Good question. I don't know -- I never was this much interested in it,
since I think calling C++ from C is really asking for trouble (esp WRT
to portability and things that might break later, some years from
now), so should only be done if there is absolutely no other
way. Since "no other way" never happened to me (either C++ was OK or I
could avoid linking against C++ libraries), I was spared the trouble
to find out how well it works. Always assuming it would have been
trouble -- perhaps it has worked flawlessly and still does so? I
haven't followed the fate of the qtc, the supposed C binding of QT
closely. Trolltech only advertises C++ and Java bindings and it is
rarely justifiable in serious projects to use bindings not supported
by the library vendor (except you have good reason to believe,
maintenance will be trivial, e.g. because the bindings are generated
automatically or something like this).
But generally the scarcity of foreign bindings to QT if compared with
the bindings for GTK indicates in my opinion that it is indeed more
difficult to write C++-Bindings to another language than it is to
write C-Bindings (which brings us almost back to the topic of this
thread). And that the fact that QT has been practically defined as a
C++-extension, places it at a disadvantage in that respect.
Regards -- Markus