On Thu, 3 Jun 2010 07:26:43 +0200 (CEST)
Vincent Torri <vto...@univ-evry.fr> wrote:
>
>
> On Thu, 3 Jun 2010, Carsten Haitzler (The Rasterman) wrote:
>
> > On Wed, 2 Jun 2010 20:24:28 +0200 (CEST) Vincent Torri
> > <vto...@univ-evry.fr> said:
> >
> > all other callback adds use const void *data - and that's correct
> > as it means the add doesnt do anything to what data points to
> > (doesn't modify) but the callback itself that is passed this
> > pointer gets void * as the callback can modiy what it points to.
>
> but it breaks the 'const' chain. In that case, there is no interest
> of using any const pointers (for me).I like the C++ way of using
> const: if you pass a const pointer, at some point, you are sure that
> is it never modified later.
Unfortunately C doesn't have the correct way to describe what we are
after (this call won't modify the data, but you can do what you want to
it, since it's yours). If we really really wanted to preserve
appropriate const attributes we'd need two versions of each function:
one for const data, and one for non-const, and even then it would fail
to indicate EFL doesn't modify the data.
Note the C standard library has _exactly_ the same problem. [I'm sure
either the c89 or c99 rational document described this, but I can't
find it anywhere - maybe a defect notice]
Examples:
char *strstr(const char *, const char *);
Which returns you a non const version of the const paramater, so C
(and C++) programmers should be aware of the problem. And since the
users of the library then DON'T need to cast their modifiable data or
the unmodifiable data (as long as their types are correct), it's all
fine.
Regards,
nash
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
