On Mon, 23 Apr 2012 10:46:36 +0900 Cedric BAIL <cedric.b...@free.fr> said:
> On Tue, Apr 17, 2012 at 5:01 PM, Tom Hacohen <tom.haco...@samsung.com> wrote:
> > On 17/04/12 10:55, Carsten Haitzler (The Rasterman) wrote:
> >> i don't see the point. it's just a pointer to something. it's fine as-is.
> >> in this way of doing an api we no longer can use the const attribute to say
> >> anything about the object here. there isn't a lot of point either.
> >
> > I find it nice to have in cases where you want to query the object but
> > not modify it. For example, but not only: when returning textblock
> > cursors (assuming they were Eobj as well) from the textblock API...
> >
> > But ok, if you think it's not needed ATM I'll just wait until I find a
> > concrete use case.
>
> I do disagree with raster on this. Const is a must, it help compiler
> and developer spot their error more easily. It also help for some
> optimization. I do thing that adding an eo_query(const Eo *obj, ...);
> is worth it. It does means that we do have a new class of function
> pointer in Eo. So we better think about it now, rather than later and
> break our structure and ABI.
you can't do it with varargs as any of the op id macros could set or get,
unless you now complicate things. also there is no optimization the compiler
can sensibly do in any of these situations. so here is what it looks like to
the compiler for 1 get example:
eobj_do(obj, EVAS_COLOR_GET(&r, &g, &b, &a));
fn(void *obj, int id1, void *p1, void *p2, void *p3, void *p4, int end);
vs
fn(const void *obj, int id1, void *p1, void *p2, void *p3, void *p4, int end);
the ONLY optimizing the compiler can do with a const ptr vs non is assume
previously fetched values are the same without a re-fetch and no operations in
between that MAY have affected them. eg:
void *obj = x;
printf("val = %i\n", obj->myval);
f1(obj, 10); // f1 takes const void * for obj
printf("val = %i\n", obj->myval);
in THIS case the compiler can keep the value fetched from the first printf
(myval) and OPTIMIZE without having to deref obj as what obj points to
can/will not have changed. if it was not const for the obj, compiler must re-do
the deref.
BUT... here's the catch... the "cached" value would be in a register and...
that would have been nuked by the func call. so unless it was inlined - it wont
be able to. ALSO for eobj the object struct is opaque to the caller so u never
deref its internals... thus the above never happens. so it doesnt help
optimization at all in these kinds of cases.
as for spotting bugs - doesnt a GET tell you enough? do u think people see the
const before they see a get? as for compiler... what issue will it spot here?
how will the compiler spot anything iuf we add a const in front of the obj ptr
and specialize "gets" ?
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
