On Thu, Nov 10, 2016 at 10:15 AM, Jean-Philippe André <j...@videolan.org> wrote:
> On 10 November 2016 at 18:49, Carsten Haitzler <ras...@rasterman.com> wrote:
>
>> On Wed, 9 Nov 2016 12:14:36 -0200 Gustavo Sverzut Barbieri <
>> barbi...@gmail.com>
>> said:
>>
>> > Hi all,
>> >
>> > I'm using Eo extensively and its Eolian works well, great work.
>> >
>> > But one thing that I struggle in my examples is to translate
>> > enumerations to string and back. I have to repeat that similar code in
>> > my examples and I wonder if Eolian should generate them for me... I
>> > guess so, what's your take on that?
>> >
>> > Also, please add another marker for "enum" that informs it's a
>> > bitwise, we just document that, but would be nice to have a formal way
>> > to inform. Maybe also something in the pass/return of values, to
>> > specify if it takes a single or multiple. Like this:
>> >
>> > enum @bitwise Mode {
>> > read, [[ being bitwise, no values means (1 << 0)]]
>> > write, [[ 1<<1 is automatic]]
>> > }
>> >
>> > generates:
>> > const char *mode_str_to(enum Mode); // for single entry
>> > enum Mode mode_str_from(const char *Mode); // for single entry
>> >
>> > const char *mode_bitmask_str_to(unsigned Mode); // for many entry
>>
>> this one above is going to suck for bitwise. you'd have to generate a
>> biffer -
>> you couldn't sanely generate "all combinations" and compile theme except
>> for
>> very trivial examples. then the q is - what buffer is this? a single one
>> isnt
>> very usable. :(
>>
>> jpeg brought this up today. he might expand on this. :)
>>
>
> Yes. Based on raster's eina_freeq, we could create a temporary string API.
>
> An API that, unlike eina_tmpstr, does not require any manual free. By
> definition, a string would be valid only for the current scope. (with a
> small gotcha if ecore_main_loop_iterate is called).
>
> At the moment, eina_freeq is used for "safety" but I think some kind of
> garbage collected objects API could be useful, especially for strings. That
> way we could simply return const char* in many places without having to
> worry about static allocation, or requiring the user to free each string.
full ACK on that.
also, I wish we could go systemd's route and simply rely on GCC
attribute cleanup on our code. Not sure it works for returns, but in
all other places it ditches half of the code, things like:
x = open()
if (!done(x)) goto error;
other(x);
close(x);
return;
error:
close(x);
becomes simply:
__attribute__(cleanup(close)) x = NULL;
x = open();
if (!done) return;
other(x);
It's pretty much like C++ destructors that get called when variable go
out of scope...
Real example
https://github.com/systemd/systemd/blob/master/src/core/load-fragment.c#L366
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
