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

[Sherief N. Farouk]

Would we even need a "virtual interface"? I think most functions can be
statically bound. Take this with a grain of salt however - I haven't gone
through ALUT thoroughly enough. Most of the time, a header with inline
member functions would do with most of the functionality, and if properly
inlined the speed loss would be near nil.

- Sherief

> -----Original Message-----
> From: openal-devel-bounces at opensource.creative.com [mailto:openal-
> devel-bounces at opensource.creative.com] On Behalf Of Chris Robinson
> Sent: Monday, June 02, 2008 7:31 PM
> To: openal-devel at opensource.creative.com
> Subject: Re: [Openal-devel] Using C++ in ALUT?
> 
> 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++.
> _______________________________________________
> Openal-devel mailing list
> Openal-devel at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal-devel