On Wed, Oct 17, 2012 at 11:27 AM, Carsten Haitzler <ras...@rasterman.com>wrote:

> On Wed, 17 Oct 2012 10:01:23 -0300 Gustavo Sverzut Barbieri
> <barbi...@profusion.mobi> said:
>
> did u read the docs provided? they provide example use cases (simplified).
>
> as to the below - the cost of the ptr isn't worth worrying about - they are
> temporary... VERY temporary. it's a special thing to allow c to be more
> like
> js/lua/shell etc. think of eobj. now we do things like
>
> obj =  eo_add(class, parent,
>               GEOMETRY(10, 20, 50, 30),
>               FILE_SET("/path/to/file"),
>               GROUP_SET("groupname"));
>
> ok - so file is a constant string. so is group. now let's pretend we want
> to
> FIND a data file in a path or relative to the apps installed dir at
> runtime and
> we have:
>
> const char *file_find(const chart *file);
>
> how could i do something convenient like
>
> obj =  eo_add(class, parent,
>               GEOMETRY(10, 20, 50, 30),
>               FILE_SET(file_find("image.jpg")),
>               GROUP_SET(group_find("base")));
>
> the only way is to provide a buffer to snprintf into OR to return a
> strduped or
> strinshare'd string... the problem is all our existing api doesn't free
> this
> string afterwards. it has no idea where the string came from so you CANNOT
> do
> the above as you will leak strings as no one frees them. the alternative is
> that you have to do it in 2 stages - get the strings first, then call the
> api,
> then free them afterwards. imaging you wanted to find 2 different files -
> so
> you couldnt use a static char buffer either as u'd overwrite the same
> buffer
> within the call args.
>
> tmpstr solves that by provide a very short list of "currently active"
> strings
> that are duplicated and survive as a return string SO they can be passed
> in as
> params to the method above and then be freed by the method when done. the
> advantage is they are really simple and trivially detected as being a
> tmpstr or
> not. if not it does what it does now - leaves it alone. it may be a const
> str
> or some other buffer that doesn't need freeing here. this system is to be
> able
> to preserve an entire string as a return value long enough to go INTO
> another
> func as is given as examples in the docs.
>
> this is also part of making things IDE friendly. as above with FILE_SET
> literally an IDE could provide not just autocomplete but once u start
> typeing
> in FILE_SET(... pop up a file browser to select a data file from your apps
> "project tree" without having to find the full file name and just put it in
> there with the file find api as above nicely for you. as you scroll around
> a
> thumbnail of the file is provided above.near the entry in the src and if u
> want
> ot change it just click on it and select something else. it's making it
> user
> friendly AND compact. it's one step of many.
>

Cedric did explain this to me, and I'm worried and scared the way things
are going.

In my opinion this will break expectation and will induce users to leak.

They already leak now, where the expected behavior is "i receive a const, I
don't keep it, you must free afterwards". If you introduce "I receive a
const, which I may free", then you'll see leaks to show more and more. This
is based on USER, not our code.

As usual the problem will be to handle the incorrect usage and corner cases.

I agree C is cumbersome and you always need 3 lines, one to
declare-type-and-get, another for the real call, another to release. But
that's the language you choose for the project. So keeping it consistent
would be nice.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to