--snip--
> I do understand these concerns. However, my disappointment was not
> about the lightness of the wrappers, but rather their non-idiomatic
> C++. Most of the time this implies no compromise efficiency wise and
> even when it does, the difference is not going to be important, and
> even if it is going to be important you can always fall back to the C
> interface if you really feel the need. For example, in ++dfb there is a
> macro __DFB_PLUS_PLUS__INTERFACE_CLASS that is used to produce the
> common reference counting functionality code for C++ versions of
> interface classes. The idiomatic C++ way of doing this - which I use in
> my wrapper - is to define a template class
>
> template <typename T>
> class Interface { ... }
>
> and then inherit this base class in the interface wrapper classes.
> There is no need for any virtual functions or indirections or what not
> and the result is just as fast as the macro way.
yes, i also have been working on that template stuff.
imho
at first you must have 2 template parameters, first is the implementing class
and second is the corresponding _C class/struct.
also you must have a (remark IAny was supposed to be the template's class name)
IDirectFBClass(IDirectFBClass_C *myptr = NULL):IAny<IDirectFBClass,
IDirectFBClass_C>(myptr){}
constructor defined explicitly.
at that point of time - i was running into some trouble, not everything was
left as smooth to implement for
the end user. i stopped work on this at that point of time, but will come back
to it later this month.
> My goal is simply to have a header-only inline idiomatic C++ wrapper
> for those portions of DirectFB that I need. But since I quite like
> DirectFB I'm starting to think I could just go and wrap the whole
> things. The tedious part is writing helper interfaces for various DFB
> data types so that they can be used in idiomatic fashion. As an
> example, I have a Coord2d<T> template and a Rect<T> template with
> Rect<Int> automatically convertible to DFBRectangle* and DFBRegion*
> (internally this is just a reinterpret_cast so again no efficiency is
> really lost). Things like DFBSurfaceDescription and its ilk are more
> problematic, but currently I'm thinking about having setter functions
> that update the field describing which fields of the structure are
> valid.
>
of course you can act in this way, but please do somekind of benchmarking if
you
are creating template classes and reinterpret_cast's against current
implementation.
> > as mentioned before - feel free to implement a ++DFB-NG or whatever you
> > will call it. i'm looking forward to see it appearing at cvs-ml :)
>
> Ok. I think I'll have something ready this week.
>
nice :)
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
