Hello,
On Sat, Jun 15, 2013 at 6:21 AM, Felipe Magno de Almeida
<felipe.m.alme...@gmail.com> wrote:
> On Fri, Jun 14, 2013 at 12:52 PM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
>> On Fri, 14 Jun 2013 11:02:36 -0300 Felipe Magno de Almeida
>> <felipe.m.alme...@gmail.com> said:
>
> [snip]
>
>> > I'm using metaprogramming in C++ for binding to Eo, but it is proving very
>> > difficult for lack of void* data parameters for class functions, e.g.,
>> > class_constructor,
>> > class_destructor, constructor. Also, see below.
>>
>> more details?
>
> [snip]
>
> The syntax isn't yet fixed of course and it is still very
> experimental. But, what
> I have almost working right now is something like this:
>
> PS: 27 and 28 are the numbers for the op call, I haven't yet abstracted
> calling,
> so I have to do this manually right now, since I'm not using the same syntax
> as C.
[snip example]
> I'm not yet handling overrides et al, but they don't seem very hard to extend.
> The problem I'm facing though is, when I register the class (eo_class_new),
> I have all pointers-to-members (and their signatures). So, I create a vtable
> (indexed by number -> pointer-to-member) and then I have the functions
> that will interface with Eo be instantiated by this index, function signature
> and class type (struct simple in the example above). It has this signature:
>
> template <int I, int N, typename T, typename F>
> EAPI void eo_member_function(Eo* obj, void* class_data, va_list* list);
>
> I = index in the vtable, N is the size of the vtable (so I can avoid dynamic
> allocating the vtable), T is the class and F is the function-member signature,
> e.g., void(T::*)(int*) const.
>
> The problem is, I can't pass the vtable directly to the constructor, or save
> it anywhere in the Eo_Class. So I needed to improvise and use local
> static to allocate them like this:
>
> template <int N, typename T>
> vtable<N, T>* get_vtable()
> {
> static vtable<N, T> v;
> return &v;
> }
>
> Which works, but has a few limitations, for example thread-safety on
> pre-C+11, also I can't use the same T and N, e.g. struct simple, for different
> Eo classes because the local static would be the same, and consequently the
> same vtable.
>
> Another problem is that I can't fill this vtable in the class_constructor,
> because I couldn't find a way to pass any information to class_constructor
> because it only receives a just constructed Eo_Class*.
Why don't you create your own constructor instead of using the default
eo_constructor. That constructor would be used in all case by your C++
class anyway. If you didn't see it yet, look for eo_constructor in
Eo.h.
> If, on the other hand, oe_class_new had a void*data parameter, I could do
> more in the class_constructor, and, to make it even better,
> Eo_Class_Description
> had a size parameter for additional data in Eo_Class that I could modify
> freely
> (think of it as a static variable members, shared for all Eo* instances from
> the
> same Eo_Class*), then I could use this space for the vtable and avoid the
> local static workaround completely, and still avoid more dynamic allocations.
There is a data_size in Eo_Class_Description. You should be able to do
something like sizeof (Private_Data) + vtable_size, I think. Would
that work for you ?
In any case your work is really interesting to me as I want at some
point to be able to have Eo class written in JS and I bet that if you
manage to do what you want in C++, JS should be doable. So validating
the API is very important. If there is something we need to change,
now is a good time !
Thanks for your help,
--
Cedric BAIL
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
