[Development] [Proposal] Replace size related parameters with size_t

Yves Bailly yves.bailly at laposte.net
Tue Dec 24 19:49:23 CET 2013


On 24/12/2013 19:26, Kurt Pattyn wrote:
> QString, QByteArray, QList, aso often use sign integers to store sizes, indexing, aso.
> This often leads to signed/unsigned mismatches and is not really according standard practice.
> Also, this restricts the indexes, sizes, aso to 32-bit.

31-bit actually... :-) unless you use negative indices, which can be handy sometimes.
That said, the days where you would need to index more than 2147483647 items don't seem
so close yet. In cases where it might happen (file offset), usually "long long" or int64_t
is used, which should be plenty enough for some years.

This might be an issue when using e.g. QByteArray to handle more than 2GB of memory, or
sharing more than 2GB with QSharedMemory. If keeping the signed indices is desirable,
then maybe those classes should switch to int64_t - after all, huge amount of RAM is
more and more common these days.

> One solution to resolve the signed/unsigned mismatch is to cast the types to the appropriate type, but this can be dangerous, and hides the real problem.
>
> A better approach would be to use std::size_t.
>
> My proposal is to replace all int types with size_t where appropriate.
>
> I realise that this has a major impact on compatibility, but it is certainly something that should be considered.
> A solution to the compatibility problem could be to duplicate the methods and mark the old ones as obsolete.
>
> What are your thoughts?

This a subject which as already been highly discussed already.

A side effect is to have to define a special value as being "invalid index",
similar to std::string::npos, for e.g. search functions which return an
index instead of an iterator.

I used to agree to use size_t for all size-related semantic, whereas Qt developers
have consistently preferred int, for reasons they will recall much better than me.
Along the years I got to deal with it, really it's a minor annoyance.

So for what it worthes, my thought is to consider there are more important things
to do before such an important change.

Regards,

-- 
(o< | Yves Bailly                          | -o)
//\ | Linux Dijon  : http://www.coagul.org | //\
\_/ |                                      | \_/`



More information about the Development mailing list