On Wed, 2010-11-24 at 02:56 +0100, Jaroslav Šmíd wrote:
> On 11/19/2010 10:15 PM, Evan Nemerson wrote:
> > On Fri, 2010-11-19 at 19:58 +0100, Jaroslav Smid wrote:
> >> Well, U suffix works, but I thought vala would be smart enough to handle
> >> this. Anyway, I had to switch to C because vala doesn't use size_t for
> >> array
> >> sizes and uses int.
> >
> > public void foo ([CCode (array_length_type = "size_t")] int[] bar);
> >
> > Generally array_length_type is used for bindings... if you just need to
> > use a C library which uses size_t you can just do something like the
> > above in your vapi and it will work perfectly. Lots of bindings use this
> > since the type used for the array length in C is so inconsistent (often
> > even within the same library).
> >
> > If you want libraries you write in Vala to expose size_t as the array
> > length parameter, you can still do it but you will occasionally have to
> > work around issues caused by Vala thinking the variable is an int
> > (although it will be generated as size_t). That wouldn't be too
> > difficult, though... certainly less work than writing everything in C.
> >
> >>
> >> pancake: sorry for sending messed up message :-)
> >>
> >> On Thu, Nov 18, 2010 at 10:53 PM, pancake<[email protected]> wrote:
> >>
> >>> Vala should handle this correctly. The type is uint32 and not int32
> >>>
> >>> On 18/11/2010, at 15:31, Xavier Bestel<[email protected]> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> On Thu, 2010-11-18 at 10:52 +0100, Jaroslav Smid wrote:
> >>>>> /home/jardik/Projects/DAOLinux/ErfEditor/Blowfish.vala:6.15-6.24: error:
> >>>>> Expected initializer of type `uint32' but got `int64'
> >>>>> 0x243F6A88, 0x85A308D3, 0x13198A2E, 0x03707344,
> >>>>> ^^^^^^^^^^
> >>>>
> >>>> I think it's because this constant is too big to fit a signed int32, so
> >>>> it's a signed int64 => error.
> >>>> You should suffix it to explicitly tell it's unsigned to make it fit, I
> >>>> guess.
> >>>>
> >>>> Xav
> >
> >
>
> 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.
> 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.
> At least some command line argument that would
> force vala to use size_t? I know languages like C# and Java use int -
> but that is what I don't get. It's much better if type with the size of
> a pointer is used for it,
A command line switch would be *horrible*. Then you would have something
that completely alters the behavior of the compiler in a quite possibly
incompatible way that would be very difficult to spot. Every time you
get a chunk of Vala code, you have to know whether array lengths need to
be int or size_t... Then what happens when you need to mix the two in
the same project?
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 only thing I think valac should be doing is be to handle something
like this properly:
void foo ([CCode (array_length_type = "size_t")] uint8[] bar) {
var baz = bar.length;
}
-Evan
_______________________________________________
vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
