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
What's the problem of passing a a buffer to snprintf into?
const char *file_find(char buf[PATH_MAX], const char *filename)
{
const char *prefix = "/tmp";
snprintf(buf, PATH_MAX, "%s/%s", filename);
return buf;
}
obj = eo_add(class, parent,
GEOMETRY(10, 20, 50, 30),
FILE_SET(file_find(buf1, "image.jpg")),
GROUP_SET(group_find(buf2, "base")));
one big downside from your approach with Eina_Tmpstr is that it's not
clear at all who is responsible to free it. Sure there can be a
convention like "the function receiving Eina_Tmpstr as parameter free
it". But it's a convention prone to bugs. And it will do very bad
things if you pass it around:
void f(Eina_Tmpstr *newname) {
my_movefile(my_homedir(), newname);
my_movefile(my_tmpdir(), newname);
eina_tmpstr_del(newname);
}
> 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.
you shouldn't use a static char buffer, but as many buffers as the
strings you will snprintf.
>
> 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.
this IDE-friendly thing could be made regardless how FILE_SET operates
or am I missing anything?
Lucas De Marchi
------------------------------------------------------------------------------
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
