Hello, On Mon, Jun 17, 2013 at 11:35 PM, Felipe Magno de Almeida <[email protected]> wrote: > On Mon, Jun 17, 2013 at 10:13 AM, Cedric BAIL <[email protected]> wrote: >> On Sat, Jun 15, 2013 at 6:21 AM, Felipe Magno de Almeida >> <[email protected]> wrote:
[snip] >>> 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); Oh yes ! Sorry I misunderstood what you where looking for and it makes sense ! I would just argue on the function name being : void *eo_class_data_get(const Eo_Class *klass); I will put some times next week with Daniel on adding that. If you have time and will before that, a patch will be accepted. >> 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: [snip] > This is would be a small modification, but in a lot of places, but > would make for a better integration between C and C++. That is a really interesting idea. Why not just play with undefining EO_TYPECHECK in your case ? I like the trick of reusing cpp to generate binding. I am not sure how to use it in other case than C++, but worth thinking about it. Thanks, -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
