[Openal-devel] FreeALUT stream proof-of-concept

[Chris Robinson]

On Sunday 08 June 2008 04:39:20 pm Sherief N. Farouk wrote:
> > Because the actual implementation declaration is never exported from
> > the lib
> > (and currently, isn't even declared outside of the file it's in). Don't
> > forget, ALUTStream (which really should be ALUTstream to better match
> > AL
> > type-naming) is a virtual interface with no implementation. The actual
> > implementation is a StreamImpl object, but the app uses it through the
> > base
> > ALUTstream type. An app can't explicitly new an ALUTstream object
> > because it
> > has pure virtuals (the compiler will throw an error).
>
> [Sherief N. Farouk]
>
> Why's that? Why not a base class with overridable, virtual functions? You
> do know the concrete type anyway, which is a stream-from-file, so why not
> give it a natural C++ syntax rather than a C-like bridge?

Because the implementation may change, and if the implementation is exposed to 
the user app it'll break ABI if it ever changes. The object should be 
passible between C and C++ (use the C++ interface in C++ code, even if the 
object is created in C code, and vice versa).


Unless you're talking about something like this:

struct ALUTstream {
    virtual ALboolean ALUT_APIENTRY IsPlaying ()
    { return This->IsPlaying(); }
    virtual ALboolean ALUT_APIENTRY Poll ()
    { return This->Poll(); }
    virtual ALboolean ALUT_APIENTRY PlayOnSource (ALuint sourceID)
    { return This->PlayOnSource(sourceID); }
    virtual ALboolean ALUT_APIENTRY Stop ()
    { return This->Stop(); }

    ALUTstream(a,b,c) : This(alutCreateStreamFromFile(a,b,c))
    { }
    virtual ~ALUTstream()
    { delete This; };

private:
    ALUTstream *This;
};

But that's pretty ugly, with more levels of indirection. Plus, there's a 
problem when you do something like this:

{
    alut::stream stream(a,b,c);
    stream.PlayOnSource(sourceID);
    alcMakeContextCurrent(NULL);
}

The stream will attempt to destroy itself when it goes out of scope, but 
because there's a NULL context, it can't stop the source, and detach/delete 
the (internal) AL buffers. As it is right now, alutDestroyStream will return 
AL_FALSE and delete will throw an exception (what exactly it'll throw I've 
not determined yet). This lets you check the error and retry destroying it.

However, in the case above, an exception would be thrown but the object is 
invariably lost, so the AL buffers are leaked because they couldn't be 
deleted and there's no way to get them.