Why don't you use the existing C++ wrappers -- because of this
business of loading both the float and the double version? Are you
using one wrapper for each library, or one wrapper for both libraries?

The hashtable access time should not be a real problem. You can reduce
it further by using a std::vector and use an index into this
vector as a handle to Csound. Every time you create an instance of
Csound, you push the Csound object pointer onto this vector, and use
the index as a reference to it. Then you have essentially one extra
dereference, period, over using the raw CSOUND pointer. This should be
more or less unnoticeable.

However, my real question is this. You have a CSOUND object in your
wrapper, right? Then you should do this:

void *hostData = csound->GetHostData(csound);

Instead of this:

void *hostData = csoundGetHostData(csound);

The entire Csound API is stored as function pointers in the Csound
object in this way, it is already object-oriented. These pointers are
of course the ones from the correct library.

Hope this helps,
Mike


On 8/22/09, Andy Fillebrown  wrote:
>
> maybe this has a simple C++ specific solution that doesn't concern Csound,
> but it is beyond me at the moment...
>
> I'm dynamically loading both the floats and doubles version of the C api
> simultaneously and wrapping them in C++ classes. The problem I'm running
> into is I can't retrieve host data from the CSOUND pointer passed in the
> callbacks because I don't know which library made the call. Is there a way
> to know which library has called the callback so that I can get the correct
> address of "csoundGetHostData"?
>
> My current solution is to track each wrapper class's creation and
> destruction using a static hash table with the CSOUND pointer as the key.
> This works well enough, but the additional access time leaves me wondering
> if there's a better way. Usually when working with callbacks I'm able to
> specify my own address that will be passed back, too, but I do not see a way
> of doing this in the Csound api -- and from the projects I've browsed it
> appears the api is not designed with dynamic loading in mind. I can't help
> but wonder if I'm missing something, though, or if maybe someone else is
> using the Csound libraries this way and has resolved similar issues already.
>
> Regards,
> ~ andy.f
>
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

----- "Michael Gogins"  wrote:
> Why don't you use the existing C++ wrappers -- because of this
> business of loading both the float and the double version?

Yes, I'm making a Qt-based set of classes that wrap the Csound API.  Part of what I want to do with it involves linking to the Csound libraries at run time using QLibrary instead of linking at compile time.


> Are you using one wrapper for each library, or one wrapper for both
> libraries?

One wrapper for both.


> However, my real question is this. You have a CSOUND object in your
> wrapper, right? Then you should do this:
> 
> void *hostData = csound->GetHostData(csound);
> 
> Instead of this:
> 
> void *hostData = csoundGetHostData(csound);
> 
> The entire Csound API is stored as function pointers in the Csound
> object in this way, it is already object-oriented. These pointers are
> of course the ones from the correct library.

Yes, but I have mutltiple csound libraries loading and linking at run time, and they are using the same set of static callbacks with the only differentiating argument being the CSOUND pointer passed back.  Since the callback could be originating from any of the libraries currently loaded, I have no way of calling the correct library's "csoundGetHostData" to get my wrapper classes pointer back without knowing which library the CSOUND struct was allocated in ...so if I have both the single and double precision versions of Csound loaded it makes any eventual call to "csoundGetHostData" from inside my callback function impossible (afaik) since calling the incorrect library's "csoundGetHostData" won't work if it's not the library that the CSOUND struct being pointed to was created in.  I can re
 solve and link to any one of the csoundGetHostData functions at runtime from any one of the libraries currently loaded, but only one will actually return the correct host data.  In contrast -- when setting up callbacks in other API's I'm allowed to specify the address of any user-data via a void pointer that will be passed back to the callback, in addition to any arguments specific to that particular API.  This allows simplified use of the callback whether the library is bound early or late.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Let's say you have callback:

int mycallback(CSOUND *csound,...);

You have in your wrapper:

CSOUND *floatCsound;
CSOUND *doubleCsound;

Your callback is called:

int mycallback(CSOUND *csound,...)
{
 // NOT!!!! csoundGetHostData(csound);
  void *myHostData = csound->GetHostData(csound);
}

The CSOUND:GetHostData function is csoundGetHostData from the same
library as CSOUND *floatCsound or doublecsound was created from. If
the callback is called from the float library, the CSOUND::GetHostData
function here is the one from the float library. If the callback is
called from the double library, the CSOUND::GetHostData here is the
one from the double library. This kind of thing is the whole reason
why all the API functions are members of the CSOUND structure.

I don't get what your problem is with this -- send me your code?

Regards,
Mike

On 8/23/09, Andy Fillebrown  wrote:
>
>
> ----- "Michael Gogins"  wrote:
>> Why don't you use the existing C++ wrappers -- because of this
>> business of loading both the float and the double version?
>
> Yes, I'm making a Qt-based set of classes that wrap the Csound API.  Part of
> what I want to do with it involves linking to the Csound libraries at run
> time using QLibrary instead of linking at compile time.
>
>
>> Are you using one wrapper for each library, or one wrapper for both
>> libraries?
>
> One wrapper for both.
>
>
>> However, my real question is this. You have a CSOUND object in your
>> wrapper, right? Then you should do this:
>>
>> void *hostData = csound->GetHostData(csound);
>>
>> Instead of this:
>>
>> void *hostData = csoundGetHostData(csound);
>>
>> The entire Csound API is stored as function pointers in the Csound
>> object in this way, it is already object-oriented. These pointers are
>> of course the ones from the correct library.
>
> Yes, but I have mutltiple csound libraries loading and linking at run time,
> and they are using the same set of static callbacks with the only
> differentiating argument being the CSOUND pointer passed back.  Since the
> callback could be originating from any of the libraries currently loaded, I
> have no way of calling the correct library's "csoundGetHostData" to get my
> wrapper classes pointer back without knowing which library the CSOUND struct
> was allocated in ...so if I have both the single and double precision
> versions of Csound loaded it makes any eventual call to "csoundGetHostData"
> from inside my callback function impossible (afaik) since calling the
> incorrect library's "csoundGetHostData" won't work if it's not the library
> that the CSOUND struct being pointed to was created in.  I can resolve and
> link to any one of the csoundGetHostData functions at runtime from any one
> of the libraries currently loaded, but only one will actually return the
> correct host data.  In contrast -- when setting up callbacks in other API's
> I'm allowed to specify the address of any user-data via a void pointer that
> will be passed back to the callback, in addition to any arguments specific
> to that particular API.  This allows simplified use of the callback whether
> the library is bound early or late.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Are you recommending including csoundCore.h and making the CSOUND pointer transparent?

I was under the impression that leaving the CSOUND pointer opaque was more flexible when loading the libraries dynamically, allowing users to specify in the host app which csound library to use instead of having to recompile and relink to a different one each time ...and AFAIK I can't resolve csound->GetHostData dynamically by function name only like I can with csoundGetHostData, and by being able to load and link the wrapper to the Csound API library at runtime it allows users to specify not only which float version of the API to use but also which release version as long as the "csoundXXX" function names remained the same across releases.  Where the function pointers are located in the struct alignment would then be a non-issue.  If I include any particular version of csoundCore.h wouldn
 't I lose the benefit of being able to late-bind to different versions of the Csound API simultaneously?



----- "Michael Gogins"  wrote:
> Let's say you have callback:
> 
> int mycallback(CSOUND *csound,...);
> 
> You have in your wrapper:
> 
> CSOUND *floatCsound;
> CSOUND *doubleCsound;
> 
> Your callback is called:
> 
> int mycallback(CSOUND *csound,...)
> {
>  // NOT!!!! csoundGetHostData(csound);
>   void *myHostData = csound->GetHostData(csound);
> }
> 
> The CSOUND:GetHostData function is csoundGetHostData from the same
> library as CSOUND *floatCsound or doublecsound was created from. If
> the callback is called from the float library, the
> CSOUND::GetHostData
> function here is the one from the float library. If the callback is
> called from the double library, the CSOUND::GetHostData here is the
> one from the double library. This kind of thing is the whole reason
> why all the API functions are members of the CSOUND structure.
> 
> I don't get what your problem is with this -- send me your code?
> 
> Regards,
> Mike
> 
> On 8/23/09, Andy Fillebrown  wrote:
> >
> >
> > ----- "Michael Gogins"  wrote:
> >> Why don't you use the existing C++ wrappers -- because of this
> >> business of loading both the float and the double version?
> >
> > Yes, I'm making a Qt-based set of classes that wrap the Csound API. 
> Part of
> > what I want to do with it involves linking to the Csound libraries
> at run
> > time using QLibrary instead of linking at compile time.
> >
> >
> >> Are you using one wrapper for each library, or one wrapper for
> both
> >> libraries?
> >
> > One wrapper for both.
> >
> >
> >> However, my real question is this. You have a CSOUND object in
> your
> >> wrapper, right? Then you should do this:
> >>
> >> void *hostData = csound->GetHostData(csound);
> >>
> >> Instead of this:
> >>
> >> void *hostData = csoundGetHostData(csound);
> >>
> >> The entire Csound API is stored as function pointers in the Csound
> >> object in this way, it is already object-oriented. These pointers
> are
> >> of course the ones from the correct library.
> >
> > Yes, but I have mutltiple csound libraries loading and linking at
> run time,
> > and they are using the same set of static callbacks with the only
> > differentiating argument being the CSOUND pointer passed back. 
> Since the
> > callback could be originating from any of the libraries currently
> loaded, I
> > have no way of calling the correct library's "csoundGetHostData" to
> get my
> > wrapper classes pointer back without knowing which library the
> CSOUND struct
> > was allocated in ...so if I have both the single and double
> precision
> > versions of Csound loaded it makes any eventual call to
> "csoundGetHostData"
> > from inside my callback function impossible (afaik) since calling
> the
> > incorrect library's "csoundGetHostData" won't work if it's not the
> library
> > that the CSOUND struct being pointed to was created in.  I can
> resolve and
> > link to any one of the csoundGetHostData functions at runtime from
> any one
> > of the libraries currently loaded, but only one will actually return
> the
> > correct host data.  In contrast -- when setting up callbacks in
> other API's
> > I'm allowed to specify the address of any user-data via a void
> pointer that
> > will be passed back to the callback, in addition to any arguments
> specific
> > to that particular API.  This allows simplified use of the callback
> whether
> > the library is bound early or late.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus
> > on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and
> focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net