C++ wrapper for extern development

[Larry Troxler]

Hi Guenter, Karl...

No, I haven't thought seriously about how one would go about it, but
just wanted to know if something had already been done before I thought
about it too much.

I agree, that the C api is pretty straightforward, once it is learned.
What I was thinking of was the possibility to use some template magic in
C++ to simplify the notation, eliminate all the casts, for example, that
are involved in using the var-args passed to the DSP processing
functions (for example). But I don't know if this is possible, and I can
think of a couple of things to consider - (1) Can a C++ interface really
avoid someone having to learn the C API anyway? (2) Can this be really
done just as an add-on (proxy classes, etc) without having to touch the
existing infrastructure? (3) Can it be done without loss of efficiency
in the run-time processing?

Well, like I said, I haven't thought about this in detail much at all,
and was just asking if others have already thought this through. 

Larry Troxler

Karl MacMillan wrote:
> 
> Guenter,
> 
> Glad to have your thoughts on this (I have been meaning to look at Gem for
> the purpose of C++ wrappers for a while, but haven't gotten around to it).
> I think that it is going to be difficult to make externals much simplier -
> the C api is pretty straight forward as it is.  I was thinking more in
> terms of providing subclasses of the wrapper base class that define
> standard types of objects - 1 in / 1 out cotrol object, 1 control in / 1
> dsp out, etc.  Implement a few virtual functions and you have an
> object.  Does anyone have any better ideas?
> 
> I almost think what would be better would be an object 'wizard' - a simple
> script to ask some questions and generate all of the boiler plate code for
> you and you just fill in the functions.  More interesting would be to get
> it to generate all of the boiler plate code for PD, Max/MSP, and
> jMax (along the lines of fiddle)!  Any thoughts?
> 
> Karl
> 
> On Fri, 3 Nov 2000, Guenter Geiger wrote:
> 
> >
> >
> > Gem is really targeted for doing graphics, so it is only partly
> > useable as a base class for pd external objects (look at
> > src/Base/CPPExtern.h).
> >
> > The C++ wrapping of Gem does not really (IMO) take away the complexity
> > of creating externals.
> >
> > This said, it may be a good starting point to investigate how it can
> > be done.
> >
> > I haven't really analyzed the design thouroughly, the drawbacks of
> > GEM's wrapping are:
> >
> > - uses #define instead of templates ( this makes it easier portable to
> >   some extend).
> >   altough the defines reduce the amount of typeing needed for each
> >   external, they do not really clarify what is happening.
> >
> > - adding of messages becomes more complex than in plain C.
> >
> > despite that, having a C++ wrapper would be great, though I think
> > creating a decent API is not that simple.
> > Do you have any concrete suggestions ?
> >
> > Guenter
> >
> > Karl MacMillan writes:
> >  > Have you looked at Gem?
> >  >
> >  > Karl
> >  >
> >  > On Tue, 1 Aug 2000, Larry Troxler wrote:
> >  >
> >  > > Just wondering, has anyone thought about writing some C++ classes that
> >  > > wrap the existing PD code that is used to create classes?
> >  > >
> >  > > I'm not suggesting modifying the existing PD core, but rather, having
> >  > > some classes that encapsulate it, in order to make it easier to code new
> >  > > externs, and to make it more understandable what is going on.
> >  > >
> >  > > Larry
> >  > >
> >  >
> >  > --
> >  > _____________________________________________________
> >  > | Karl W. MacMillan                                 |
> >  > | Computer Music Department                         |
> >  > | Peabody Institute of the Johns Hopkins University |
> >  > | karlmac at peabody.jhu.edu                           |
> >  > | www.peabody.jhu.edu/~karlmac                      |
> >  > -----------------------------------------------------
> >  >
> >  >
> >
> 
> --
> _____________________________________________________
> | Karl W. MacMillan                                 |
> | Computer Music Department                         |
> | Peabody Institute of the Johns Hopkins University |
> | karlmac at peabody.jhu.edu                           |
> | www.peabody.jhu.edu/~karlmac                      |
> -----------------------------------------------------