On Mon, Jun 17, 2013 at 10:13 AM, Cedric BAIL <cedric.b...@free.fr> wrote:
> Hello,
Hello,
> On Sat, Jun 15, 2013 at 6:21 AM, Felipe Magno de Almeida
> <felipe.m.alme...@gmail.com> wrote:
[snip]
>> 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.
I see, I hadn't abstracted constructors yet, which will call eo_add_internal
and will define their own constructors. I thought the 'standard' way to define
default-constructors (ones that don't have any parameters)
was to define EO_BASE_SUB_ID_CONSTRUCTOR and use eo_add as
is the case with ecore_anim, ecore_idle_enterer, ecore_idle_exiter, ecore_job,
ecore_poll, ecore_timer and others. But thinking now, I can add parameters
to the constructor which would be used to pass the vtable pointer to the
constructor.
>> 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 ?
This Private_Data is per instance right? It would be interesting a space which
wer per Eo_Class for the vtable. And if it was allocated in the same space
as Eo_Class, then it would add more locality and wouldn't require a vtable
pointer to each instance. Though I'm not so sure if it is that important now.
There could be a custom_data_size in Eo_Class_Description which
would make the allocation for Eo_Class to be sizeof(Eo_Class)+custom_data_size
and eo_class_get_custom_ptr(klass) return (char*)klass + sizeof(Eo_Class);
> 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 !
Well, I'm not sure it validates it so much, because the implementation is
quite complicated with *a lot* of preprocessor metaprogramming and template
metaprogramming to create automatically the class and the functions that
handle varargs from the signature automatically, do the pointer-to-member
and etc. The binding for the legacy API is *much easier*, but the binding
to the legacy API doesn't include override of course, because the legacy
doesn't do override, but it is much easier in C++ to abstract callbacks than
to generate the binding for APIs in Eo.
Something that could make it much easier to generate bindings for C++ would
be for the #define's that abstract calling within eo_do to be able to generate
signature information at preprocessor time.
For example:
Instead of having:
#define eo_base_data_set(key, data, free_func)
EO_BASE_ID(EO_BASE_SUB_ID_DATA_SET), EO_TYPECHECK(const char *, key),
EO_TYPECHECK(const void *, data), EO_TYPECHECK(eo_base_data_free_func,
free_func)
It could be:
#define eo_base_data_set(key, data, free_func)
EO_BASE_ID(EO_BASE_SUB_ID_DATA_SET), EO_PARAMS(EO_PARAM(const char *,
key), EO_PARAM(const void *, data), EO_PARAM(eo_base_data_free_func,
free_func))
#define EO_TYPECHECK_PARAMS(X) X
#define EO_PARAMS EO_TYPECHECK_PARAMS
#define EO_PARAM EO_TYPECHECK
So I could in the library:
#define EFLCXX_EO_PARAM(TYPE, ARG) TYPE
#define EFLCXX_EO_PARAMS(PARAMS) void(PARAMS)
#undef EO_PARAM
#undef EO_PARAMS
#define EO_PARAM EFLCXX_EO_PARAM
#define EO_PARAMS EFLCXX_EO_PARAMS
So the signature doesn't have to be replicated, like this:
eo_class_c(eo_base
, (eo_base_data_set)(eo_base_data_get)
, ...
)
Or even maybe:
eo_class_c(eo_base
, (data_set)(data_get)
, ...
)
#undef EO_PARAM
#define EO_PARAM TYPECHECK
#undef EO_PARAMS
#define EO_PARAMS EO_TYPECHECK_PARAMS
This is would be a small modification, but in a lot of places, but
would make for a better integration between C and C++.
> Thanks for your help,
> --
> Cedric BAIL
Regards,
--
Felipe Magno de Almeida
------------------------------------------------------------------------------
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
