[Openal-devel] Using C++ in ALUT?
chris.kcat at gmail.com
Mon Jun 2 16:31:21 PDT 2008
On Monday 02 June 2008 08:49:53 am Jason Daly wrote:
> Sherief N. Farouk wrote:
> > I second the ownership opinion. I'd love to have a C++ interface, but
> > that'll need its own ARB-like entity to guarantee consistency. The C++
> > layer would be thin (and inline-able, I believe) enough not to pose any
> > performance issues.
There shouldn't be much of a performance issue, as this virtual interface is
similar to how DirectX works (and there doesn't seem to be any speed issues
there, even in eg. software DirectSound3D). Only difference is, on Windows,
the C interface could touch directly into the struct vtable.. but the
layout's not gauranteed by the C++ ABI, so an actual function would be needed
instead for proper portability.
But still, I'd imagine on most systems, the wrapper function would amount to
two mov's and a jmp.. the calling conventions are the same, and assuming the
stack layout is the same (the implicit 'this' pointer is the first argument
on the stack), it just needs to get the real function address and jump there.
Of course, if it's not the same it'd need to do a bit more work, but it
wouldn't be any worse than having called the interface function directly with
the overhead of one regular function call.
Absolute worst case, for systems that can't deal with the extra call overhead
(and can't get the 2xmov+jmp optimization), we can make system-specific C
macros to call directly into the vtable. eg. on Windows-like vtable layouts,
instead of defining the alutIsStreamPlaying function, we make a macro that
derefs the object twice, and calls the function type at the right offset (you
can look in the d3d/dsound/etc headers to see how it does it). It would be as
if you called the function in C++ (in essense, inlining the C wrapper).
Though if you needed every ounce of speed, I wouldn't imagine you'd use ALUT
> I'm basically thinking the same thing. Leave freealut as-is (we need
> that to be compatible), but there's nothing wrong with creating a C++
> layer on top of it (similar to what OpenAL++ did for OpenAL, at least at
> one time).
Compatibility is my main concern, which is why I brought it up. But how many
systems are there without a useable C++ compiler? Note that we don't *need*
the STL or a bunch of C++ libs, as I'm sure there's plenty of systems with
buggy implementations.. we could still do everything "the C way", just
through a C++ struct instead of C functions.
The gains being having proper inheritence schemes, and letting C++ users pick
and choose which they want to use (and they can even use the same object
across the C/C++ boundary, unlike a wrapper where the C++ version is an
object in and of itself that's difficult to use in C). And, personally, I
find raw objects like this:
rather ugly and unweildy for larger classes (what happens if it's copied to
another object? do they share the same buffers/source? what if the original
goes out of scope? a whole world of hurt with reference counting just waiting
to trip, IMO..).
Also, I'm not suggesting we make all of FreeALUT C++, or convert the existing
functions to this method. alutCreateBufferFromFile and such wouldn't make
sense with an interface (it returns AL stuff directly). But it shouldn't be
an issue to make new methods, that require an explicit ALUT object, work this
way. The current stuff would remain C, and a streaming API could be made
More information about the Openal-devel