On Tue, Nov 23, 2010 at 18:36:40 -0800, Evan Nemerson wrote:
> On Wed, 2010-11-24 at 02:56 +0100, Jaroslav Šmíd wrote:
> > Anyway, any chance that vala will switch to size_t (or at least intptr_t
> > or ptrdiff_t (which is standard defined type for pointer difference))
> > from int for array indexing and array sizes?
>
> It's a long shot. The problem is that Vala isn't building a whole new
> ecosystem of software, it is trying to reuse existing libraries. It is
> easy to switch to size_t (or ssize_t) if you're creating, say, .NET or
> JRE, but most C libraries use int.
Standard library uses size_t consistently and so does anything POSIX.
GLib does use it's own typedef gsize, but does not do so consistently. The
memory functions do, but the rest is a mixture.
In any case I would prefer if vala generated size_t in interfaces it
*generates* and was able to understand appropriate declarations for .vapis.
> > Writing that stuff before each array is very ugly.
>
> I agree that it is ugly, but unless you can convince all the C libraries
> to switch to (s)size_t, I don't see a way around it. You either have to
> write something extra when you want to use size_t or when you want to
> use int, and I think int is by far the most common case so it makes
> sense to optimize for that.
There is a way around it -- being able to specify per-namespace default.
A single library is usually self-consistent. So specifying the attribute for
whole namespace would help.
So if you have a library that uses type X consistently, you'd just annotate
the top-level namespace declaration in the .vapi with
[CCode(array_size_type = "X")] and be done with it. If it's not
self-consistent, than obviously individual members and arguments would need
to be annotated.
> A command line switch would be *horrible*.
Agree. Command-line switch would not work.
> Also, keep in mind that not everyone is going to agree on size_t. First
> of all, it's unsigned, and there are a lot of places where that is a
> deal-breaker. Then, what about ssize_t, unsigned int, unsigned long,
> long, unsigned short, short, intptr_t, ptrdiff_t, etc.?
The precise meaning of size_t, ptrdiff_t and inptr_t are defined by the
standard, so there is a clear guideline when to use which (I don't think
ssize_t is a standard type). They are:
- size_t is the return type of sizeof operator and used as argument of
memory allocation functions, so it's appropriate for array and object
sizes.
- ptrdiff_t is the return type of operator - applied to pointers, so it's
appropriate for offsets that need to be signed.
- intptr_t (c99 only) is an integeral type large enough to store value of
a void*.
Note, that size_t or ptrdiff_t don't have to be large enough to store value
of a void*. size_t and ptrdiff_t must only be able to store size of any
single object, but single objects may be limited to less than whole memory
size (e.g. when segments are used).
--
Jan 'Bulb' Hudec <b...@ucw.cz>
_______________________________________________
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
