[Openal-devel] Using C++ in ALUT?

[Chris Robinson]

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

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

ALUT::Stream stream("somefile.ogg");
stream.PlayOnSource(SourceID);
while(stream.IsPlaying())
    stream.Poll();

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 
C/C++.