Am Thu, 20 May 2010 14:27:45 +1000 schrieb Carsten Haitzler (The
Rasterman):
I just documented this with some lines in the beginning of the example
that everyone understands that this is only example code and real
applications should use pointers to data (structures).
regards
Andreas
> On Wed, 19 May 2010 08:24:09 +0200 Atton Jonathan
> <jonathan.at...@gmail.com> said:
>
> it is indeed a shortcut. i could use printf with %p instead - but i
> was just avoidng adding a full struct/object there that would
> normally be the case when querying values from it. is imply used the
> pointer itself as a quick shortcut to keep the code small and
> focused. in any normal situation it'd be a void * to your original
> data struct that you'd probe/fetch values from etc.
>
> > This is a shortcut, it avoid to use a struct to store the int.
> > Sometimes for an example it is better to have less code, this way
> > you only see the interesting part. But of course this is not a good
> > example for newbies.
> >
> > 2010/5/19 Brett Nash <n...@nash.id.au>
> >
> > > On Tue, 18 May 2010 22:01:57 +0200
> > > Andreas Volz <li...@brachttal.net> wrote:
> > >
> > > > Hello,
> > > >
> > > > I noticed a problem in the Elementary GenList example code:
> > > >
> > > > static Elm_Genlist_Item_Class itc1;
> > > > char *gl_label_get(const void *data, Evas_Object *obj, const
> > > > char *part) {
> > > > char buf[256];
> > > > snprintf(buf, sizeof(buf), "Item # %i", (int)data);
> > > > return strdup(buf);
> > > > }
> > > >
> > > > static void
> > > > gl_sel(void *data, Evas_Object *obj, void *event_info)
> > > > {
> > > > printf("sel item data [%p] on genlist obj [%p], item pointer
> > > > [%p]\n", data, obj, event_info);
> > > > printf ("data val: %i\n", (int) data);
> > > > }
> > > >
> > > > void
> > > > test_genlist(void *data, Evas_Object *obj, void *event_info
> > > > {
> > > > int i;
> > > > ...
> > > >
> > > > for (i = 0; i < 2000; i++)
> > > > {
> > > > gli = elm_genlist_item_append(gl, &itc1,
> > > > (void *)i/* item data */,
> > > > NULL/* parent */,
> > > > ELM_GENLIST_ITEM_NONE,
> > > > gl_sel/* func */,
> > > > (void *)(i * 10)/* func
> > > > data */); ...
> > > > }
> > > >
> > > > While wrapping GenList to C++ I noticed that something really
> > > > bad happens here. The value of 'i' and 'i*10' is casted into a
> > > > pointer type and later casted back to int. I'm really sure this
> > > > code isn't covered by the C standard and not portable in any
> > > > way. This code needs the int type to have the same size as a
> > > > pointer type. But there may be architectures/compilers where
> > > > this isn't the case. And even if this works here it may bring
> > > > someone to the idea to do the same with other integral types
> > > > where this won't work for sure. Not a smart idea in a public
> > > > example...
> > > >
> > > > If you think this is correct code and I'm wrong please enlighten
> > > > me. :-)
> > >
> > > It's technically not correct. Yes it hits something undefined in
> > > there. Practically however it's only a problem if sizeof(int) >
> > > sizeof(ptr) or some weird platform which doesn't support odd
> > > pointers or something (cray I's?). Don't think efl runs on any
> > > of those platforms ;-)
> > >
> > > Pratically it's fine. A slight improvement may be to cast it to
> > > an intptr_t which will protect it against different size
> > > void/int's (And will reduce warnings too).
> > >
> > > > If not I'll change the example to hold two int arrays in the
> > > > correct scope and work with pointer type data.
> > >
> > > Or do that ;-)
> > >
> > >
> > > ------------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> >
> >
> > --
> > Regards.
> > ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am"
> -------------- The Rasterman (Carsten Haitzler)
> ras...@rasterman.com
>
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
